arry - icann...6. next steps • next steps • official notice of renewal due to landlord – •...

1

19 January 2018

To: ICANN Board From: The SSAC Chair Via: The SSAC Liaison to the ICANN Board The purpose of this letter is to bring you up-to-date on proposed changes to the membership of the Security and Stability Advisory Committee (SSAC) and to provide an explanation for the attached request for Board action. This change is the result of ongoing new member evaluations conducted by the SSAC Membership Committee and approved by the SSAC. The SSAC Membership Committee considers new member candidates and makes its recommendations to the SSAC. The SSAC has agreed with the Membership Committee’s recommendation to nominate Barry Leiba and Chris Roosenraad as SSAC members. Many of the SSAC members have known Barry Leiba from his extensive work in the IETF, including being working group chair, being Applications Area Director, serving on the Internet Architecture Board. He brings significant expertise in Internet messaging and messaging-related standards, more broadly application layer protocols and the security and privacy aspects of them. He has a strong background in internationalization issues. Chris Roosenraad has participated extensively in the MAAWG. He has been active with the Technology Coalition and advising the US Government through the FCC CSRIC process. He has extensive experience managing some of the largest Internet infrastructure services, including DNS, DHCP, email, and identity management. The SSAC believes Barry and Chris would be significant contributing members of he SSAC. The SSAC Membership Committee respectfully requests that the Board appoint Barry Leiba and Chris Roosenraad to the SSAC for a 3-year term beginning immediately upon approval of the board and ending on 31 December 2020. Attached are their CVs for your reference.

The SSAC welcomes comments from the Board concerning this request. Rod Rasmussen, SSAC Chair

Co

2

BARRY LEIBA

SUMMARY STATEMENT Senior Technical Staff, in-depth technical knowledge in Internet technology and strong ability to problem-solve to resolve conflict, to gain consensus, and to develop software architecture Experienced negotiator in bringing discussions to consensus, merging agendas to accomplish objectives Excellent presenter with a high comfort level of presenting to executive level, technical people, and general public Strong human relations skills with ability to analyze individual and team contributions to defuse situations and reach targeted objectives

EXPERIENCE HUAWEI TECHNOLOGIES 2009 – Present

Senior Standards Manager, Applications and Security Provided leadership in Internet standards work with the Internet Engineering Task Force (IETF) – the standards-development organization responsible for many of the Internet's standards – for Huawei's Industry and Standards Department Attained leadership positions in the IETF (see below), and provided guidance to more junior members of the Huawei team Responsible for guiding corporate strategy on Applications and Security standards work

INTERNET ENGINEERING TASK FORCE (IETF) 1998 – Present

Applications Area Director (2012-present) Served as Applications Area Director (2012-2016), responsible for managing the standards process and the working groups in the Applications Area, and review and approval of all standards documents Chair of three working groups (2016-present), and prior chair of five working groups (2006-2012) Served on the Internet Architecture Board (IAB, 2007-2009) Author of twenty five RFCs Serving as IETF liaison to the Messaging Malware Mobile Anti-Abuse Working Group (M3AAWG, 2009-present) Recognized as an expert in Internet messaging and in messaging-related standards

IEEE INTERNET COMPUTING MAGAZINE 2008 – Present

Associate Editor in Chief (2012-present); Editorial Board Member (2008-present) Edited the “Standards” department in the magazine from 2008 to 2016 Appointed to the Editorial Board in early 2008 Appointed as Associate Editor in Chief in 2012 Guest Editor for three issues between 2009 and 2013 Responsible for overall content for those issues, and “department” content for all issues Responsibilities include writing, editing, reviewing, and process management IEEE Senior Member

IBM CORPORATION 1977 – 2009

Senior Technical Staff Member, Research Division, Hawthorne, NY Served as project leader, manager, and senior technical advisor in a diverse range of areas, providing detailed technical leadership, software research, strategy, and advice to executives across the corporation Delivered briefings and participated in task forces in Internet standards, electronic mail, social computing, computer security, and mobile and ubiquitous computing Project Highlights:

Bluehouse 2008 Guided research team to connect work initiatives for completion of projects through joint program between Research and Lotus divisions Key leader for group that connected Bluehouse project to mobile devices, to enhance mobile collaboration, and then implemented standards-based email in Bluehouse, addressing email and security issues

BluBird 2007 Developed a podcast distribution system, in joint work with the CIO office BluBird aimed to enhance the user experience for corporate podcasts, and included a media repository, some enhanced tagging and searching, and the use of metadata – some automatically created – to help users find the place in the podcast of interest to them

Contact Information Redacted

Contact Information Redacted Contact Information Redacted

3

Page 1

Chris RoosenraadDirector, UltraDNS

SummarySecurity on the Internet is no longer the work of one talented individual, or even a team of talented individuals. Security comes from collaboration, from working together with others (industry, academia, and government) to share information and best practices. I am an expert in building this collaboration, in bringing together different people with different areas of expertise, and finding ways for them to work together towards a common goal.

ExperienceDirector of Product Management at Neustar, Inc.January 2017 - Present

Two primary areas of responsibility:

Product ownership for DNS products (former UltraDNS product line). Manage the product roadmap, life cycle, and direction forward. Prioritize product requests, and identify long term goals.Industry/Government relations strategy. Map out our strategy for interacting with other industry players and government agencies. Coordinate internally for a coherent message out to our partners, colleagues, and competition.

Chairman Emeritus2008 - Present

I have served in almost every leadership position within MAAWG, first as an ordinary member, then as chairman of the technical committee, then the program committee, vice-chairman, and finally chairman.

As chairman emeritus, I act as a ambassador for the organization, an internal and external advocate, and an advisor to the current leadership.

TreasurerAugust 2015 - Present

The Technology Coalition is an internet industry organization dedicated to eliminating online child sexual exploitation. As treasurer and board member, I am responsible for overseeing the budget, accounts payable and receivable, and all aspects of the financial life of this organization. I make sure they have the money to do the great work they do.

Customer Security at Charter Communications

Contact Information Redacted

Contracting and Disbursement Authority for Lease Renewal of Singapore Office

Exhibit A

Jia-Rong LowVice President, Stakeholder Engagement & Managing Director – Asia Pacific

Linda ChinDirector, Global Operations

Board Finance Committee Meeting__ January 2018

| 2

Strategic Rationale Current Status Board Decision Requested

Summary of Estimated Costs

Relocating vs Renewing

Next Steps

1 2 3

4 5 6

Agenda

| 3| 3

1. Strategic Rationale & 2. Current Status

1. Strategic Rationale• Affirm ICANN’s commitment to the globalization goal • Engage and support APAC stakeholders• Retain staff and attract talent

2. Current Status• Since October 2015• South Beach Tower – Level 4, Unit 11• 20 staff; 26 work desks (can reconfigure for more spaces)• Close proximity to past ICANN meetings venue & lodging

for visitors• Convenient location and attractive to current and new staff

(near 2 major metro interchanges)

| 4| 4

3. Board Decision Requested• To Contract for Renewal of Lease

• Propose not to relocate • Terms

• 3 years: 1 October 2018 – 30 September 2021• Option to renew for additional 3 years

• Space • No change in area = 4,639.28 square feet (431 square meters)

• Lease Cost (Rent + Op Exp + Taxes) - ESTIMATES:• Increase from current:

• Rent ~10% [due to building full occupancy & market supply down]• Operating Expenses ~4% [market trend]

• Lease (3 yrs) =• Costs vis-à-vis Budget:

• Upfront Cost:• Est. Rental Cost:

1 Oct-18 to 30 Jun-19 (FY19 Draft Budget)

Confidential Negotiation Information



| 5| 5

3. Board Decision Requested• To Contract for Renewal of Lease

• 3 years vs 5 years• The Gross Rent for a 5 years lease at South Beach Tower (current

location) is expected to be the same for a 3 years lease, at(incl. taxes), given the current full occupancy of the building

• According to the Singapore Office supply forecast from Jones La Lasalle(JLL) and Colliers, in 3 years’ time (Yr 2021), we can expect 2.1 million square feet of new office space.

• Expect estimated downward adjustments in Gross Rent by 15% from current rate, based on historical trends and future office developments in the vicinity of the South Beach Tower. This translates to savings of

• As such, we propose to renew the lease for 3 years.



| 6

4. Summary of ESTIMATED Costs


| 7

5. Relocating vs Renewing Relocate (Move)• Market rental in the vicinity :• If move, assume average rental rate : • Projected Cost Savings : • Added Cost of Renovatio

Conclusion : Renew (Stay) is the preferred option





| 8| 8

6. Next Steps

• Next Steps • Official notice of renewal due to Landlord –

• After 31 Dec 17 & Before 1 Apr 18• Board approval – Feb 2018• Notice of renewal to Landlord – Feb 2018• Negotiations & draft lease – Feb / Mar 2018• Finalize lease contract – April 2018

| 9

Q&A

| 10

Appendixes

| 11

(a) Terms, Space & ESTIMATED Cost /sf/mo.


| 12

(b) ProximityNear ICANN community, tech/Internet companies, major metro interchanges & ICANN meeting venue

Note: car ownership is very expensive in Singapore, therefore, proximity is important.

Contracting and Disbursement Authority for Lease Renewal of Brussels Office

Jean-Jacques SahelVice President, Stakeholder Engagement & Managing Director Brussels Office

Board Finance Committee MeetingJanuary 2018

| 2

Strategic Reasons Location Board Decision Request

Status & Next Steps

1 2 3

4

Agenda

| 3| 3

1. Strategic Rationale & 2. Location

1. Strategic Rationale• Affirm ICANN’s commitment to the globalization goal • Engage and support European stakeholders• Retain staff and attract talent• Drive operational efficiency

2. Location• Since the mid 2000s in this European hub and capital city• EU Quarter• Near 1 major metro station• Close proximity to European institutions & lodging for

visitors• Convenient and attractive to current and new staff

| 4| 4

3. BFC Recommendation for Board Approval • To Contract for Renewal of Lease

• Propose not to relocate • Terms

••

• Space • No change in area (sqm)• Possibility of functional renovation e.g. enhanced meeting spaces, with

landlord offering to contribute• Lease Cost :

• Decrease from current:• Lease:

• Proposed, with 6 years early termination clause: (Total Rent per year, inc. charges and property tax)

• Current, with 3 years early termination clause:• FY18 costs – in line with FY18 budget• FY19 costs – included in FY19 draft budget

Confiden ial Nego ia ion nforma ion


Confidential Negotiation nformation

Confidential Negotiation nformation


| 5| 5

4. Status & Next Steps

• Status• Conducted market review • Performed cost analysis of lease renewal versus

relocating to another location • Proposed new terms under legal review and

consideration for Board approval • January 18

• Next Steps • Board approval – Feb 2018• Finalize lease contract – Feb 2018

1

SSAC Advisory on Registrant Protection: Best Practices for Preserving Security and Stability in the Credential Management Lifecycle

SAC074

SAC074 SSAC Advisory on Registrant Protection: Best Practices for Preserving Security and Stability in the Credential Management Lifecycle

An Advisory from the ICANN Security and Stability Advisory Committee (SSAC) 03 November 2015

2

SSAC Advisory on Registrant Protection – Best Practices for Preserving Security and Stability in the Credential Management Lifecycle

SAC074

Preface This is an advisory to the ICANN Board, the ICANN community, and, more broadly, the Internet community from the ICANN Security and Stability Advisory Committee (SSAC) on Registrant Protection: Best Practices for Preserving Security and Stability in the Credential Management Lifecycle. The SSAC focuses on matters relating to the security and integrity of the Internet’s naming and address allocation systems. This includes operational matters (e.g., pertaining to the correct and reliable operation of the root zone publication system), administrative matters (e.g., pertaining to address allocation and Internet number assignment), and registration matters (e.g., pertaining to registry and registrar services). SSAC engages in ongoing threat assessment and risk analysis of the Internet naming and address allocation services to assess where the principal threats to stability and security lie, and advises the ICANN community accordingly. The SSAC has no authority to regulate, enforce, or adjudicate. Those functions belong to others, and the advice offered here should be evaluated on its merits. A list of the contributors to this advisory, references to SSAC members’ biographies and disclosures of interest, and individual SSAC members’ withdrawals and dissents with respect to the findings or recommendations in this advisory are at the end of this document.

3


SAC074

Table of Contents

Executive Summary ............................................................................................ 4 1 Introduction ...................................................................................................... 6 2 Recent Attacks ................................................................................................. 7

Re-using the Same Username/Password Combination .......................................... 7 Phishing and Spear Phishing Attacks ...................................................................... 8 Storing and Sending Credentials in Cleartext .......................................................... 9 Compromises of Unclear Mechanism ..................................................................... 10 Credential Management Incident Response Errors ............................................... 11

3 Credential Types ............................................................................................ 11 4 Credential Use ................................................................................................ 13 5 The Credential Management Lifecycle Today .......................................... 15 6 Practical Checklist / Credential Management Best Common Practices 22 7 Recommendations ......................................................................................... 27 8 Acknowledgments, Disclosures of Interest, Dissents, and Withdrawals 29

8.1 Acknowledgments .......................................................................................... 29 8.2 Disclosures of Interest ................................................................................... 29 8.3 Dissents ........................................................................................................... 30 8.4 Withdrawals ..................................................................................................... 31

Appendix A: Glossary of Terms ...................................................................... 32 Appendix B: TLD Registry Breaches .............................................................. 35 Appendix C: Previous SSAC Report References ........................................... 37

4


SAC074

Executive Summary Attacks that compromise registrant data and/or the Domain Name System (DNS) settings of domain names1 continue to be a significant problem for registrars and registries, as well as for the registrants themselves and the users of their sites. This Security and Stability Advisory Committee (SSAC) advisory provides background about this problem, including numerous examples, and explains the credential management lifecycle and related terminology for the Internet Corporation for Assigned Names and Numbers (ICANN) community. This advisory then provides specific best practice guidelines that will help registrars and registries enhance the security of domain names and the systems that support them. Section 6 of this advisory contains these best practices, addressing the entire credential management lifecycle. SSAC makes four recommendations to ICANN, which are described fully in Section 7 below:

Recommendation 1: As part of regular reports, the ICANN Compliance Department should publish data about the security breaches that registrars have reported in accordance with the 2013 Registration Accreditation Agreement (RAA), paragraph 3.20. 2 We do not, at this time, recommend whether registrars' names be published or not. However, we do recommend that statistics about the number of breaches and the number of registrars affected, the aggregated number of registrants affected, and the high-level causes of the breaches, including specifying which breaches could be attributed to a problem in the credential management life cycle would be illuminating to the community and will emphasize the need for good security measures to be followed by registrars. We believe that this data can be appropriately anonymized, and still be a useful way to provide better information to the Registrar community as to the nature of the threat landscape. We observe that the term ‘security breach’ in the 2013 RAA is defined as ‘any unauthorized access to or disclosure of registrant account information or registration data.’ It would be helpful in the reported data and any statistical summaries to distinguish between, on the one hand, breaches of registrar systems or unauthorized release of data by the registrar itself, and, on the other hand, unauthorized access or disclosure due to individual registrants losing control over their credentials in a way not attributable to their registrar's systems or controls.

1 Appendix A provides a Glossary of Terms. Terms defined in the Glossary are italicized the first time they are used in the text of this Report. 2 See https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#3.20.

5


SAC074

Recommendation 2: A provision similar to 2013 RAA paragraph 3.20 should be incorporated into all future registry contracts, with similar statistics published as per Recommendation 1 above. Recommendation 3: Future RAA deliberations should encourage stronger authentication practices, specifically the use of multi-factor authentication. Recommendation 4: The ICANN Board should direct ICANN staff to facilitate global hands-on training programs for registrars and registries based on the best practices outlined in Section 6 of this document, with the goal to enable parties to learn practical operational practices for preserving security and stability of the credential management lifecycle. We would welcome the opportunity to advise training staff in the creation of a curriculum. This effort should involve measurement and outreach including cooperation with other global training efforts with ICANN partners such as ISOC. ICANN should support this effort with adequate staffing and funding. Such a program should cover at least the following topics:

• Create a training program that follows the structure of the DNSSEC Deployment Initiative but that is focused on hands-on training of operational practices that provide best security practices for the credential management lifecycle.

• Create and maintain an information portal, managed by ICANN staff, supported by community subject-matter expert contributions, and with links to educational material.

• Provide an annual report on the work accomplished.

6


SAC074

1 Introduction

Attacks that compromise registrant data and/or the DNS settings of domain names continue to be a significant problem for registrars and registries, as well as for the registrants themselves and the users of their sites. This advisory augments the previous work done in SAC40,3 which advised registrars on protecting registrant accounts, and SAC44,4 which advised registrants on protecting their accounts. Both advisories recommended strong identification and authentication, but did not itemize specific methods for doing so. This SSAC advisory fills this gap by defining specific best practice guidelines for preserving security and stability in comprehensive domain-related credential lifecycle management. Since registrants, registrars, and registries all manage some aspects of credentials relating to domain names, this advisory targets all three communities, with some emphasis on the registrar community. While these three communities address the contracted parties within the ICANN contractual model, added stakeholders should also make note of their credential uses and lifecycle management practices. This includes: Privacy Proxy Services, Resellers, Hosting Facilities and Independent DNS Providers. The issue of credential management has emerged as a serious business challenge that goes far beyond traditional password management. Many compromises have been tied directly with issues relating to credential management. This SSAC report recounts recent attacks to motivate the need for action, examines where credentials are used throughout the complete lifecycle of a domain name, and recommends better practices to create a more secure credential management process. This advisory specifically addresses credential lifecycle practices for designing, creating, distributing, storing, renewing, transferring, revoking, recovering, and destroying credentials associated with a domain name lifecycle. All methods and schemes used to provide authentication of an identity (registrant or authorized administrator of registrar or registry) and authorization for specific actions are in scope. The scope also includes highlighting any relevant policy issues that can support or hinder credential management. A cornerstone of all security strategies is an organization’s ability to control access to data and systems. Virtually all access controls rely on the use of credentials to validate the identities and permissions of users, applications, and devices. Types of security credentials include:

• User Names or IDs, and passwords or passphrases.

• Asymmetric Key Pairs. A public key and private key that enable encryption, authentication and digital signatures.

• Security tokens, which are typically one-time-passwords or PINs generated

3 See https://www.icann.org/en/system/files/files/sac-040-en.pdf. 4 See https://www.icann.org/en/system/files/files/sac-044-en.pdf.

7


SAC074

via a physical device (i.e. hardware token) or via a program running on a computer (i.e. software token).

• Biometric attributes, which identify a user by a feature of their biology, including fingerprints or iris scans. These are not commonly used in domain name registration processes, and are mentioned for completeness.

Multi-factor authentication schemes employ two or more such types of credentials. Typically they will mix credentials from the categories "something one has" (e.g. a hardware token), "something one knows" (e.g. a password) and "something one is" (e.g. biometrics). Information about recent attacks was acquired through searches of public news reporting. Only very limited information about current credential management practices was publicly available because registrars and registries do not generally make their processes public. Additionally, the ICANN 2013 RAA does not contain any meaningful requirements about credential management. It is important to note that the lack of transparency and lack of requirements in this space prevents any rigorous analysis of the current situation or the effectiveness of any measures undertaken to improve the situation. This assessment of the current state of the practice is based on private conversations with registrars and registry operators and what can be deduced from public reporting about attacks. This advisory specifically addresses protection of a registrant’s domain name at the level delegated by a registrar, not further subdomains the registrant may administer.

2 Recent Attacks

Malicious access to and potential reconfiguration of registrant data can severely disrupt business operations and can cause significant financial and reputational harm. Damage from changes to registrant data is not limited to the registrant alone, but can also affect registrars, registries, users of the registrant’s domain(s), and other DNS service providers. In the last few years, there have been numerous publicized events where the compromises were attributable to deficiencies in credential management. Typical attack vectors, and instructive examples of specific attacks that occurred between March 2012 and March 2015, are reviewed below, with further examples contained in Appendix B. While the examples below point to specific publicized events, they are not meant to single out specific registrars or registries, but rather illustrate the importance and immediacy of the problem.

Re-‐using the Same Username/Password CombinationIn many instances, users employ the same username/password combination across different accounts or on different websites. Password reuse stems from a user’s need for convenience and the limited human capacity to remember random strings of characters. Either registrants or authorized personnel for a registrar or registry may make this mistake. Such reuse is poor practice because it makes the authentication system brittle: a

8


SAC074

single compromise of a user/password combination can be used to attack other sites. One clear example was the attack at the domain registrar Namecheap in January 2014.5

Phishing and Spear Phishing Attacks Phishing is an illicit attempt to compromise credentials by luring Internet users to a page that imitates a trusted site such as a bank or e-commerce site. This tactic appears to have succeeded via targeting of GoDaddy registrants in 2012,6 and other registrars and their customers have also been targeted. A successful detection strategy is for the registrar to identify suspicious access patterns (indicative of credential abuse), as the theft of credentials does not occur on the registrars’ systems. A spear phishing attack uses phishing techniques to target high-value credentials that allow access to critical systems or data such as those held by the staff members of a registrar or registry. The compromise of an entire registrar is highly critical as all customer data and systems can be exposed. Attackers therefore spend time specifically crafting a targeted approach and a resultant spear phish email. Spear phishing reportedly resulted in the change of DNS settings of several high-profile domains in August 2014.7 Attackers employed a spear phishing attack against staff at a Melbourne IT reseller to capture administrator-level account credentials, and used them to alter name server delegations for several domain names, including NYTimes.com.8 The attacker changed the content served by the hijacked domains by serving all Internet lookups for those domains via their DNS servers.9

Domain ShadowingAttacks against registrar accounts using stolen registrant credentials continue to escalate and evolve. Recently, the “Angler” exploit kit has drastically increased the use of a tactic called “Domain Shadowing”10 in which, by using stolen or phished credentials, the malicious actors create numerous subdomains associated with existing, reputable domains in the registrant’s portfolio. This tactic has been used since at least 2011, and is even more prevalent today. With credentials, the attackers gain full access to DNS and domain resources. The new subdomains are pointed to Internet Protocol (IP) addresses that further serve up malicious content such as malware and ransomware. Because registrants often do not regularly monitor for additions to their zone data, and their existing legitimate DNS entries continue to function normally, these malicious subdomains often go unnoticed for extended periods of time. Improved monitoring and notifications by registrars confirming DNS changes to zones they are hosting for registrants, and an increased awareness of DNS activity by registrants would go a long way towards reducing or eliminating domain shadowing. 5 See http://www.ecommercetimes.com/story/80979.html. 6 See https://nakedsecurity.sophos.com/2012/11/23/hacked-go-daddy-ransomware/. 7 See http://www reuters.com/article/2013/08/28/media-hacking-melbourne-idUSL2N0GT01K20130828. 8 See http://www.pcworld.com/article/2047628/spear-phishing-led-to-dns-attack-against-the-new-york-times-others.html. 9 See http://www.cnet.com/news/melbourne-it-tells-how-hacker-launched-ny-times-cyberattack/. 10 See http://blogs.cisco.com/security/talos/angler-domain-shadowing.

9


SAC074

Storing and Sending Credentials in CleartextCredential data is sensitive and needs protection both in transit and at rest to minimize the chance of disclosure. Even if the information is encoded in a way that is not human-readable, techniques exist to determine which encoding is being used, and then to decode the information. This was one of the factors that made a compromise at Melbourne IT so damaging.11 Insecure transmission of credentials includes unencrypted email or browser sessions (cleartext) and phone conversations. Sending passwords over the phone to customer service representatives has reportedly been common practice at some registrars as recently as July 2013. 12 Ideally, customer service representatives should not have visibility of the primary account password/passphrase. Additionally, customer service representatives should not ask a registrant for their password to verify their identity because the service representative then learns those passwords. In order to allow for phone verification, many registrars have implemented a phone-specific authentication method. These authentication methods can take similar forms to the additional factors often found in two-factor authentication models. They can be in the form of a pre-determined Personal Identification Number (PIN), or by verifying a temporary access code / phrase sent to a mobile device or alternative email by the registrar. Hacking Attacks Successful attacks on registrars and registries have allowed hackers to obtain credentials directly from these authoritative systems. An example is the compromise of registrar Webnic.cc in February 2015. The attackers evidently obtained persistent access into the registrar’s systems via a rootkit, granting them access to a variety of credentials.13 It is not publicly known whether those credentials were stored in cleartext. On February 23, 2015 attackers briefly hijacked Google’s Vietnam domain, google.com.vn. The attackers then updated the domain record of computer manufacturer Lenovo.com, and pointed it to a Cloudflare account that they controlled, where the attackers then intercepted emails sent to the Lenovo.com domain. The main public-facing Lenovo.com website was also disrupted on February 26, 2015, and was unavailable for some time. Neither of the hijacked domains was protected with a registry lock. During the incident the attackers also claimed that they had obtained the EPP (Extensible Provisioning Protocol) AuthInfo codes for domains that the registrar sponsored14; however this claim has not been publicly substantiated.

11 See http://www.itnews.com.au/News/374095,melbourneit-storing-domain-passwords-in-cleartext.aspx. 12 See http://security.stackexchange.com/questions/39621/is-my-domain-registrar-storing-my-password-in-cleartext. 13 For accounts of the compromise, see: http://krebsonsecurity.com/2015/02/webnic-registrar-blamed-for-hijack-of-lenovo-google-domains/ and http://www.theverge.com/2015/2/25/8110201/lenovo-com-has-been-hacked-apparently-by-lizard-squad. 14 See https://twitter.com/LizardCircle/status/570732413971800064 and http://krebsonsecurity.com/2015/02/webnic-registrar-blamed-for-hijack-of-lenovo-google-domains/.

10


SAC074

Figure 1: DNS records for Lenovo.com, which was hijacked on 25 February 2015. The record on the leftshows the record before the hijack, and the right shows the record while the attack was in progress.

Compromises of Unclear MechanismThe true mechanism used for an attack or compromise is often indeterminable. However, sometimes analysts can reasonably conclude that weak or stolen credentials were involved. For example, in August 2013 many .NL websites were redirected to a handful of IP addresses controlled by a malicious party, which replaced legitimate content with malicious content. This kind of attack is dangerous because the hijacked domains, benign for their lifetime, will bypass domain-based blacklists or domain reputation filters, and end users largely cannot protect themselves.15 The domains that were redirected all belonged to only three web hosting companies.16 The distribution and nature of this attack suggests that the attackers compromised credentials at those three companies and used them to make apparently legitimate changes in the .NL registry. Although there is no evidence of a direct relationship, the .NL registry’s website was compromised the month before, and it is plausible the credentials used to redirect the websites were compromised in a sort of watering hole attack. Similar attacks have occurred against the Uganda,17 Guadeloupe,18 Romania,19 Ireland, Tajikistan,20 and Pakistan Topic Level Domain (TLD) registries, through a variety of attack methods. Some of the attacks appear to have bypassed a TLD’s credential management system altogether, but in the Uganda case the registry statement indicated the likely cause was compromised registrar credentials. In 2013 Markmonitor counted twenty-three registry breaches, noting that “popular ccTLD [country code Top Level Domains] registries such as .CN (China), .BE (Belgium) and .MY (Malaysia) were all impacted by issues arising from Distributed Denial of Service (DDoS), Social

15 See http://blogs.cisco.com/security/dns-compromise-distributing-malware/. 16 See http://blog.fox-it.com/2013/08/05/dns-takeover-redirects-thousands-of-websites-to-malware/. 17 See http://news.softpedia.com/news/Sony-PayPal-Gmail-Intel-Yahoo-Uganda-Domains-Hacked-via-DNS-Poisoning-362340.shtml. 18 See http://thehackernews.com/2012/11/guadeloupe-national-domain-registrar.html. 19 See http://arstechnica.com/security/2012/11/google-microsoft-paypal-other-romanian-sites-hijacked-by-dns-hackers/. 20 See http://thehackernews.com/2014/01/Tajikistan-Google-Twitter-hacked-Domain-Registrar.html.

11


SAC074

Engineering and Brute Force attacks.”21 Please see Appendix B: “TLD Registry Breaches” for more details. Registrars also come under attack from sophisticated actors whose goal is to modify Internet architecture to achieve further objectives. For example, Enom.com detected a highly targeted redirection of domains in May 2015.22 and coordinated the response to the hijacking with the assistance of U.S. Federal law enforcement.

Credential Management Incident Response ErrorsImportant lessons can be learned not just from recent attacks, but from responses to them. Attacks cannot be completely prevented, so it is critical to have an incident response plan for when attacks occur.23 ICANN’s 2013 RAA requires that registrars notify ICANN of security breaches that result in unauthorized access to registrant information.24 Further, it is best practice for a registrar or registry to notify its customers of a breach once detected, and if the credentials or credential management system may have been compromised, to recommend that customers change their password.25 However, it is important that customers know the format of such notifications ahead of time, and to make sure that the notification email comes from a trusted and recognizable domain name, Pretty Good Privacy (PGP) signed, and the password change service is on a known site. Lessons for how not to format such password breach notification emails can be gleaned from Moniker’s handling of a 2013 compromise. The process Moniker followed was sound, but customers often discarded the email that notified them of the breach as a suspected phish, which cost valuable time during the incident response.26

3 Credential Types

There are a variety of mechanisms, generically credentials, for users to prove their identity and authenticate to registrars. Once authenticated, users can register new domains, transfer ownership, remove existing domains, or modify DNS records. When a malicious entity undertakes these actions it causes significant problems or financial harm to individuals, organizations and companies. Credential types used in the domain name industry include:

21 See https://www markmonitor.com/mmblog/2013-domain-name-year-in-review/. 22 See http://www.thedomains.com/2015/05/20/enom-com-informs-customers-of-very-sophisticated-attack-but-no-domains-were-stolen/. 23 See http://www.cert.org/incident-management/csirt-development/csirt-faq.cfm?. 24 ICANN 2013 RAA, paragraph 3.20: “Registrar will give ICANN notice within seven (7) days of... any unauthorized access to or disclosure of registrant account information or registration data. The notice required pursuant to Subsection (iii) shall include a detailed description of the type of unauthorized access, how it occurred, the number of registrants affected, and any action taken by Registrar in response.” 25 See SAC-040; https://www.icann.org/en/system/files/files/sac-040-en.pdf. 26 See http://news.softpedia.com/news/Domain-Name-Registrar-Moniker-Hacked-Users-Forced-to-Change-Passwords-362278.shtml.

12


SAC074

Digital Certificates: A public key infrastructure (PKI) provides the components and services that enable practical deployment and operation of a system that uses digital certificates. Digital certificates are data structures that bind (associate) a public key with the identity of a process or system as verified and signed by a trusted entity. Usually the trusted entity is an independent third-party whose primary function is to certify certificates, called a Certificate Authority (CA). Because these certificates are signed by another trusted signing entity (the CA), it is imperative to create an appropriate trust relationship with the CA and to ensure appropriate procedures and policies exist to avoid any breach of trust. Any CA must have mechanisms in place to verify what it is that they are signing. The strength of the verification defines the protection level of the certificate that is issued. An entity validating a digital certificate must be able to check the digital signature by using the public key of the trusted signing entity, many of which are pre-installed in modern web browsers and operating systems. In the Internet Engineering Task Force (IETF) there is work ongoing to sign certificates with the help of DNS Security Extensions (DNSSEC), which would imply a different chain of trust be built for Digital Certificates than the traditional use of CAs that is described here. Domain AuthInfo Code. The Domain AuthInfo Code is a secret code shared between a registrar and a registrant. The registrar relies on the code to initiate the transfer of a domain name from another registrar. This is a measure designed to prevent unauthorized domain transfers. The EPP <domain: authInfo> element is defined in RFC5731,27 and EPP AuthInfo codes are stored in registry databases. In generic Top Level Domains (gTLDs), every registrar is required by ICANN's Inter-Registrar Transfer Policy28 to give the AuthInfo code to the registrant, who can give it to any other registrar to initiate a valid transfer request. The policy requires registrar-generated AuthInfo codes to be unique on a per-domain basis (noting that this does not mean it can or should be used to identify a Registered Name Holder).29 Multi-Factor Authentication: Combining at least two methods of proving an identity from three distinct categories: something you know (commonly a password or a passphrase), something you have (e.g. a value displayed by a security token fob, or a one-time password sent to a known mobile phone number), and something “that you are” (something about you that is unlikely to change over time, such as a biometric attribute). One Time Password (OTP): A password that is valid for only one login session or transaction on a computer system or other digital device. An OTP might be generated by a hardware token or a software module. Another method of using an OTP is for the authentication server to send it to the user via an out-of-band trusted communications channel, for example a text message to a pre-registered mobile phone number. 27 See RFC5731: https://tools.ietf.org/html/rfc5731. 28 See https://www.icann.org/resources/pages/registrars/transfers-en. 29 See ICANN Inter-Registrar Transfer Policy, section 5: https://www.icann.org/resources/pages/policy-2012-03-07-en.

13


SAC074

Password/Passphrase: A string of characters from a set of acceptable characters that is a secret shared between a user (or client) and the systems (servers) to which that user authenticates. The length and complexity of the string affect the strength of the password in resisting a brute force attack. Public/Private Keys: An encryption and authentication scheme based on a pair of cryptographic keys that is owned by each party. The Public Key is made publicly known and is used to encrypt data intended for that party or to authenticate (verify the signature of) data coming from that party. A party’s Private Key is kept secret and used to authenticate (“sign”) data sent by that party, and to decipher encrypted data sent to that party. Symmetric Keys: An encryption or decryption key that is known only by authorized parties. Typically a secret key is used in symmetric key encryption technologies where two parties share the same secret key. User ID: A User ID is a unique character string (often an email address) or numeric value used by a system to identify a specific user.

4 Credential Use

Credentials are required for individual users, devices, and applications and are often used for authentication purposes, access control, integrity checking, and/or providing confidentiality. These credentials typically consist of a public/private key pair, a shared secret, some kind of hardware or software token, an individual password/passphrase, or a digital certificate. These credentials are used to assert the identity of an entity wishing to get authenticated to perform certain functions. At a high level, the domain industry has three general distribution models:

1. The registry operator interacts solely with registrars, who offer domain names to registrants. In this model each registrar is responsible for all interactions with its registrants.

2. The registry operator has registrars, but the registry operator also acts as a registrar. In this model each registrar is responsible for all interactions with its registrants.

3. The registry operator acts as the sole registrar for the TLD. The registry operator interacts directly with all registrants.

In addition, some registrars have resellers, which access the registrar’s system in order to create and manipulate domains in the registry on behalf of their registrants. Some companies that sell domain names to the public are fully accredited registrars for some TLDs and have direct access into those registries, and offer additional TLDs by acting as a reseller of another registrar that has direct access to those other TLDs. As a result, the access credentials that are used depend upon the role that an entity is fulfilling at a given time or for a given interaction.

14


SAC074

This table lists the most common credentials used in the domain name industry, the purposes for which they are used, and the parties who use them. Table 1: Various Credential Types, Their Purpose, and Who Uses Them Credential Purpose of Credential Entity Using

Credential Entity Validating or Storing the Credential

EPP AuthInfo code Initiate registrar-to-registrar transfer

Registrant, Registrar/reseller

Registry

Registrant username and password at registrar/reseller

Access to domains, DNS settings, payment methods, etc.

Registrant Registrar/reseller

Username/password and certificate for registry access

Gives registrar access to TLD registry. SSL certificate and encryption required for communication between the registrar's client system and the registry; authentication by user/password required for session establishment.

Registrar Registry

IP addresses Controls access to registry; access is restricted to known registrar IP addresses via address filters (Access Control Lists).

Registrar Registry

Payment credentials (credit card number and CVV code, etc.)

Payment for services Registrant Registrar/Reseller, payment processor

Registrar account funding credentials. May involve bank account numbers, credit card account details, etc.

Transaction accounts at registries; used each time the registrar performs a billable transaction.

Registrar, Registry

Registry, bank or payment processor

Registry-registrar security passphrases and service usernames and passwords.

Authenticate the registrar’s requests to registry tech support, finance department, etc.

Registrar Registry

Registrar-registrant - security passphrases, PIN values, and service usernames and passwords.

Authenticate the registrant’s requests to the registrar.

Registrant Registrar

Credentials for access to registry’s or registrar’s internal systems or hardware

Authenticate authorized individuals to internal resources.

Registry or Registrar

Registry or Registrar

15


SAC074

Privacy/proxy account Privacy/proxy services are designed to mask data about the registrant and other domain contacts so that it is not published in WHOIS. Data about the underlying contact is stored at the service provider, which may or may not be associated with the domain registrar.30

Registrant, Registrar, Privacy/proxy service provider

Registrant, Privacy/proxy service provider

DNSSEC Key-Signing Key (KSK)

A key that signs the set of all keys for a given zone, including itself

Registrants, Registrars and Registries


DNSSEC Zone-Signing Key (ZSK)

A key that signs data within a given zone



All credentials need to have a secure process for credential management regardless of their purpose. Compromise of any of the abovementioned credentials by someone with malicious intent could cause severe damage to the resources controlled by that entity. Attack vectors can include modifications to domain holder registration, DNS entries, transfer options and renewals, responsible contact information as well as billing information for credit card fraud or identity theft. Successful attack consequences include significant damage to brand reputation, financial implications as well as time costs required to investigate and rectify the damage.

5 The Credential Management Lifecycle Today

Credentials have a lifecycle for their initiation, maintenance and associated support.31 Credentials must be protected at all stages of this lifecycle, from creation to destruction. Each phase of the lifecycle has its own challenges, requirements, and recommendations. We discuss each phase as it is practiced by registrars and registries today: designing, creating, distributing, storing, changing, renewing, transferring, revoking, recovering, and destroying. Recently, some registries have allowed registrars to fund their accounts with the registry using credit cards, while others have created direct debit access methods. In these cases, registry operators must take special care regarding the holding and management of credentials associated with credit cards and banking information. In situations where Cardholder Data is involved, there are controls specifically prescribed by the Payment Card Industry Data Security Standards (PCI DSS) that must be met. PCI DSS provides a comprehensive baseline of credential management and security measures, and are updated by the major credit transaction networks (Visa, Mastercard, etc.) periodically in 30 For more about privacy and proxy services, see the work of the PDP Privacy & Proxy Services Accreditation Issues Working Group, at: http://gnso.icann.org/en/group-activities/active/ppsa 31 See http://www.idmanagement.gov/glossary/letter c.

16


SAC074

an attempt to compensate for changing attack methods and complexity.32 Many companies who regularly handle transactions involving credit cards go through extensive audits annually to attest that they are meeting these standards. Some registries have switched from a “deposit” account model (pre-pay) to a “credit” account model (post-pay). The post-pay model sometimes reduces the number of transactions that the registry has to account for from a security and credential management point of view, and also reduces some real-time dependencies of domain registrations on finance functions. Designing Credential design is the decision about how the registrar or registry will validate an identity including requirements and constraints on the validation mechanism. The design choices embody policy and risk decisions, sometimes based on assumptions rather than carefully considered choices. Choices made at the design stage directly impact possibilities at all other stages of the credential management cycle, so it is important to choose wisely. A wide variety of credential design practices are in use today. As demonstrated in Table 1 above, most registrants are identified by e-mail addresses or account IDs and are validated only through the use of passwords/passphrases. Registries validate registrar identities with a wider variety of credential types. In many cases one credential provides all access with no further checks. How long the user remains authenticated varies, but at some registrars the user can remain logged in for days. Human-generated and human-input passwords are being phased out as single factor authentication because, in general, they are no longer considered sufficient protection for a resource of even moderate value – they are either too easy to break or too hard to remember.33 A variety of programs for automated password generation and management34 are available, and already in use. These programs and applications are designed for use by end users and can help registrants keep track of and improve the security of their own credentials, but cannot be directly required by a registrar or registry. Based on the anecdotal information available, some registrars and registries have implemented stronger validation measures, such as two-factor authentication, source-IP-address validation, or manually verified keys. Two-factor authentication may be in the form of a short-lived one-time password (OTP). The OTP is either generated by a hardware token or software application, or sent to an enrolled mobile device. Allowing log-ins only from a pre-arranged set of IP addresses is a useful second factor. However, this relies on the integrity of global routing and IP-address delegation, which are not foolproof. Thus address validation by itself is not sufficient. Manually distributed and

32 See https://www.pcisecuritystandards.org/security standards/. 33 See Shimeall, T., & Spring, J. (2013). Introduction to Information Security: A Strategic-based Approach. Newnes. pg 130. 34 See http://lifehacker.com/5529133/five-best-password-managers.

17


SAC074

verified (i.e. carried by human courier rather than over the network) cryptographic keys provide a very high degree of assurance in the validation process. A special case to consider is how to authenticate an interaction that is not over the Internet, but still remote. Registrars and registries usually have a telephone number for serving users. On telephone conversations, cryptographic integrity is not readily possible, and passphrases must be used with requirements different from typed passwords (“choose a verbal passphrase with a number and a symbol in it” doesn’t really make sense). A pre-authorized list of contacts and their phone numbers is a technique some registries add when validating registrar personnel. Callback to a number on the list increases the strength of the authentication. Modification of names on the pre-authorized list is a tightly controlled process at some registries, while informal at others. Important factors in credential design decisions include the expertise of the staff, the operational budget, usability requirements, threats to the credential confidentiality, and costs incurred if threat actors succeed. However, no standard exists for password management. While most registries have basic security implemented, there are not regular audits of password management practices to update the practices as threats evolve. Creating Creating credentials is a complex process that involves more than just generating a shared secret. Other steps currently in use by some organizations include validating the authenticity of the creation request, assigning the credential to the appropriate user, and initiating the distribution and storage procedures that take integrity and confidentiality mechanisms into account. Registries and registrars enforce several policies at creation time. Creation time is when requirements on the shared secret are enforced. Policies for who or what may request a credential are also enforced, though the policies vary widely. Some registries require only that the registrant pass a “Completely Automated Public Turing test to tell Computers and Humans Apart” (CAPTCHA) as evidence of human creation. Other registries require the registrant to appear in person with certain government-issued identification. Registry authentication of a new registrar, or vice versa, is a process bound by international contract law, and thus rather rigorous. However, requesting a new account for an employee of a registrar or registry at another organization (e.g. a registrar employee account at a registry) may be as simple as a phone call or help-desk email with little formal authentication. Distributing Credential distribution means getting the credential to every person or process that needs to use it. The owner of the credential often is its creator, such as when a user selects a password or generates a public key certificate. Sometimes (part of) the credential is something about the user, such as their personal or organizational name, phone number,

18


SAC074

or IP address. A third party may create the credential, such as hardware OTP generators, and distribute relevant elements to each party. Each of these situations has unique considerations, but the most common tacit user expectation is that during distribution the credentials are protected by strong cryptography,35 including verification of message integrity, and that credentials are exposed as little as possible. Registrants, registrars, or even registries do not always meet this expectation. Passwords are often written down to distribute them to coworkers who share the same account (this is in itself bad practice – each person should have their own account for the role or relevant function). Paper and pencil distribution is not ideal, but it is far better than unsecured electronic distribution, over email or chat for example. As at creation time, each of the individuals receiving the credentials must somehow have their need for access validated. Shared credentials make this process harder to track, make auditing access/security events less effective and make revoking credentials for an individual intractable. Storing Users expect registrars and registries to store a protected version of the credential that does not reveal the credential if the file is read. For passwords, this means a one-way function that is unique to each user (formally, a salted hash function). There are no confirmed public cases of registries or registrars storing passwords incorrectly, although there are several confirmed instances of web content companies doing so.36 Computer-generated private keys can be stored by encrypting them with a key derived from a password/passphrase for extra protection (as in PGP [Pretty Good Privacy]). Problems arise when those who authenticate credentials cache valid credentials and/or a cookie representing the fact that the credential has been validated so users don’t need to constantly type in their passwords. Caching creates a time window during which an attacker can obtain the cached credential and use it. This vulnerability is particularly severe on Windows machines, where a family of attacks called “pass the hash” is prevalent. Multiple features of a networked Windows environment combine in such a way that the adversary can bypass the need to crack the password hash at all and just use the cached or stored hashed credential as a validation mechanism, bypassing legitimate authentication.37 Any credential storage scheme is vulnerable to credential caching attacks, however the attacks on Windows are particularly easy, well known, and exploitation code is freely available.38 Many registrants, registrars, and registries have vulnerable Windows machines being utilized for important management functions, increasing the risk of credential compromise. Regardless of the Operating System used for storing credentials, registries and registrars should be aware of

35 See Section 5.6. http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57 part1 rev3 general.pdf. 36 See http://www.dirmgr.com/blog/2012/6/12/how-linkedin-missed-out html. 37 See http://passing-the-hash.blogspot.com/2014/03/guest-post-lets-talk-about-pass-hash-by.html. 38 See https://community rapid7.com/Rapid7 BlogPostDetail?id=a111400000AajbcAAB.

19


SAC074

these kinds of issues and have mitigation plans in place to deal with a breach or compromise to these systems. Backing up key material is a special case of storage that is handled quite differently from usual storage. Backups of passwords/passphrases, private keys and secret keys need to be readable in an emergency. Therefore backups need to be stored offline or otherwise physically separated to minimize compromise. Not all registrars and registries separate backups in this way. Changing Changes to credentials are important events. Many registrars and registries have advised that they log when the user changes their password, and many send change notification messages. However, the credential change phase contains many opportunities for attack. Some controls implemented by some registrars and registries include:

• Automated and manual processes that monitor change logs for suspicious patterns as indicators of problems.

• Credential reuse policies.

• Multiple credential change mechanisms.

• Protection of information that can be used to change a credential at the same level of protection given to the credential itself.

Credential reuse prevents users from selecting the same password as their last password, or last 5 passwords, for example. There are anecdotal stories of users not understanding that “change” password meant switching to a different password, the user thought the act of password change somehow fixed compromised passwords by itself. Reuse limitations overcome this particular user education issue. Users change credentials with a variety of mechanisms, such as via a web session, via encrypted email, in person, or via the help desk. Each mechanism has challenges. For example help desk requests are sometimes hard to authenticate. Encrypted email can be hard to acknowledge in a different message channel, though text messages may work. Important information includes more than just the credential itself – it includes any information that may be used to validate an identity. Names, phone numbers, IP addresses, physical addresses, email addresses, security questions, and fax are used by registrars and registries in some combination to validate identities at least in some workflows, including recovery of credentials. These information items, or some subset of them, can be used to gain control of an identity. Renewing Renewing credentials is similar to the changing phase, except that a credential renewal is a change required by the service provider after a certain amount of time. The amount of time specified by the service provider policy varies widely. Some registrars never require

20


SAC074

a credential renewal. Some registrars and registries require credentials to change as often as every 90 days. The frequency of change that is advisable varies with the credential type selected during the design phase. Stronger credentials, such as hardware tokens and cryptographic certificates, need to be changed less frequently. Transferring Registrars and registries in gTLDs and many ccTLDs have policies that registrars must transfer sponsorship of a domain at the request of the registrant. This requirement presents credential management challenges. Therefore the EPP registry-registrar protocol offers a means by which one party can pass identity validation information to another. As prescribed by ICANN's Inter-Registrar Transfer Policy,39 all gTLD registries use EPP.40 A valid EPP AuthInfo code41 is required to initiate a registrar-to-registrar transfer (see Section 3 for more about AuthInfo codes). Many registrars change a domain’s AuthInfo code after the domain has been transferred. ICANN policy also contains provisions for revoking improperly requested transfers. Registrars can use revocation procedures to recover from situations in which an AuthInfo code was obtained or used improperly and leads to a domain hijacking. In order to deter hijacking some registrars also have an optional process of domain locking. If a domain is locked transfer requests are rejected unless the registrant provides out-of-band instruction to unlock the domain.42 However, these policies may not always be implemented, and some registrars have reportedly used registrant account passwords as AuthInfo codes. Additionally, registrars must protect the AuthInfo codes they assign and receive. There are unconfirmed reports of hackers using AuthInfo codes for domain hijacking. Revoking There are multiple scenarios in which a registry or registrar revokes a credential. Revoking is not the same as destroying – a revoked credential is actively removed from credential caches, active sessions terminated, and the use of the credential blocked as quickly as possible. Revocation commonly occurs when credentials are determined to have been compromised, are changed (the old credential may be revoked after the new one is installed), or personnel leave the organization. Common structures in use for revoking credentials include revocation lists such as certificate revocation lists (CRL).43 The authentication system Kerberos (Microsoft Active Directory and many open source solutions use Kerberos44) has an account lockout function, but no explicit credential

39 See https://www.icann.org/resources/pages/policy-transfers-2014-07-02-en. 40 See http://icannwiki.com/EPP. 41 See RFC 5731 at https://tools.ietf.org/html/rfc5731. 42 See http://icannwiki.com/Domain Locking. 43 See http://tools.ietf.org/html/rfc5280. 44 See http://www kerberos.org/software/whykerberos.pdf.

21


SAC074

revocation function besides destroying an account,45 which makes this function difficult for some organizations to execute in short time frames. When personnel turn over at registrars, registries, or corporate registrants the departing person sometimes provides all access information to their successor. The successor rarely changes the credentials, which allows for the former employee to potentially still have access to the registrar account. Recovering Credential recovery occurs when a user has forgotten their user ID, password, or other credential material. These recovery processes vary among different registrars, but often they are simply a link sent to the account's registered e-mail address, a predefined password hint provided by the Registrant, or a series of security questions and answers. Additionally, registrars who provide telephone support may also have a mechanism that allows someone to access the account with a combination of passwords, call-in personal identification numbers (PIN), or by providing the last few digits of the credit card or payment method on file for the account. While such a process is necessary, this process is a likely target for attacks attempting to gain unauthorized access. In particular, there does not appear to be wide awareness of the dangers of using email (which relies on proper functioning of the DNS) to verify elements of DNS functionality. If attacks are successful, as described above, the attacker gains the ability to change nearly anything relating to the domains and the domain management account. This might include the registrant name, contact information, password, PIN, payment profile or billing information, and even the two-factor authentication elements. Destroying Destroying a credential is the end of its lifecycle. Registrars and registries have different processes for credential destruction that approximately follow these steps. The credential file and any information associated with the account or account validation is delinked, i.e. deleted. Many registrars write junk to the credential file on disk, and then delete it to make sure digital forensics could not recover the file from the disk. Some organizations treat hard drives that have stored credential information as sensitive and physically shred or degauss the drives when they are retired. Registrars and registries try to be careful to remove all copies of credential information from their systems during destruction. Not all registrars and registries agree as to which information is sensitive enough to warrant destruction, but some agree that anything used in any phase of the credential lifecycle, including information used in recovering, transferring, or renewing, should be destroyed carefully. 45 See http://web mit.edu/kerberos/krb5-1.13/doc/admin/lockout html.

22


SAC074

6 Practical Checklist / Credential Management Best Common Practices

There are practical improvements that can be made to all stages of the credential management lifecycle. We present these overall considerations for implementing best current practices for each stage in the lifecycle in the same order the stages were presented in the prior section. Familiarity with SAC40’s and SAC44’s recommendations will help the reader contextualize this report, however reading them is not necessary to make use of the recommendations presented here. Refer to Established Best Practices First, SSAC recommends that registries and registrars refer to community vetted and standards-based documents since these are well defined and continuously evolving to what the information security community believes to be best current practices. These documents address security controls in a methodical and holistic approach and cover much more than just credential management. The specific sections that pertain to credential management are highlighted.

• The Critical Controls46 are a recommended set of actions for information security defense that provide specific and immediate high-value actionable ways to stop today's most pervasive attacks. They were developed, vetted and are maintained by a consortium of hundreds of security experts from across the public and private sectors.

• Registrars and registries should refer to the ISO 27000 family of standards, which help organizations keep information assets secure.

• ISO/IEC 27001 specifies requirements for an information security management system (ISMS). This standard includes risk assessment and a list of security controls and their objectives.

• ISO/IEC 27002 provides best practice recommendations on information security management for use by those responsible for initiating, implementing or maintaining ISMS. This standard includes access control, operational security, and communications security.

• Registrars and registries that take credit card information from users should refer to the controls specifically prescribed by the PCI DSS. PCI DSS47 provides a comprehensive baseline of relevant credential management and security measures.

The following sections of the PCI DSS specifically pertain to aspects of credential management and cover in detail aspects of password length, strength, rotation, session timeouts, incorrect login attempts, minimum necessary access, etc.

46 See http://www.counciloncybersecurity.org/critical-controls/. 47 See https://www.pcisecuritystandards.org/documents/PCI DSS v3-1.pdf.

23


SAC074

• Requirement 8: Identify and authenticate access to system components

• Requirement 3.2: Credential Storage

• Requirements 3.5 – 3.7: Cryptographic Key Management Multi-Factor authentication remains a key element in efforts to establish a more secure environment. There are many variations on how and when a multi-factor model could be implemented, but many web application environments could benefit from the proper implementation of such a methodology.

• The World Wide Web Consortium (W3C)48 group is publishing a guide to help implement strong multi-factor authentication.

Designing Attacks cannot be completely prevented, so design should include risk assessment and incident response plans.49

• Consider implementing a carefully designed multi-factor authentication system. One option is to send text messages containing a PIN to a customer-authorized mobile phone number.

• Encourage security-minded credential management, including adequate requirements for:

o password length and strength,

o password expiration, and o password recovery.

• Decide how much access the user has once authenticated, and how long until the credential needs to be validated again. These design decisions should follow basic security principles of providing the least access and least privilege while still permitting the user to perform the task. This includes requiring a user to re-authenticate to do important tasks and having a relatively short inactivity timeout once logged in (15 to 120 minutes). Such a design makes abuse and compromise harder for an adversary and easier for the registrar or registry to detect.

• Create and implement an abuse and fraud detection plan. For example, registrars can monitor DNS activity in order to reduce current attacks such as domain shadowing.

• Create and implement an incident response plan.

48 See http://www.w3.org/Security/. 49 See http://www.cert.org/incident-management/csirt-development/csirt-faq.cfm?.

24


SAC074

Creating Credential creation involves trust in policies and procedures that cannot be completely tamper-proof. The risk must be managed, as it cannot be eliminated. Checks and audits to detect misuse are critical. Creation time is when requirements on the shared secret are enforced. Password requirements should include:

• minimum length (as high as 14-character minimum)

• character type mixtures (letters, symbols, and numbers)

• prohibitions against repeated characters

• no password re-use

• whether the password is in a commonly used password-cracking table (and thus easily guessable), and

• history of recently used passwords. There are common creation-time requirements for cryptographic credentials as well, such as their intended lifetime, how large (in bits), and key protocol. Distributing and Using Credentials must be protected while they are distributed to or used by the authorized parties. Protections include:

• Transmitting only over an encrypted channel such as Hypertext Transfer Protocol Secure (HTTPS) or Secure Shell (SSH)50 between any pair of machines that handle the credentials.

• Authorized parties should be limited as much as possible to single individuals. Where multiple individuals share a role, they should still obtain unique credentials in order to better track abuse or misuse, and to simplify reassignment of credentials when only one employee of those with the shared role no longer requires access.

• Attempts to brute-force attack password-protected user accounts by supplying entries from a list of commonly used passwords should be detected and mitigated.

• The values of supplied passwords (and incorrect attempted passwords) should not be recorded in logs.

50 See NIST SP [[need to look up pub number]] for specifications on what is considered a strong algorithm and key size for a safe encrypted channel.

25


SAC074

Storing (including backing up) Credentials need to be stored in a way that minimizes the risk of revealing them to adversaries during the credential’s lifetime.

• Passwords/passphrases, private keys, or secret keys should never be documented in places where this information may be compromised, such as in debug logs, wikis or trouble tickets.

• Any storage of a credential should be as a protected version so that the credential is not revealed if the file is read. Proper protection methods include encrypting the data, employing proper authentication protocols, and using one-way functions (salted hashes or bcrypt) when possible so the cleartext cannot be easily recovered. Storing hashes on disk properly is not enough; the credential manager needs to store credentials properly during all phases of their use.

• When a credential is used or validated, the validator should store it in memory for as little time as possible, and zero the memory when done.

• Backups need to be stored offline or otherwise physically separated to minimize compromise. Backups can themselves be encrypted with one master backup key. This master key needs to be physically protected and highly guarded when in use.

• Registries and registrars should have clear policies and procedures for storing or backing up credentials.

Changing No matter where a credential is changed, there are four steps that registrars and registries should perform: validate, install, acknowledge, log.

• Any change request must be validated. The user requesting the change must be a validated, authentic user who is allowed to request the change.

• The new credential is installed, following all the good practices used during the credential creation phase.

• The change is acknowledged via a message to the user in a medium different from that used to change the credential and not relying on the credential just changed; this step is important in the case where the genuine user did not in fact make the change request as well as in general customer relations to confirm the change succeeded.

• Finally the change (but not the value of the new credential) is logged.

• Such controls should be applied to all information items that can be used to steal an identity, not just strictly the credentials. Other important information items include names, phone numbers, IP addresses, physical addresses, email addresses, security questions, and fax numbers.

26


SAC074

• Registrars and registries should employ credential reuse restrictions. Reuse restrictions strengthen credentials, especially passwords, because a credential weakens significantly if used in multiple places or over a long time.

• A registrar or registry should notify its customers of a breach once detected.

• If credentials or the credential management system may have been compromised, customers should be contacted and advised to change their credentials.

• Customers should be able to confirm or authenticate breach notices, since some may mistake authentic breach notices for phishing attacks. Breach notices should also be placed on the registry’s or registrar’s web site, and on social media, so that customers can obtain confirmation of the incident in an independently verifiable way.

• Breach notification emails should be sent from a trusted and recognizable domain name, should be PGP-signed, and the password change service should be on a known site.

Renewing During the design phase, select a frequency for which customers must renew or change their credentials. Stronger credentials, such as hardware tokens and cryptographic certificates, need to be changed less frequently. Transferring Registrars and registries are required to follow ICANN's Inter-Registrar Transfer Policy for handling AuthInfo codes (see Section 5 of the policy). Revoking Registrars or registries should revoke credentials under three circumstances:

• when credentials are compromised;

• when credentials must be renewed (old credential is revoked); and

• when personnel change roles or depart the organization. Personnel turnover should result in automatic credential termination by use of individual logins, along with hardware tokens retrieved on employee termination or, where appropriate, OTPs sent in text messages as a second factor.

Since cached credentials cannot be revoked, registrars and registries should set short cache times. Web sessions or other interactive log-ins should be actively terminated, and credential revocation should propagate quickly through any distributed authentication system. (One way to handle session termination is to routinely check whether a password change has happened during an active session.)

27


SAC074

Recovering Registrars and registries should increase internal awareness that credential recovery processes are common targets for adversaries.

a. Password recovery processes for registrants require special consideration because a domain name can be used to redirect email sent to the domain. It is not safe to send credential recovery instructions for a domain to an email address within that domain. This special problem requires extra attention to the credential recovery process at registrars and registries.

b. Email accounts may expire due to infrequent use, or the expiration of the associated domain name. An adversary can access affected accounts and use the “forgot” process to change the password for domain management.

c. Registrars should pay attention to non-delivery notices for email sent to email accounts.

Destroying Destroying credentials is the last stage in the credential management lifecycle.

a. Credentials, and any information that can be used to recover or create credentials, should be destroyed when no longer needed.

b. Destruction should include overwriting the relevant file with junk, or destroying the physical storage media (if practical) to deter digital forensics. Hardware used to store and process credentials should also be shredded or degaussed when it is time for disposal.

c. If the credential to be destroyed is the only way to obtain access to important files, either live or backed-up, those files either need to be destroyed themselves or transferred to a different credential so that the total destruction of the credential can be completed.

d. Registrars and registries should have well-formed processes to ensure that all copies of a credential are destroyed during this phase, including any backups.

7 Recommendations

SSAC makes the following recommendations to ICANN: Recommendation 1: As part of regular reports, the ICANN Compliance Department should publish data about the security breaches that registrars have reported in accordance with the 2013 RAA, paragraph 3.20. 51

51 See https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#3.20.

28


SAC074

We do not, at this time, recommend whether registrars' names be published or not. However, we do recommend that statistics about the number of breaches and the number of registrars affected, the aggregated number of registrants affected, and the high-level causes of the breaches, including specifying which breaches could be attributed to a problem in the credential management life cycle would be illuminating to the community and will emphasize the need for good security measures to be followed by registrars. We believe that this data can be appropriately anonymized, and still be a useful way to provide better information to the Registrar community as to the nature of the threat landscape. We observe that the term ‘security breach’ in the 2013 RAA is defined as ‘any unauthorized access to or disclosure of registrant account information or registration data.’ It would be helpful in the reported data and any statistical summaries to distinguish between, on the one hand, breaches of registrar systems or unauthorized release of data by the registrar itself, and, on the other hand, unauthorized access or disclosure due to individual registrants losing control over their credentials in a way not attributable to their registrar's systems or controls. Recommendation 2: A provision similar to 2013 RAA paragraph 3.20 should be incorporated into all future registry contracts, with similar statistics to be published as per Recommendation 1 above. Recommendation 3: Future RAA deliberations should encourage stronger authentication practices, specifically the use of multi-factor authentication. Recommendation 4: The ICANN Board should direct ICANN staff to facilitate global hands-on training programs for registrars and registries based on the best practices outlined in Section 6 of this document, with the goal to enable parties to learn practical operational practices for preserving security and stability of the credential management lifecycle. We would welcome the opportunity to advise training staff in the creation of a curriculum.

This effort should involve measurement and outreach including cooperation with other global training efforts with ICANN partners such as ISOC. ICANN should support this effort with adequate staffing and funding. Such a program should cover at least the following topics:

• Create a training program that follows the structure of the DNSSEC Deployment Initiative but that is focused on hands-on training of operational practices that provide best security practices for the credential management lifecycle.

• Create and maintain an information portal, managed by ICANN staff, supported by community subject-matter expert contributions, and with links to educational material.

• Provide an annual report on the work accomplished.

29


SAC074

8 Acknowledgments, Disclosures of Interest, Dissents, and Withdrawals

In the interest of transparency, these sections provide the reader with information about four aspects of the SSAC process. The Acknowledgments section lists the SSAC members, outside experts, and ICANN staff who contributed directly to this particular document. The Disclosures of Interest section points to the biographies of all SSAC members, which disclose any interests that might represent a conflict—real, apparent, or potential—with a member’s participation in the preparation of this Report. The Dissents section provides a place for individual members to describe any disagreement that they may have with the content of this document or the process for preparing it. The Withdrawals section identifies individual members who have recused themselves from discussion of the topic with which this Report is concerned. Except for members listed in the Dissents and Withdrawals sections, this document has the consensus approval of all of the members of SSAC.

8.1 Acknowledgments

The committee wishes to thank the following SSAC members and external experts for their time, contributions, and review in producing this Advisory. SSAC Members Greg Aaron Jeff Bedser Don Blumenthal Ben Butler KC Claffy Merike Kaeo Mark Seiden Doron Shikmoni Julie Hammer Ram Mohan Rod Rasmussen ICANN staff Julie Hedlund Kathy Schnitt

8.2 Disclosures of Interest

SSAC member biographical information and Disclosures of Interest are available at: https://www.icann.org/resources/pages/ssac-biographies-2015-06-15-en

30


SAC074

8.3 Dissents

Mark Seiden has provided this dissent: As an active member of this work party, I regret dissenting with this report's recommendations. As a whole they fall short of recommending that the ICANN Board require any basic technical protection for parties whose credentials have been breached. The current recommendations do little harm, but miss the opportunity to go far enough to be useful in addressing actual breaches. A credential holder needs to find out about (e.g.) the loss of a password (the best known example of a static credential) so they can manage their own risk after the breach, usually by changing the password. The same breached password might be used, for example, by a reseller or a registrant at a multiplicity of registrars, or by a registrar at a multiplicity of registries. So the password may need to be changed in lots of places. If not informed of a breach, there is significant risk of loss of valuable assets, direct operational impairment, and consequential damage. Two practical mechanisms for finding out about such breached credentials are - direct notification by the party who became aware of the breach and - publication of the details of the breach with adequate specificity. Though noting that notification to credential holders of loss of their credentials is a best practice, this report does not go so far as to recommend that ICANN require prompt notification to credential holders by all Contracted Parties who become aware of such a loss, and, further, to require that business associates of Contracted Parties (such as resellers, vendors, subcontractors, privacy protection services) be similarly contractually required to take action of a sort resulting in prompt notification to the holder of the breached credential. Paradoxically, many data breach laws already require notification and (in many cases) publication of applicable breaches, so an ICANN contractual requirement for breach notification (unless inconsistent with applicable law) would likely not be surprising to many. It would beneficially clarify the need in cases where certain kinds of valuable breached credentials are not covered by particular data breach laws (cryptographic keys, and other shared secrets, for example, may not be mentioned in laws which typically have focused on Cardholder Data, and Personal Information breach which can result in identity theft). The recommended aggregated statistical information should be of use to analysts, but does not inform credential holders whose accounts are compromised. Absent a contractual requirement to promptly notify, the prompt publication of breach details could serve a similar purpose if specific enough so cardholders could identify that they are among the affected group.

31


SAC074

- The Work Party has not determined what use ICANN makes of the breach reports they receive under section 3.20 of the RAA, but has been told that when past reports were supplied by registrars there might be an expectation that data reported would be kept in confidence by ICANN. My opinion is that an excess of sensitivity to this mere possibility has weakened Recommendation 1. My additional recommendation to the Board is that ICANN publish full breach details starting as soon as this becomes possible, and if needed to notify contracted parties to adjust their expectations that this will soon occur, thus eliminating any future expectation of privacy in the interests of transparency about misfeasance or operational failure. - Due to lack of time, this report is incomplete in some areas which, in my opinion, would have been better included than omitted in a document intended to be definitive. While these omissions are not worthy of a dissent on their own, I will mention them now in passing as possible future work areas: The report does not currently cover in enough detail the use and flow of credentials in contexts beyond the expected Registrant, Registrar and Registry (including addressing critical parties such as resellers, privacy proxies, operators of DNS and DNSSEC services), and there is no recommendation addressing the possibility of those parties mishandling credentials. The report does not discuss any requirements for Contracted parties to provide transparency in credential management or other security practices (of the sort one would find in a Certificate Authority's Certificate Practice Statement.) To summarize: We start out, and are left with a lamentable situation where a registrant (for example) may not be reliably able to determine how their credentials are handled and, even worse, even after a breach, may not reliably find out that their credentials are compromised.

8.4 Withdrawals

There were no withdrawals.

32


SAC074

Appendix A: Glossary of Terms

A quick reference guide for terms used in the documents. Where possible, definitions from authoritative sources are used.

• Access Control – The prevention of unauthorized use of a resource, including the prevention of use of a resource in an unauthorized manner.

• Asymmetric Key Pair – A cryptographic key pair that is utilized in asymmetric algorithms.

• Authentication – The process of verifying a claim that a system entity or system resource has a certain attribute value.

• Authorization – An approval that is granted to a system entity to access a system resource.

• Biometric Authentication – A method of generating authentication information for a person by digitizing measurements of a physical or behavioral characteristic, such as a fingerprint, hand shape, retina pattern, voiceprint, handwriting style, or face.

• CAPTCHA – a program that protects websites against bots by generating and grading tests that humans can pass but current computer programs cannot (http://www.captcha.net/); stands for “Completely Automated Public Turing test to tell Computers and Humans Apart.”

• Cleartext – Any information that is not encrypted.

• Credential – Data that is transferred to establish the claimed identity of an entity.

• Credential Management – Refers to maintenance of a credential from the time it is created to the time it is destroyed.

• Digital Certificates – Data structures that bind a public key to the identity of a process or system as verified and signed by a trusted entity.

• Domain AuthInfo Code – The AuthInfo code is a secret code shared between a registrar and a registrant with which a registrar initiates the transfer of a domain name to another registrar while preventing unauthorized domain transfers. Use is required by ICANN's Inter-Registrar Transfer Policy. (See also EPP.)

• Domain Name – Officially, the list of the labels on the path from a node to the root of the domain name space tree (RFC 1034, p. 6). For the purposes of registrant protection the domain name is the label under the stewardship of a registrant that is acquired from a registrar. Determining this transition label programmatically in a fully-qualified domain name currently has challenges (see SAC-070).

• EPP (Extensible Provisioning Protocol) – A protocol that provides

33


SAC074

communication between domain name registries and domain name registrars whenever a domain name is registered or renewed. See RFCs 5730-5734. All registries under ICANN contract use EPP.

• Encryption – A method of scrambling information in such a way that it is not readable by anyone except the intended recipient(s), who must decrypt it to read it (synonymous with Encoding).

• Hash Function – A mathematical computation that results in a fixed-length string of bits from an arbitrary size input; a one-way hash function is not reversible to produce the original input.

• Integrity – Assurance that the data has not been altered except by people who are explicitly intended to modify it.

• Multi-factor authentication – An authentication method using more than one factor, where factors are classes of authentication tests such as "a thing one knows," "a thing one has," or "a thing one is" (see also password, crypto token, biometrics, authentication).

• OTP (One Time Password) – an authentication technique in which each password is used only once as authentication information that verifies an identity. This technique counters the threat of a replay attack that uses passwords captured by wiretapping.

• Passphrase – A sequence of words or other text used to control access to a computer system, program or data.

• Password – A protected, private character string used to authenticate an identity.

• Phishing attack – A technique for attempting to acquire sensitive data, such as bank account numbers, through a fraudulent solicitation in email or on a Web site, in which the perpetrator masquerades as a legitimate business or reputable person.

• PIN (Personal Identification Number) – A numeric password shared between a user and a system, which can be used to authenticate the user to the system.

• Private key – A digital code used to decrypt information and provide digital signatures. This key should be kept secret by its owner; it has a corresponding public key.

• Public key – A digital code used to encrypt information and verify digital signatures. This key can be made widely available; it has a corresponding private key.

• PKI (Public key infrastructure) – The set of hardware, software, people, policies, and procedures needed to create, manage, store, distribute, and revoke digital certificates based on asymmetric cryptography.

• Secret Key – A digital code that is shared by two parties; it is used to encrypt and decrypt data.

34


SAC074

• Spear Phishing – A phishing attack that is specifically targets an organization, department or individual.

• User ID – A unique character string or numeric value used by a system to identify a specific user.

• Watering hole attack – An attack against targeted businesses and organizations. In a watering hole attack scenario, threat actors compromise a carefully selected website, known to be used by the business or organization, by inserting code resulting in malware infection of those accessing the website.

35


SAC074

Appendix B: TLD Registry Breaches

.EDU In early 2013, an initial breach was discovered via the discovery of email redirection of all MIT.edu email to a RIPE IP address. The alleged target of the redirection was email traffic related to government research projects. The registry database was compromised, and the registry operator sent breach notifications to all registrants, asking them to change their passwords. 52 Due to the compromise of the registrant database, it was alleged that attackers had the ability to modify all DNS and account details to all .EDU domains for an undisclosed period. .RO Attackers hijacked the .RO domains of Google, Microsoft, Yahoo, and others. Allegedly the DNS records for the affected domain names were modified as a result of a security breach at the RoTLD domain registry, which manages the authoritative DNS servers for the entire .RO domain space. A compromise of the RoTLD Web system used by .RO domain name owners to administer their domains, or the registry's DNS servers, is one of the possibilities. This incident was also alleged to be a possible DNS poisoning attack. A Microsoft report by Cynthia Kern and Nick Whitworth in April of 2013 indicated that twelve TLDs were successfully hacked since November 2012. 53 .PY The .PY (Paraguay) registry was compromised on February 20th, 2014. Hackers allegedly from Iran accessed and modified the www.NIC.py database, redirecting www.google.com.py to another site. The hackers posted the entire NIC.py database54 containing contact names, national ID numbers, street addresses, phone numbers, and more registrant details. In this instance, the hack was done by exploiting a simple remote code execution55 vulnerability. This is not the first time56 that NIC.py, managed by the two most respected Computer Science Universities of Paraguay, was hacked. .PK

52 See: http://www.educause.edu/educause-security-breach-and-password-change-information. 53 See: http://ccnso.icann.org/files/38133/presentation-cctld-security-assessments-kern-whitworth-08apr13-en.pdf. 54 See: http://cker.ir/leak/nic-py/. 55 See: http://ha.cker.ir/2014/02/www-nic-py-py-registrar-rce-vulnerablity/. 56 See: http://www.abc.com.py/nacionales/confusion-con-antiguo-hackeo-1217054 html

36


SAC074

The .PK (Pakistan) registry was allegedly compromised by the same group that allegedly compromised .RO. A PKNIC SQL vulnerability (PKNIC is the Pakistani (.PK) domain name registry) may have allowed hackers from Turkey to hack into .PK domains registered by Google, Yahoo, and MSN, plus nearly 300 other sites. The Turkish hackers also defaced the Google Pakistan homepage. .TC, .GD, .VG The “Adamsnames incident” in 2013 allegedly arose out of a business dispute between parties administering services for the .TC, .GD, and .VG registries. See: “KSRegistry has been appointed the new registry operator for Grenada’s ccTLD after bad management at the previous operator led to the whole TLD being hijacked.”57 A hasty switch-over followed the alleged wholesale hijacking of the ccTLDs58 by a disgruntled former employee of AdamsNames, who temporarily relocated it from the UK to Turkey. The TLDs went offline in March after the former employee apparently took over the domain AdamsNames.net, the web site which was used by registrants to manage their names. Registry Security Vulnerabilities Exposed With 23 registry security breaches in this last year, the number of incidents reached an all-time high. Popular ccTLD registries such as .CN (China), .BE (Belgium) and .MY (Malaysia) were all impacted by issues arising from Distributed Denial of Service (DDoS), Social Engineering and Brute Force attacks (source Mark Monitor).

57 See: http://domainincite.com/12916-ksregistry-takes-over-gd-but-questions-remain-about-two-other-hijacked-cctlds. 58 See: http://domainincite.com/12238-confusion-reigns-over-three-hijacked-cctlds

37


SAC074

Appendix C: Previous SSAC Report References

A number of previous SSAC Reports have examined issues related to the protection of registrant data and offered recommendations for better practices by registrants, registrars and resellers. SAC040 “Measures to Protect Domain Name Registration Services Against Exploitation or Misuse”59 (19 August 2009) examined a number of high profile incidents involving domain name registration accounts to determine if there were common causes among the events that might reveal measures to reduce or mitigate certain threats and vulnerabilities. The report examined the incidents in sufficient detail to identify how accounts were compromised, the actions attackers performed once they had gained control of the account, and the consequences. The report presented security measures used in other Internet business segments (e.g., financials, durable goods merchants) to protect customers from similar vulnerabilities. It identified practices registrars can share with customers so that registrar and customer can jointly protect registered domains against exploitation or misuse, and discussed methods of raising awareness among registrants of the risks relating to even a temporary loss of control over domain names and associated DNS configurations.

It also identified vulnerabilities as well as policies and practices (business and operational) that were exploited to see whether a common thread might emerge.

SAC044 “A Registrant’s Guide to Protecting Domain Name Registration Accounts” (5 November 2010)60 attempted to catalog measures that registrants should consider to protect their domain name registration accounts and the domain names managed through these accounts. The report described the threat landscape for domain names, and identified a set of measures for organizations to consider. It also considered risk management in the context of domain names so that an organization can assess its own risk and choose appropriate measures.

The problems identified in these reports can be summarized as follows:

Passwords. Enforcement of strong passwords and regular password rotation is not widely undertaken by registrants or enforced by registrars. Additionally, password reset and recovery procedures are frequently vulnerable to exploitation.

59See: https://www.icann.org/en/groups/ssac/documents/sac-040-en.pdf. 60See: https://www.icann.org/en/groups/ssac/documents/sac-044-en.pdf.

38


SAC074

Predictable Processes. Simple and predictable processes governing the registrar-registrant interactions can provide opportunities for attackers to intervene and exploit those processes to deceive both registrar and registrant. Authentication. Not all registrars offer strong two factor authentication (2FA) and in some cases where they do, it is not implemented correctly. Similarly, device verification is not widely deployed. Contact Email Accounts. Simple and singular approaches to the use of contact email accounts provide opportunities for exploitation by attackers. Responsible Contacts. Identification of one or more individuals as ‘responsible contacts’ can cause problems when those individuals are absent, or no longer associated with the domain. 3rd Party Access. Registrants can on occasion allow 3rd party access to registration data or to the account itself thereby increasing the risk of compromise or exploitation, especially should a dispute arise.

Implementation Recommendations for SSAC Advice Document SAC074


Recommendation Description ICANN’s Statement ofUnderstanding

Background on the Issue ICANN OrganizationImplementation

Recommendation &proposed implementation

plan

Rationale for ImplementationRecommendation

1 As part of regular reports, theICANN Compliance Departmentshould publish data about thesecurity breaches that registrarshave reported in accordance withthe 2013 Registrar AccreditationAgreement (RAA), paragraph 3.20.

ICANN’s Contractual Compliancedepartment should provideregularly updated data aboutsecurity breaches reported inaccordance with the 2013 RegistrarAccreditation Agreement (RAA),paragraph 3.20. This data shouldinclude statistics about the numberof security breaches, the number ofregistrars affected, the aggregatenumber of registrants affected, andthe high-‐level causes of thebreaches. The SSAC does notrecommend at this time whetherspecific registrars' names should bepublished.

The SSAC advisory states, attacksthat compromise registrant dataand/or the DNS settings of domainnames continue to be a significantproblem for registrars and registries,as well as for the registrantsthemselves and the users of theirsites.The 2013 Registrar AccreditationAgreement (RAA) requires registrarsto disclose certain informationregarding security breaches to ICANNContractual Compliance. HavingICANN org provide appropriatelyanonymized reporting regardingsecurity breaches at Registrars will bea useful way to provide betterinformation to the Registrarcommunity as to the nature of thethreat landscape.

Implementation isrecommended.

The Contractual Compliancedepartment will add therequested data to its existingpublic reporting.

This request is within the remit of theICANN Org and the data is available tothe organization based on theprovisions in the 2013 RAA. TheContractual Compliance team has thedata tools, and resources necessary topublish the requested reporting.Implementation can be achieved withthe existing FY19 Budget for theContractual Compliance department.

2 A provision similar to paragraph3.20 of the 2013 RegistrarAccreditation Agreement (RAA)should be incorporated into allfuture gTLD Registry Agreements,with similar statistics published(e.g., about the number ofbreaches, the number of registrarsaffected, the aggregate number of

Our understanding of this advice isthat a provision similar toparagraph 3.20 of the 2013Registrar Accreditation Agreement(RAA) should be incorporated intoall future gTLD RegistryAgreements, with similar statisticspublished (e.g., about the numberof breaches, the number ofregistrars affected, the aggregate

The Registrar AccreditationAgreement contains provisions thatrequire Registrars to reportinformation to ICANN regardingbreaches to their systems, but theRegistry Agreement does not. TheSSAC is identifying this gap, andrequesting ICANN to require RegistryOperators to do the same level of

Implementation will beattempted.

The ICANN Org will includethis in the proposed changesto the registry agreementduring the next bilateralnegotiation.

The SSAC advises this requirement willcontribute to better security andstability in the DNS. Ensuring andimproving the security and stability ofthe DNS is within ICANN’s remit.There would be no impact to thebudget to pursue the proposedimplementation plan.

Recommendation Description ICANN’s Statement ofUnderstanding

Background on the Issue ICANN OrganizationImplementation

Recommendation &proposed implementation

plan

Rationale for ImplementationRecommendation

registrants affected, and the high-‐level causes of the breaches).

number of registrants affected, andthe high-‐level causes of thebreaches).

reporting and disclosure regardingany system breaches.

3 Future RAA deliberations shouldencourage stronger authenticationpractices, specifically the use ofmulti-‐factor authentication

Our understanding of this advice isthat for future versions of theRegistrar Accreditation Agreement(RAA), ICANN should advocate thatregistrars are committed tostronger authentication practicesthan those which they arecommitted to in the 2013 RAA,specifically the use of multi-‐factorauthentication.

The SSAC advisory states, attacks thatcompromise registrant data and/orthe DNS settings of domain namescontinue to be a significant problemfor registrars and registries, as well asfor the registrants themselves andthe users of their sites. The advisorygoes on to sayMulti-‐Factorauthentication remains a key elementin efforts to establish a more secureenvironment. Their recommendationis to encourage strongerauthentication practices byregistrars, and to consider doing sovia the RAA.

Implementation will beattempted.

ICANN Org will request theRegistrars to considercontractual requirementsrelating to theauthentication practices ofregistrants in a future roundnegotiation of the RegistrarAccreditation Agreement.

The SSAC advises that multifactorauthentication will contribute toenhanced security and stability forregistrants and thus the DNS.Ensuring and improving the securityand stability of the DNS is withinICANN’s remit. There would be noimpact to the budget to pursue theproposed implementation plan.

4 The ICANN Board should directICANN staff to facilitate globalhands-‐on training programs forregistrars and registries based onthe best practices outlined inSection 6 of this document, withthe goal to enable parties to learnpractical operational practices forpreserving security and stability ofthe credential managementlifecycle.

Our understanding of this advice isthat ICANN staff should facilitatetraining programs for registrars andregistries relating to the credentialmanagement cycle. These trainingsshould focus on the best practicesoutlined on SAC074. We note theSSAC's offer to provide input toICANN's development of thetraining curriculum.

The SSAC advisory goes intosignificant detail of the credentialmanagement lifecycle in the registry,registrar, registrant ecosystem, andprovides a series of best commonpractices. They advice ICANN todevelop and provide hands ontraining for registries and registrarson these practices in the name ofregistrant protection.

Implementation isrecommended.

The Global Domains Divisionwill provide the requestedtraining. The training wouldlikely occur at a future GDDSummit or ICANN meetingand be recorded for futureuse.

The purpose of Global DomainsDivision (GDD) is to serve the globalpublic interest, the registrants andend users of the Internet by ensuringa secure and stable domain namesystem (DNS), while promoting trust,choice, and competition in the trusteddomain name service industry.Providing training to the contractedparties to help protect registrants isconsistent with the stated purpose ofthe GDD. The training can bedeveloped and provided byprioritizing the activity with theexisting FY19 Budget request.

Renewal of .MUSEUM Registry Agreement

ICANN BOARD MEETING (Los Angeles, February 4, 2018)

TITLE: Renewal of .MUSEUM Registry Agreement PROPOSED ACTION (select): Board Resolution

TOPIC LEADER: Chris Disspain

STAFF IN SUPPORT: Akram Atallah

TIME REQUESTED: Consent Agenda

FRAMING THE ISSUE:

The .MUSEUM Registry Agreement with Museum Domain Management Association(“MuseDoma”) is set to expire on 2 March 2018. ICANN org and MuseDoma negotiated aproposed Renewal Registry Agreement based on modifications to the current .MUSEUMRegistry Agreement and the inclusion of certain provisions from the base New gTLD RegistryAgreement. The Board is being asked to approve this proposed Renewal RegistryAgreement.

EXECUTIVE SUMMARY:

The proposed renewal agreement for .MUSEUM includes revisions to more closely align tothe terms of the New gTLD Registry Agreement. The revisions include terms intended toallow for swifter action in the event of certain threats to the security or stability of the DNS,as well as other technical, operational, and reporting obligations expected to provideconsistency across all registries. The proposed provisions include:

• Specification 12 to replace Appendix S: Some legacy TLDs like .MUSEUM have beencategorized as “Sponsored” TLDs via Appendix S. A similar construct, “Community”TLDs, was introduced via Specification 12 in the New gTLD Registry Agreement. Assuch, legacy TLDs such as .TEL, .CAT and .TRAVEL have transitioned from“Sponsored” TLDs to “Community” TLDs when those TLDs renewed their registryagreement. As a “Sponsored” TLD, .MUSEUM follows a charter defining the purposefor which the sponsored TLD is managed and operated. The proposed renewalagreement for .MUSEUM replaces the existing registration restrictions in the currentregistry agreement Appendix S with Specification 12. As .MUSEUM is recategorizedfrom a “Sponsored” TLD to a “Community” TLD, the eligibility requirements for.MUSEUM will expand to include a more broadly defined community of museums,professional associations of museums, and individuals with an interest or a link withthe museum profession and/or activity.

• Registry Fees: The proposed renewal agreement complies with MuseDoma’s requestto maintain the existing annual registry fees of $500 until the TLD surpasses 5,000registered names. The last monthly transaction report from September 2017 shows456 total domains under management for .MUSEUM. Per the terms in the proposedagreement, the registry fees can be renegotiated in three years.

INPUT REQUESTED: Approve/Don’t Approve

Approve:• Pro: Added improved safeguards for the TLD to adopt the new technical and

operational specifications to align with the New gTLD Registry Agreement.• Con: None.

Don’t Approve:• Pro: None.• Con: MuseDoma, as with other legacy TLD Registry Operators, have the presumptive

right of renewal.

STAFF or COMMITTEE RECOMMENDATION:

ICANN org recommends that the Board approve the proposed Renewal Registry Agreementwith MuseDoma for operation of the .MUSEUM top level domain.

BASIS FOR DECISION AND RATIONALE:

The current .MUSEUM Registry Agreement expires on 2 March 2018. The proposed RenewalRegistry Agreement was posted for public comment between 24 August 2017 and 3 October2017. At this time, the Board is approving the proposed .MUSEUM Renewal RegistryAgreement for the continued operation of the .MUSEUM TLD by MuseDoma.

LIST OF DOCUMENTS:• Proposed .MUSEUM Renewal Registry Agreement• Redline showing changes compared to the current .MUSEUM Registry Agreement• Current .MUSEUM Registry Agreement• New gTLD Agreement – 31 July 2017• Public Comment Summary and Analysis

Check Box -‐ Board Shepherd/Staff Interaction

Date Staff Sent Doc to ShepherdDate of clearance or comments sent toStaff FROM Shepherd (comments/clearanceare to be sent by email from Board Shepherdemail to Staff in charge with a copy to Board-‐Ops):Date answers/amendments provided byStaff back to Shepherd:

ICANN Investment Policy | Adopted November 2007 | Updated July 2009 | Updated September 2011 | Updated April 2014| Updated March 2016 | Updated February 2018 View archived policy from November 2007 View archived policy from July 2009 View archived policy from September 2011 View archived policy from April 2014 [ADD LINK TO MARCH 2016 POLICY HERE]

Adopted November 2007 Updated July 2009 Updated September 2011 Updated April 2014 Updated March 2016 Updated February 2018

Introduction

Purpose of the ICANN Investment Policy

Philosophy of the ICANN Investment Policy

Areas of Responsibility

General Investment Principles

Approval of Disbursements from the Reserve Fund

Periodic Review/Approval of Policy and Exceptions

INTRODUCTION

[INSERT ADOPTION DATE HERE ONCE APPROVED] - This statement of investment policy has been adopted by the Board of Directors of the Internet Corporation for Assigned Names and Numbers (ICANN) to provide guidelines for the investment of cash on hand (funds).

2

Formatted: Position Horizontal: Center Relative to:Margin Vertical: 0 Relative to: Paragraph Wrap Around

Since its early days, ICANN’s operations and risk profile have changed significantly, due to ICANN’s unique role in the Internet eco-system and its commitment to accountability and transparency to the public. ICANN is exposed to legal and other challenges of its activities. This exposure has continuously increased as the Internet and the domain name system (DNS) have expanded and ICANN’s role has become more visible, including following the termination of the U.S. Government oversight of the IANA functions late 2016. In addition, ICANN is one of the root server operators upon which the global Internet DNS depends. Malicious threats and vulnerabilities, some attacking (or hijacking) the DNS root, continue to appear. Network science and technology will continue to evolve, as will vulnerabilities. As ICANN’s activities have become more complex and more visible with the expansion of the DNS, it continuously improves its capabilities to plan for the future, to manage and mitigate its exposure to risks, with a high sense of financial responsibility and discipline. This has led ICANN to adopt and live by the simple principle of never spending more than it can afford. ICANN therefore ensures that its expenses never exceed its funding.

For the purposes of managing investment risk and to optimize potential returns within acceptable risk parameters, the investment of funds is divided into two pools of assets.

• The Operating Fund is used to fund day to day operations of ICANN including all items in the ICANN Board approved annual budget. In general, the Operating Fund is set at a level necessary to fund a maximum of three months of expected operating expenses. Amounts in the Operating Fund that exceed this limit shall be transferred to the Reserve Fund.

• The Reserve Fund is ICANN’s funding of last resort to cover large expenses resulting from unavoidable, unpredictable or unplanned events, which cannot be funded from ICANN’s Operations.

Illustrative examples of such events include:

o the urgent and unbudgeted replacement of large assets, or payment of large liabilities,

o the undertaking of major downsizing or significant restructuring of ICANN’s operations.

o the occurrence of major security and stability threats and attacks. o the occurrence of unplanned large litigation and/or penalty expenses. o undertaking new and major programs resulting from a new strategic plan or

exceptional unforeseen external events o the recovery and continuation of operations after a disaster.

Deleted: will be

Deleted: , sometimes called the Working Capital Fund

3


ICANN recognizes that it is impossible to foresee all possible events that can trigger large, unavoidable, unpredictable or unplanned expenses, which cannot be funded from ICANN’s Operations. As a result, the list above is considered illustrative and non-limitative. ICANN, like many organizations, is exposed to natural disasters, economic fluctuations and regulatory changes. However, unlike any other organization, ICANN’s mission has led the Organization and its multistakeholder model of governance to be subject to the constant changes that affect the Internet, driven by demographic, governmental, economic and technical factors. No matter how well ICANN plans, manages risks and applies financial discipline, it is highly exposed to unpredictable events that may have an overwhelming impact on its on-going activities, which are supported by its Operating Fund. In this environment, the only financial resource available to ICANN to face the negative impacts of any events outside of its daily activities, is its Reserve Fund.

• The use of any Reserve Fund is restricted by actions of the Board of Directors. The Board of Directors has delegated to the Board Finance Committee (BFC) the authority to act on behalf of the Board of Directors to release funds from the Reserve Fund to pay for items of an emergency nature.

PURPOSE OF THE ICANN INVESTMENT POLICY

The purpose of the ICANN Investment Policy is to:

1. Describe the philosophy of the Investment Policy that will guide investment management decisions.

2. Define and assign the responsibilities of all involved parties including the ICANN Board of Directors, the ICANN Chief Financial Officer (CFO) and personnel, and the Investment Management Company (as defined below).

3. Describe the general investment principles for investment of the funds including the size of the funds, the suggested levels of risk, the expected return on investment, the suggested liquidity level, the expected asset allocation strategy, the expected global focus, and suggested allowable and restricted asset classes.

4. Establish a basis for evaluating and reporting investment results and compliance with the Investment Policy.

5. Clarify the methods by which the Reserve Fund will be funded as well as the process by which the Reserve Fund can be accessed for emergency requirements.

PHILOSOPHY OF THE ICANN INVESTMENT POLICY

The philosophy of the ICANN Investment Policy is to:

Deleted: only used for emergencies. The Reserve Fund is a rainy day fund.

Deleted: staff

4


• Ensure that funds held by ICANN are invested wisely with due fiduciary care. • Ensure that funds are safe and held securely to minimize risk of loss to the fullest extent

possible. • Ensure that funds earn appropriate returns commensurate with the level of risk and real

rates of return that can offset the effects of inflation over a market cycle. • Ensure that funds remain liquid enough to be accessible to handle the needs of ICANN's

operations (Operating Fund) and the needs of ICANN, if any (Reserve Fund). • Ensure clarity on the amounts to be held in the funds. • Ensure clarity on the method(s) to access the funds for expenditure.

AREAS OF RESPONSIBILITY

Board of Directors

The Board of Directors of ICANN shall direct the ICANN Investment Policy, including:

• Create and approve the ICANN Investment Policy. • Maintain and update the Investment Policy periodically • Delegate to the BFC specific duties and responsibilities related to the monitoring of the

Investment Policy, including: o Approve of the Investment Management Company. o Direct the CFO to monitor the Investment Management Company, monitor the

performance of the funds, and the compliance with the Investment Policy. o Periodically monitor the performance of the Reserve Fund and Operating Fund. o Monitor ICANN’s compliance with the Investment Policy. o Periodically evaluate ICANN’s current risk tolerances and investment objectives. o Periodically report to the full Board on ICANN org’s compliance with the

Investment Policy. o Approve disbursements from the Reserve Fund.

ICANN Org

ICANN's CFO, with the assistance of certain ICANN personnel, shall take certain steps to oversee the administration of the Investment Policy, including:

• Monitor and direct all activities related to the Operating Fund, including funding daily operations.

• Recommend the Investment Management Company. • Monitor the activities of the Investment Management Company. • Ensure that any amounts not required for the Operating Fund are transferred to the

Reserve Fund. • Respond to monthly status reports on the performance of the Reserve Fund. • Periodically report to the Board of Directors on the performance of the Reserve Fund. • Periodically report to the Board of Directors on compliance with the Investment Policy.

The Investment Management Company

Deleted: as measured by the CPI

Deleted: in case of an emergency

Deleted: (at least annually).

Deleted: the Deleted: the Deleted: the

Deleted: Staff and CFO

Deleted: staff

5


The Investment Management Company shall take certain steps to oversee the Reserve Fund including:

• Hold fiduciary responsibility for all assets in the Reserve Fund. • Comply with all guidelines and limitations set forth in the Investment Policy. • Manage, analyze and oversee the execution of investment decisions including buying,

selling, and holding of individual securities for all asset types in all asset classes. • Report monthly to the ICANN CFO on the performance of the Reserve Fund and

compliance with the Investment Policy. • Communicate any major changes to economic outlook, investment strategy, or any other

factors which affect implementation of investment process. • Be available to report periodically to the Board of Directors on the performance results of

the Reserve Fund including comparisons with approved industry benchmarks. • Be available to report periodically to the Board of Directors on the compliance with the

Investment Policy. • Inform the Board of Directors regarding any significant changes including changes to the

investment management company, its financial strength, significant decline in assets under management, SEC investigations, material litigation, changes in portfolio management personnel, ownership structure, investment philosophy, and investment processes.

GENERAL INVESTMENT PRINCIPLES

Pools of Funds

ICANN's investment funds will consist of two pools of funds: the Operating Fund and the Reserve Fund.

The Operating Fund, sometimes called the Working Capital Fund, is the pool of funds that is used for ICANN's day-to-day operations. The Operating Fund will not be Board restricted and will be used to fund operating expenses of ICANN, including payroll and accounts payable. All disbursements at ICANN shall comply with Board-approved disbursement guidelines and financial controls. The Operating Fund will be replenished by ICANN's revenues, and can also be replenished by the Reserve Fund if the Board determines that it is necessary.

Disbursements out of the Reserve Fund are restricted by the Board.

Size of Funds

The size of the Operating Fund and the Reserve Fund shall be evaluated and established on an annual basis as part of the budget preparation process.

The Operating Fund shall contain enough funds to cover ICANN's expected expenditures for three months. Periodically, any funds in excess of this will be transferred to the Reserve Fund.

Deleted: there is an emergency requirement

Deleted: The Reserve Fund is the pool of funds held by ICANN for rainy day emergencies.

6


The Reserve Fund shall contain any amounts not contained in the Operating Fund. Any surplus funds will be used to build up the Reserve Fund The Reserve Fund is expected to reach and maintain a level of funds to maintain a minimum of 12 months of expected expenditures.

Investment Horizon and Objectives

The Operating Fund has a short-term horizon and a principal preservation objective to meet working capital needs. The Reserve Fund has a medium investment horizon and a conservative-moderate investment objective to enhance return on assets.

Guidelines: Risk Level of Funds

Although there are many ways to measure risk, this investment policy primarily measures risk as the possibility of losing nominal asset value in a fund over a given period of time. Historical performance and volatility measures are indicators of its risk profile. A fund with very little risk would never incur losses as measured over any historical period. A fund with moderately low risk would not incur losses over most historical periods. A fund with greater risk might have incurred losses in certain historical periods.

The Operating Fund will have a conservative risk profile focusing on capital preservation with minimal principal fluctuation.

The Reserve Fund will have a conservative-moderate risk profile that is moderately low risk. The historical performance of the fund should have a very low probability of losses over any given five-year period.

Expected Investment Return (%) of Funds

Funds shall be invested in assets that are expected to yield the greatest investment return given the risk profile and other parameters of the fund. Historical performance and volatility measures are indicators of its risk profile and how the fund may perform under different market conditions.

The Operating Fund is expected to earn rates of return commensurate with a principal preservation fund. The three-month US Treasury Bill is therefore considered an appropriate benchmark for a nominal rate of return.

The Reserve Fund is expected to earn rates of return commensurate with a moderately low risk portfolio. The performance objective of the investments is to provide a total investment return in excess of the performance of the agreed upon composite benchmark. A comparison shall be made with relevant market benchmarks as well as the composite returns for other peer groups with similar philosophies. The appropriate benchmark is a function of the asset classification currently in place and may consist of a balanced or weighted average index underlying such asset classes. The total return is expected to rank above the median versus a manager universe with a similar asset mix.

Deleted: to a balance sufficient to cover an emergency requirement

7


The Reserve Fund should preserve the real (inflation-adjusted) purchasing power of the Reserve Fund's assets while maximizing real income. Real income is defined as the sum of dividends, interest, and realized gains/losses less the inflation rate as measured by CPI (Consumer Price Index) over a market cycle or rolling 10- year period.

Guidelines: Liquidity Level of Funds

Liquidity is a measure of whether the assets of the fund can be sold for cash without a significant realized principal loss. A highly liquid fund would not suffer losses even if there were an immediate sale of the assets of the fund. A moderately liquid fund would not suffer significant losses even if the assets were sold over a period of time of less than one year.

The Operating Fund will be highly liquid and only invest in cash, cash equivalents, or money market instruments (including certificates of deposits, commercial paper or SEC 2a-7 money market funds.) All funds are daily valued and can be accessed within 48 hours without any significant loss in value.

The Reserve Fund is suggested to be moderately liquid. Reserve Fund assets do not need to be sold for cash except in an emergency. The Reserve Fund may invest in money market instruments and SEC 2a-7 money market funds. It is suggested that the Reserve Fund be liquid enough to realize one-third of its value without significant loss within 30 days, two-thirds of its value without significant loss within two months, and all of its value without significant loss within six months. A significant loss is defined as more than 15% realized loss. Losses in excess require BFC and Board approval.

Permissible Investment Vehicles

The Investment Management Company may recommend investments in actively managed and/or passive strategies that invest in marketable securities. These strategies may be institutional mutual funds, collective trusts or commingled funds. The underlying security holdings must be transparent. The strategies must be non-lending portfolios.

Expected Asset Classification/Portfolio Mix and Allocation Constraints of Funds

The asset classification/portfolio mix guides the Investment Management Company to create a portfolio that best reflects the risk posture, expected return, and other investment parameters described in the Investment Policy. The categories of classification described, and the measurements expected to be complied with, in this Investment Policy are a percentage of cash equivalents, a percentage of bonds, and a percentage of equities. In addition, the allocation constraints allow the Investment Manager to rebalance the portfolio within a risk-controlled framework and should avoid market-timing changes. Rebalancing should not incur losses or administrative burdens. Portfolio rebalancing is required at least semi-annually and may be as frequent as quarterly or monthly.

The Operating Fund's asset classification is 100% cash, cash equivalents, money market instruments or SEC 2a-7 money market fund. The constraint is zero.

8


The Reserve Fund's Normal Asset Allocation is 65% Global Bonds and 35% Global Equities and Real Estate. The Asset Allocation is a long term asset allocation target. The Investment Management Company will manage a Tactical Asset Allocation Non-Lending Portfolio consistent with the allocations within the Allowable Investment Range. The portfolio will be rebalanced generally to maintain the allocations. The Investment Management Company may also rebalance in response to changes in economic and market conditions, liquidity requirements or provide defensive positioning to improve downside protection. Market timing is not permissible. The table below indicates the asset allocation ranges:

Asset Class Normal Asset Allocation Allowable Investment Range Global Fixed Income 65% 45%-85% Global Equities & Real Estate 35% 15%-55%

Guidelines: Global Focus of Funds

ICANN's funds are to be invested in well diversified assets that perform well in terms of return on investment and also are invested safely to reduce the risk of loss on the portfolio. Safety and performance are the most important priorities. The ICANN Investment Policy assumes that a well diversified portfolio designed for investment performance and safety should contain a significant amount of investments in non-US assets and are also based in non-US dollar denominated currencies.

The Investment Policy recognizes that ICANN is a U.S.-based organization, but it also must recognize that ICANN has a distinctly global focus. The funds that ICANN invests in should reflect the global nature of ICANN. The actual assets allocated to non-U.S.-based assets and non-U.S. dollar denominated investments shall be suggested by the Investment Management Company and approved by the ICANN CFO.

The Operating Fund may be denominated in its functional currencies to meet operating needs but does not require a significant global focus.

The Reserve Fund is suggested to have a significant global focus. The Investment Policy enables the Reserve Fund to invest in global assets. Actual allocations are to be monitored by the Board and may be subject to further limitations between developing and emerging foreign markets consistent with ICANN's risk profile.

Guidelines: Asset Classes of Funds

The Investment Policy requires the Investment Management Company to recommend particular active and/or index fund managers, institutional mutual funds, collective trusts or commingled funds, categories of investments, etc., that comply with the Investment Policy principles and guidelines.

Operating Fund Allowable Assets

Deleted: company

9


Cash, Cash Equivalents, and Money Market Instruments

• Checking accounts in acceptable investment grade financial institutions • Certificates of Deposit – issued by acceptable investment grade financial institutions • U.S. Government Treasury securities • U.S. Agency securities – obligations issued or guaranteed by an agency of the U.S.

government • Commercial Paper – issued by corporations possessing the highest rating issued by

Moody's or Standard & Poor's (A1/P1) • Money market funds – SEC 2a-7 money funds

Reserve Fund Allowable Assets

Investment Grade Fixed Income Securities

• U.S. Government and Agency Securities (e.g., GNMA and FNMA) • Corporate Notes and Bonds • Mortgage Backed Bonds • Asset Backed Securities (e.g., Auto and Credit Card) • Sovereign Governments, Agencies and Supranationals • Local Authorities • Institutional mutual funds or commingled funds which invest in fixed income securities • Money market instruments, and SEC 2a-7 money market funds

Investments shall be made in fixed income securities that are liquid, marketable and may include notes, bonds, 144A, fixed rate and floating rate securities with minimum investment grade ratings as defined by Moody's (Baa3), Standard & Poor's (BBB-), Fitch (BBB-) or DBRS (BBB Low).

Non-Investment Grade Fixed Income Securities

No more than 10% of the total portfolio may consist of U.S. marketable securities rated below investment grade (limited to BB and B rated), and may include high yield, notes, bonds, 144A, fixed rate and floating rate securities. In the event that registered mutual funds, collective trusts or commingled funds hold fixed income securities below investment grade, the Investment Management Company and ICANN CFO will monitor the percentage holdings and take the appropriate action to reduce exposures consistent with ICANN's moderately low risk profile.

Average Portfolio Credit Quality

The minimum weighted average credit quality of the portfolio shall be A2/A.

Equity Securities

• Common Stocks • Preferred Stocks

10


• Convertible Notes and Bonds • Convertible Preferred Stocks • Stocks of Non-US Companies (Ordinary Shares) • Stocks of REITs • Non-Lending Institutional Mutual Funds, Collective Trusts or Commingled Funds which

invest in securities as allowed in this statement

There shall be no direct investments in non-marketable securities.

Prohibited Assets and Transactions

• Exchange traded or OTC Commodities and Futures Contracts Private Placements • Private Placements • Credit default, interest rate and commodity swaps • Exchange traded or OTC Options • Limited Partnerships • Venture-Capital Investments • Real Estate Properties • Derivative Investments • Hedge funds • Short Selling • Margin Transactions • Commodities

In certain circumstances, institutional mutual fund, collective trusts or commingled fund investments may engage in transactions that include prohibited transactions for the purpose of hedging operations to minimize transaction costs, rebalancing and replicating the benchmark.

In the event that institutional mutual funds or commingled funds hold prohibited assets defined above, the Investment Management Company and CFO will monitor the holdings and take the appropriate action to reduce exposures consistent with ICANN's moderately low risk profile.

Securities Lending

This policy prohibits ICANN from undertaking a Securities Lending Program. The institutional mutual funds, collective trusts or commingled funds must be non-lending portfolios.

Fair Value of Investments

The Investment Management Company must make all investments in securities and funds that have readily determinable fair values. All fair value measurements must be consistent with ASC 820 (FAS 157) which defines fair value and establishes a framework for measuring fair value (market value).

Ethics and Conflicts of Interest

11


All Board Members, the CFO, and the Investment Management Company personnel shall comply with all applicable conflicts of interest policies and otherwise refrain from personal business activity that could conflict with the proper execution and management of the investment program, or that could impair their ability to make impartial decisions. Any known or suspected violations must be disclosed to ICANN's General Counsel.

APPROVAL OF DISBURSEMENTS FROM THE RESERVE FUND

The Reserve Fund is the pool of investments held by ICANN for the purpose described in the Introduction section of this document. The Reserve Fund is funded by any assets not required for use by ICANN's Operating Fund. Use of any funds from the Reserve Fund is restricted by action of the Board of Directors of ICANN. The Board at its sole discretion and judgment shall determine whether an emergency exists for purposes of releasing funds from the Reserve Fund.

Due to the nature of a requirement to release funds from the Reserve Fund, it may be necessary to make a rapid decision. For this reason, the Board of Directors has delegated to the Board Finance Committee (BFC) the authority to act on behalf of the Board of Directors of ICANN to disburse funds of up to $5 million from the Reserve Fund. Any such action by the BFC will be communicated to the full Board of Directors within seven days of such action.

PERIODIC REVIEW/APPROVAL OF POLICY AND EXCEPTIONS

This policy will be subject to periodic review by the CFO and BFC. Specific elements to be reviewed include:

1. Appropriate operating fund limits (currently three months' operating expenses) 2. ICANN's investment objectives and risk tolerances 3. Allowable and permitted investments 4. Portfolio asset allocation and mix 5. Portfolio benchmarks 6. Portfolio rebalancing

Exceptions to this policy require BFC and Board approval as necessary. All exceptions should be communicated by the ICANN CFO to the BFC within a 48-hour period, or as soon thereafter as is practicable, including details of appropriate action to be taken.

Deleted: staff

Deleted: that is restricted for use for rainy day emergencies only

Deleted: Here are some possible scenarios that may be considered by the Board as a qualified emergency: ... [1]

Deleted: n emergency

Comment [AS6]: Same comment as above about limitingto emergencies.

Deleted: as it related Deleted: for emergency purposes Deleted: any decision

Deleted: (at least annually)

Adopted FY19 IANA Operating Plan and Budget

2 February 2018

ICANN | Adopted FY19 IANA Operating Plan and Budget | February 2018

| 2

TABLE OF CONTENTS

1 CHANGES BETWEEN ADOPTED AND ADOPTED VERSIONS 3

2 INTRODUCTION 4

3 EXECUTIVE SUMMARY 5

4 IANA BUDGET OVERVIEW 6

5 IANA CARETAKER BUDGET 6

6 IANA OPERATING PLAN AND BUDGET 7

6.1 Portfolios 7

7 APPENDICES 9

Appendix A — IANA Budget 9 Appendix B — PTI Services and the IANA Budget Summary 10


| 3

IANA Operating Plan & Budget 1 Changes Between Draft and Adopted

Versions This section shows the changes made to the final budget based on input received from the Public Comment period. Section Number Change Type Change Description 1 Added a table Added a table for document

acronyms as requested in public comment

4 Budget Lower personnel expenses due to the decision to combine duties of two open roles (Director of Security and Director of Technical Services) into one position

6 Descriptions Changed portfolio wording ACRONYM DESCRIPTION AC Description Admin Administration AFRINIC Advisory Committee CSC Customer Standing Committee DNS Domain Name System DNSSEC Domain Name System Security Extensions EFQM European Foundation for Quality

Management FTE Full Time Staff Equivalent IANA Internet Assigned Numbers Authority IETF Internet Engineering Task Force KMF Key Management Facility KSK Key Signing Key Prof Svcs Professional Services PTI Public Technical Identifiers RAMS Registry Assignment and Maintenance RFC Request for Comments RIRs Regional Internet Registries SO Support Organization T&M Travel and Meetings


| 4

2 Introduction CONTENTS OF THE DOCUMENT This document contains the total adopted FY19 Internet Assigned Numbers Authority (IANA) Operating Plan and Budget, which was posted for public comment as required by ICANN’s Bylaws, and in accordance with ICANN’s public comment process. This document provides the details of the IANA Functions and other IANA services for fiscal year 2019 (FY19) from 1 July 2018 to 30 June 2019. This adopted FY19 IANA Operating Pan and Budget includes the amounts covered in the adopted FY19 Public Technical Identifiers (PTI) Budget and the amounts for the IANA services performed by ICANN as the IANA Functions Operator, and which are not performed by PTI. Section 6 of this document describes the IANA Functions and other IANA services and the activities performed to deliver them. Where useful, comparative information for FY18 is provided, which represents the total IANA Functions and other IANA services forecast information for this fiscal year. MULTISTAKEHOLDER PARTICIPATION The multistakeholder model enables the engagement of stakeholders in the planning process through accessible information and effective interaction. This adopted FY19 IANA Operating Plan and Budget was published for public comment to receive feedback from the community. Enabling the engagement of stakeholders in a feedback loop through a public comment period is a fundamental part of the multistakeholder model, and is a key element of the transparency and community engagement in the planning process. ICANN welcomes and recognizes the engagement of stakeholders into the planning process of the adopted FY19 IANA Operating Plan and Budget.


| 5

3 Executive Summary ICANN org receives input from PTI on its budget and then develops an IANA Budget each year, which includes the full PTI Budget as a large sub-part. SEPARATION OF PTI AND IANA BUDGETS The PTI FY18 Operating Plan and Budget included details of not only the PTI Services, but also the amount of the IANA services that ICANN org performs as the IANA Functions Operator. This is being handled differently in planning for FY19. The PTI Budget no longer references the IANA services not performed by PTI and is reflected as large sub-part of the IANA Budget, as described in this document. STRUCTURE OF WORK In addition to the ICANN funded PTI operational activities and PTI technical systems enhancements (PTI Services) outlined in the adopted FY19 PTI Operating Plan and Budget, the adopted FY19 IANA Operating Plan and Budget also includes the IANA services performed by ICANN org in its role as the IANA Functions Operator. PLANNING AND BUDGET OVERVIEW This graphic shows the PTI planning process and the encompassing ICANN planning process. PTI’s strategic goals are a part of ICANN’s strategic goals. PTI’s multiyear plans are a part of ICANN’s Five-Year Operating Plan. This adopted version of FY19 IANA Operating Plan and Budget will become a component of ICANN’s FY19 Operating Plan and Budget.


| 6

4 IANA Budget Overview The PTI Board adopts the PTI Operating Plan and Budget each year, which is included as a large sub-part of the IANA Operating Plan and Budget, which in turn is included in ICANN’s Operating Plan and Budget.

The adopted FY19 IANA Budget is $10.6 million, which is an increase of $0.5 million from the $10.0 million IANA Budget for FY18. The adopted FY19 IANA Budget is comprised of $10.1 million for PTI Services (see Appendix B) and $0.5 million for IANA services that ICANN org performs as the IANA Functions Operator. The increase of $0.5 million for PTI Services is primarily due to an increase in Personnel costs of $0.3 million, or 4.5%, due to the impact of merit awards and benefits for existing personnel and an increase in the direct shared resources due to incremental legal, technical security, and Customer Standing Committee (CSC) support by ICANN org. Administration costs increased by $0.1 million, or 5.2%, due to software services support. The IANA Services Budget increased by $0.1 million, or 18.8%, due to the incremental cost of ICANN org’s support for the work related to the Empowered Community process and the support for the Root Zone Evolution Review Committee (RZERC) activities.

5 IANA Caretaker Budget There is a potential that the IANA Budget will not be in full force and effect at the start of FY19. If that is the case, under the ICANN Bylaws, there is both a “Caretaker ICANN Budget” and a “Caretaker IANA Budget” (described at Annexes E and F, respectively), which are required to go into effect if the respective budget is not able to come into full force and effect at the beginning of a fiscal year. For purposes of FY19, the "Caretaker IANA Budget" as described in Annex F to ICANN’s Bylaws, is defined as the FY18 IANA Operating Plan and Budget as approved by the ICANN Board in June 2017.

FY19 IANA Budget Increase/(Decrease)in Millions, USD Total %PTI Services $10.1 $9.6 $0.5 4.8%IANA Services (a) $0.5 $0.4 $0.1 18.8%

TOTAL $10.6 $10.0 $0.5 5.3%(a) IANA Services include RZMA = Root Zone Maintainer Agreement and Empowered Community, and RZERC support.It will be funded by ICANN Operations.

FY19 IANA Budget

FY18 IANA Budget


| 7

6 IANA Operating Plan and Budget The work performed to deliver the IANA Functions and other IANA services contributes to achieving ICANN’s overarching strategic objectives. The IANA Functions and other IANA services sit within the objective “Support a healthy, stable and resilient unique identifier ecosystem” and goal “Foster and coordinate a healthy, secure, stable, and resilient identifier ecosystem.” Within that strategic structure, the IANA Functions and other IANA services include four portfolios: two portfolios where PTI operationalizes work and two for the IANA services performed directly by ICANN org. Of the two PTI portfolios one is focused on operational activities and the other is focused on systems enhancements and development. The two other IANA services portfolios include the activities that ICANN org performs as the IANA Functions Operator. Costs are shown in millions of US dollars with a granularity of $100,000. An absence of any expenditure is shown with a dash. The cost tables use abbreviations in some column headers and these are explained in this table. Abbreviation Meaning T&M Travel and Meetings Prof Svcs Professional Services Admin Administration FTE Full Time Staff Equivalent

6.1 Portfolios PTI is structured in two groups of thematically aligned portfolios: 2.1.3 – PTI Operations Work relating to operational responsibilities for maintaining registries for protocol parameters, IP numbers, Autonomous System Numbers, and root zone changes. Maintenance of relationship with Internet Engineering Task Force, Internet Architecture Board, five Regional Internet Registries, and TLD operators. 2.1.4 – PTI Technical System Enhancements Work to improve and develop software, tools, and other discrete projects to improve delivery of the IANA services. The two other IANA services portfolios include policy support development for the CSC and RZERC and the activities supporting the continued evolution of the root server system. 1.3.1 – Support Policy Development, Policy Related and Advisory Activities Work to optimize the efficiency and effectiveness of community policy development and advice efforts. 3.2.2 – Root Systems Operations Work to support the continued development of the root server system to ensure its ongoing security, stability, and resiliency as DNS technology and operations change over time. This


| 8

includes maintaining relationships with the Root Server Operators, RSSAC, and related stakeholders.

Portfolios FTE Pers T&M Prof Svcs Admin Capital Total2.1.3 PTI Operations 19.1 5.3 0.6 1.6 1.6 0.2 9.3 2.1.4 PTI Technical System Enhancements 3.7 0.7 0.0 0.1 0.0 - 0.8 1.3.1 Support Policy Development, Policy Related and Advisory Activities 0.7 0.1 - - - - 0.1 3.2.2 Root Systems Operations 0.0 - - 0.3 - 0.1 0.4 Total 23.4 6.1 0.7 1.9 1.6 0.3 10.6


| 9

7 Appendices Appendix A — IANA Budget

FY19 IANA Budget Increase/(Decrease)in Millions, USD Total %

FUNDING $10.6 $10.0 $0.5 5.3%

Personnel $6.1 $5.8 $0.4 6.7%Travel & Meetings $0.7 $0.6 $0.1 8.6%Professional Services $1.4 $1.4 $0.0 1.3%Administration $1.6 $1.6 ($0.0) -0.2%Contingency $0.5 $0.5 ($0.0) -0.9%Capital $0.3 $0.2 $0.1 45.4%

TOTAL CASH EXPENSES $10.6 $10.0 $0.5 5.3%

EXCESS/(DEFICIT) $0.0 $0.0 ($0.0) 0.0%

Average Headcount (FTE) (a) 23.4 22.6 0.8 3.7%(a) FTE: Full-time staff equivalent

IANA Budget FY19

IANA Budget FY18


| 10

Appendix B — PTI Services and the IANA Budget Summary

FY19 PTI Budget Increase/(Decrease)in Millions, USD Total %

FUNDING $10.1 $9.6 $0.5 4.8%

Personnel $6.0 $5.8 $0.3 4.5%Travel & Meetings $0.7 $0.6 $0.1 8.6%Professional Services $1.1 $1.1 $0.0 1.7%Administration $1.3 $1.2 $0.1 5.2%Contingency $0.5 $0.5 ($0.0) -0.9%Capital $0.2 $0.1 $0.1 157.6%Depreciation (a) $0.3 $0.4 ($0.1) -17.7%

TOTAL CASH EXPENSES $10.1 $9.6 $0.5 4.8%

EXCESS/(DEFICIT) $0.0 $0.0 $0.0 0.0%

Average Headcount (FTE) (b) 22.8 22.6 0.2 0.8%(a) Depreciation is treated as a cash expense for PTI since it will be reimbursed to ICANN(b) FTE: Full-time staff equivalent

FY19 IANA Budget Increase/(Decrease)in Millions, USD Total %PTI Services $10.1 $9.6 $0.5 4.8%IANA Services (c) $0.5 $0.4 $0.1 18.8%

TOTAL $10.6 $10.0 $0.5 5.3%(c) IANA Services include RZMA = Root Zone Maintainer Agreement, Empowered Community, and RZERC support. It will be funded by ICANN Operations.

PTI Services FY19 Budget

PTI Services FY18 Budget

FY19 IANA Budget

FY18 IANA Budget

ICANN BOARD MEETING (Los Angeles, 4 Feb 2018)

TITLE: Addressing the New gTLD Program Applications for.CORP, .HOME, and .MAIL

PROPOSED ACTION (select): For Board ResolutionTOPIC LEADER: Cherine Chalaby / Chris DisspainSTAFF IN SUPPORT: Akram AtallahTIME REQUESTED: 15 min (presentation); 15 min (discussion)

FRAMING THE ISSUE:

The ICANN org provided options at the 13 December 2017 meeting for addressingthe applications for .CORP, .HOME, and .MAIL. The Board has determined to proceedwith providing the applicants a full refund of the New gTLD Program application fee.The next step is for the Board to consider and approve the resolution directing thePresident and CEO to take this action.

EXECUTIVE SUMMARY:

Since implementation of the Name Collision Occurrence Management Frameworkthere has been no further information on name collisions or the potential risks ofdelegating the strings .CORP, .HOME, and .MAIL to prompt the Board to revisit theirindefinite deferral. The ICANN org presented options to the Board to address theoutstanding applications for .CORP, .HOME, and .MAIL.

Based on the Board’s discussion of the merits and disadvantages of the options, theBoard has determined to proceed with providing the remaining applications for.CORP, .HOME, and .MAIL with a full refund of the 2012 New gTLD Programapplication fee of $185,000. The ICANN org anticipated that significant refunds mightbe issued for the remaining program applicants. As such, the financial impact toICANN has been accounted for in the Operating Plan and Budget.

INPUT REQUESTED:

ICANN org is requesting the Board to take action to implement one of the optionsdiscussed at the 13 December 2017 Board meeting. The options discussed at thattime dealt with the following questions:

• What type of refund should be provided to the applicants?• Should the applicants receive priority over other applications for these strings

in any subsequent round of the New gTLD Program?

ICANN ORG RECOMMENDATION:

ICANN org is recommending the Board to take a resolution directing the Presidentand CEO to, upon withdrawal of the the remaining applications for .CORP, .HOME,and .MAIL, provide the applicants a full refund of the New gTLD Program applicationfee of $185,000.

Taking this action contributes to the commitment of the ICANN organization to the

security, stability and resiliency of the DNS. This action benefits the ICANNcommunity as it provides transparency and predictability to the applicants for .CORP,.HOME, and .MAIL.

BASIS FOR DECISION AND RATIONALE:

Regarding the type of refund to be provided, the Board considered that, althoughthe issue of name collision was described in AGB Section 2.2.1.3, applicants were notaware before the application window that the strings .CORP, .HOME, and .MAILwould be identified as high risk, and that the delegations of such high risk stringswould be deferred indefinitely.

Regarding priority in a subsequent round, the Board considered that there iscurrently no indication that the strings .CORP, .HOME, and .MAIL will be able to bedelegated at any time in the future. The Board also considered the potentialcomplexity associated with establishing procedures for granting priority and that thismay be an issue to be handled via the policy development process and not Boardaction.

LIST OF DOCUMENTS:

For advance reading:

1. Name Collision Occurrence Management Framework(https://www.icann.org/en/system/files/files/name collision framework30jul14 en.pdf)

2. 24 August 2016 letter from applicants for .CORP, .HOME, and .MAIL(https://www.icann.org/en/system/files/correspondence/home registry incet al to icann board 24aug16 en.pdf)

3. Applicant Guidebook, Sections 1.5 and 2.2.1.3(https://newgtlds.icann.org/en/applicants/agb/guidebook full 04jun12en.pdf)

4. Options for Addressing the New gTLD Program Applications for .CORP,.HOME, and .MAIL (https://www.icann.org/resources/board material/prelimreport 2017 12 13 en#2.a)

Check Box -‐ Board Shepherd/Staff Interaction

Date Staff Sent Doc TO Shepherd” 22 January 2018Date of clearance or comments sent toStaff FROM Shepherd(comments/clearance are to be sent by emailfrom Board Shepherd email to Staff in chargewith a copy to Board-‐Ops):Date answers/amendments provided byStaff back to Shepherd:

1

GAC Advice – Abu Dhabi Communiqué: Actions and Updates (DD Month YYYY)DRAFT Version 11

Updated 22 January 2018

GAC Advice Item(Included on final

scorecard)

Advice Text(Included on final scorecard)

DRAFT Board Understanding FollowingBoard-‐GAC Call

(Final language to be included on finalscorecard)

GNSO Review of Abu Dhabi Communiqué(Language NOT to be included on final

scorecard)

DRAFT Board Response(Final language to be included on final

scorecard)

§1.a.IIntergovernmentalOrganization (IGO)Protections

The GAC recalls its longstandingadvice on the topic of IGO protectionsand is closely monitoring the ongoingPDP on IGO-‐INGO Access to CurativeRights Protection Mechanisms. TheGAC remains open to working withthe GNSO to try to find a mutually-‐agreeable resolution to this issue. TheGAC also recalls the values ofopenness, transparency and inclusion,and representativeness and processintegrity, that are respectivelyenshrined in ICANN’s Bylaws andGNSO Operating Procedures.

a. The GAC advises the ICANN Boardto:

I. review closely the decisions onthis issue in order to ensure thatthey are compatible with thesevalues and reflect the full factualrecord.

RATIONALEAlthough the ICANN Community isstill awaiting the final report for the

The Board understands that the GACwishes for the ICANN Board to:

1. Review the decisions on the issueof IGO Protections to ensure thatthe decisions are compatible withthese values and reflect the fullfactual record.

The Board understands that the GAC isconcerned that the GNSO PDP WorkingGroup on IGO-‐INGO Curative RightsProtection Mechanisms may issuerecommendations that differ from GACAdvice. The Board understands that theGAC wishes that ICANN Board conduct aclose review of GNSO Policyrecommendations, including those thatmay differ from GAC advice.

The GNSO Council notes that the GAC hasrecalled its previous advice regardingaccess to curative dispute resolutionmechanisms by IGOs. Similarly, we referthe Board to our earlier responses, notingthat the work of the Policy DevelopmentProcess (PDP) on this topic (IGO/INGOAccess to Curative Rights) is nearingcompletion, and that this working group(WG) anticipates publication of its FinalReport and recommendations prior to theconclusion of 2017.

The Council notes favorably that the GACremains open to working with the GNSOto try to find a mutually agreeableresolution to this issue, and we share thatgoal. In regard to the GAC’s reference tothe values of openness, transparency andinclusion, as well as representativenessand process integrity, that are respectivelyenshrined in ICANN’s Bylaws and GNSOOperating Procedures, the Council islikewise committed to these values andtheir application to the ongoing work ofthe PDP WG.

The Board accepts the GAC advice toreview closely the policyrecommendations, including those thatmay differ from GAC advice and theassociated public comments before takingaction. The Board acknowledges the GAC’slongstanding advice on the need toprotect IGO acronyms in the domain namesystem, and appreciates the GAC’s interestin the outcome of the GNSO PDP on IGO-‐INGO Access to Curative RightsMechanisms.

While the direct management of a GNSOPDP is a role for the GNSOCouncil, the Board does maintain stronginterest in the progress of this PDP. TheBoard looks forward to receiving the finalpolicy recommendations from the GNSOas well as any further GAC advice on thistopic.

The Board remains committed tofacilitating discussions between allaffected parties that may resolve anyconflicts that may arise, and acknowledgesits role under the ICANN Bylaws to act in

2


scorecard)





scorecard)


scorecard)

PDP on IGO-‐INGO Access to CurativeRights Protection Mechanisms,preliminary communications indicatethat the Working Group’s proposalwill conflict with GAC advice on theissue and GAC input to the PDP aswell as the comments of over 20 IGOswho submitted comments to theWorking Group’s draft report. TheBoard plays an important role inensuring the proper application of theICANN Bylaws and GNSO OperatingProcedures, and the GAC expects thata basic safeguard would be a closeBoard review of GNSO policyrecommendations, especially wheresuch recommendations directlycontradict GAC advice.

The Council further notes that thereferenced WG has held itself open toreceive all viewpoints relevant to itsefforts, has operated in a transparent andfully inclusive manner, enjoysrepresentation from a broad spectrum ofthe ICANN community, and has engaged ina work process displaying high integrityand rigorous policy analysis.

The Council further notes that the WGheld an open working session regardingthe likely content of its Final Report duringthe ICANN 60 meeting for the purpose ofreceiving community feedback; that thissession was attended by IGOrepresentatives as well as by the ICANNCEO and other senior executives, and byseveral ICANN Board members; and thatfurther input on its likelyrecommendations was provided at thatsession.

As regards that the GAC’s concern that theWorking Group’s final proposal mayconflict with GAC advice on the issue, GACinput to the PDP, and the comments ofover 20 IGOs who submitted comments tothe Working Group’s draft report, theCouncil would first note that its priorresponse to the GAC’s ICANN 59Johannesburg Communique on this topic

the best interests of ICANN and thecommunity, within the context of ICANN’sMission and Core Values.

3


scorecard)





scorecard)


scorecard)

stated: “The PDP recently conducted aPublic Comment period on its InitialReport, and received multiple thoughtfulsubmissions including many from IGOs.Each comment from the communitycontaining new data or ideas wasextensively considered and discussed bythe PDP working group, and the PDPleadership reports that its Initial Report islikely to be materially amended as a resultof taking these comments on board.”

The PDP WG also considered the October2016 “IGO Small Group Proposal”, andincluded it in their Initial Report analysis.Notwithstanding that thoroughconsideration, Council acknowledges thatit remains likely that the WG’s FinalRecommendations will diverge from GACAdvice and the “IGO Small GroupProposal” in at least two respects. First,the PDP WG does not recommend thecreation of a new, separate disputeprocess solely for the use of IGOs, butinstead outlines the means by which theseorganizations can better access existingprocesses like UDRP and URS; integral tothe WG’s conclusion on this matter was itsinability to find any basis for an IGO’sstanding to utilize ICANN-‐providedalternative to judicial process other thantrademark rights. Second, the PDP WG

4


scorecard)





scorecard)


scorecard)

does not conclude that it is within their (orthe GNSO's, or ICANN’s) remit to grant,extend, or restrict the jurisdictionalimmunity protections of IGOs, or to limitthe legal rights of registrants who areparty to a dispute with an IGO, becausethese are matters within the jurisdiction ofnational legislatures and courts. Overall,the WG was careful to observe a cleardemarcation between the limits ofICANN’s authority and the powers ofnational courts and legislatures, and wewould hope that the GAC would welcomethat respect for sovereign powers.

Finally, the GNSO Council notes that someparties have advised the GAC that theWG’s likely recommendations are basedupon a decision to elevate commercialinterests over GAC input, and the GNSOCouncil is not aware of any evidencesupporting that assertion. The GNSOCouncil chartered this PDP with theobjective of ensuring that IGOs and INGOshave ready access to low-‐cost andeffective rights protection mechanisms, inorder to mitigate abuse of their identitiesin the DNS and to support in their workserving the public needs of citizens acrossthe globe. The PDP WG continues tobelieve that its Final Report will meet thatgoal. We eagerly await publication of the

5


scorecard)





scorecard)


scorecard)

PDP’s final recommendations, andsubsequent discussions among thecommunity preceding and at ICANN61.The GNSO Council is committed to arigorous review of the Final Report whenwe consider whether to approve itstransmission to the Board. We wouldlikewise urge the Board and GAC to accordthat Report a complete andcomprehensive reading before taking aposition on the recommendationscontained therein.

§2.a.I -‐ §2.a.IIEnabling inclusive,informed andmeaningfulparticipation inICANN

a. The GAC advises the ICANN Boardto instruct ICANN Org to:

I. Develop a simple and efficientdocument managementsystem that allows non-‐experts to easily and quicklyaccess and identifydocuments, starting withdefining minimal requirementsthat ensure that everydocument has a title and adate or reference number,identifies the author andindicates intended recipients,makes reference to theprocess it belongs to andexplains the acronyms used inthe document;

The Board understands that the GACwishes for the ICANN Board to instructthe ICANN Org to:

1. Develop a document managementsystem that allows non-‐experts toeasily and quickly access andidentify documents, starting withdefining minimal requirements thatensure that every document has atitle and a date or referencenumber, identifies the author andindicates intended recipients,makes reference to the process itbelongs to and explains theacronyms used in the document.

The GNSO Council supports this GACadvice, which we consider timely andconsistent with ICANN org’s efforts thatare underway to improve “findability” ofinformation on ICANN website, as part ofthe recently launched Open Data (orInformation Transparency) Initiative(https://www.icann.org/news/blog/creating-‐content-‐governance-‐ and-‐rebuilding-‐the-‐infrastructure-‐ of-‐icann-‐s-‐public-‐sites).

The ICANN org and the community havelong recognized the changing environmentand the need for lowering barriers tobroaden participation in ICANN and theGNSO policy development process. To thisend, implementation of recommendationsrelating to participation improvement

The Board accepts this advice and iscommitted to accountability andtransparency and pursuing easilyunderstandable and relevant informationon matters of concern to all stakeholders.The Board’s commitment to these valuesaligns with the recently startedInformation Transparency Initiative(https://www.icann.org/news/blog/creating-‐content-‐governance-‐and-‐rebuilding-‐the-‐infrastructure-‐of-‐icann-‐s-‐public-‐sites).The Board acknowledges and agrees withthe need to ensure effective and equalparticipation in the policy process by allstakeholders, which is in line with theMission and the Values, as expressed inthe Bylaws.

6


scorecard)





scorecard)


scorecard)

§2.a.I -‐ §2.a.IIEnabling inclusive,informed andmeaningfulparticipation inICANN

II. Produce easily understandableexecutive summaries, keypoints and synopses (using e.g.infographs, videos and otherinnovative ways of presentinginformation) for all relevantissues, processes andactivities, so that also non-‐expert stakeholders will beable to (a) quickly determine ifa particular issue is of concernto them and (b) if yes, toparticipate in the policyprocess easily and effectively,on equal footing with otherstakeholders. This should bedone at least, but not only,before putting issues up forpublic comment. Attentionshould be paid to using plainEnglish (and if possibletranslations into otherlanguages) in order to allownon-‐English native speakers tounderstand the issues;

RATIONALEThis advice is consistent with a jointstatement developed by the GAC and

The Board understands that the GACwishes for the ICANN Board to instructthe ICANN Org to:1. Produce executive summaries, key

points and synopses for all relevantissues, processes and activities, sothat non-‐expert stakeholders will beable to determine if an issue is ofconcern to them, and if so, how toparticipate in the process. Thisshould be done at least, but notonly, before putting issues up forpublic comment. Attention shouldbe paid to using plain English (and ifpossible translations into otherlanguages) in order to allow non-‐English native speakers tounderstand the issues.

The Board understands that the GAC andALAC believe it is critical to ICANN’slegitimacy and part of ICANN’s corevalues to encourage meaningfulparticipation in ICANN’s processes bynon-‐expert stakeholders, and part ofICANN’s responsibility to make theirvoices, their needs and interests heard.

from the most recent GNSO review isunderwayhttps://community.icann.org/display/GRWG?preview=/61610342/64069440/GNSO%20Review%20.In addition, the draft recommendations toimprove diversity as part of the CCWG-‐Accountability Work Stream 2 have beenfinalized and are currently open for publiccomment https://www.icann.org/public-‐comments/accountability-‐ diversity-‐2017-‐10-‐26-‐en.

Implementation of this GAC advice couldgo some way to lowering information andlanguage barriers for many communitystakeholders. It should also improveoperational efficiency of the ICANN organd ICANN staff.

The Board also understands that theICANN org currently produces monthlyone-‐pager PDP updates, regular pre-‐andpost-‐ICANN Meeting Reports andnewsletters highlighting specific publiccomment dates, policy developmentmilestones and participationopportunities, which are all produced inplain English and with a view towardconciseness. In addition, brief videointerviews with community leaders areproduced at each ICANN meeting toshowcase key achievements.

New courses on the ICANN Learn Onlineplatform have been developed on variouspolicy processes, and updated slide decksand infographics depicting thecommunity’s work processes have beenmade available.

Executive summaries of all PDP reportsand other major documents are routinelytranslated for publication in the six officialUnited Nations languages, and livecaptioning and other translation servicesare being used for an increasing numberof community group calls.

The Board will continue to encourage theICANN organization to produce materialsfor community use that will facilitate


scorecard)





scorecard)


scorecard)

the At Large Advisory Committee(ALAC) which will be publishedseparately.

One of ICANN’s core values is to seekand support “broad, informedparticipation reflecting the functional,geographic, and cultural diversity ofthe Internet at all levels of policydevelopment and decision-‐making toensure that the bottom-‐up,multistakeholder policy developmentprocess is used to ascertain the globalpublic interest and that thoseprocesses are accountable andtransparent” (Bylaws Section 1.2.c.ii)

In the view of the GAC and the ALAC itis not only among ICANN’s core valuesbut also critical to ICANN’s legitimacyto act in the global public interest toallow non-‐expert stakeholders tomeaningfully participate in ICANN’sprocesses and make their voices, theirneeds and interests heard, and dulytake them into account in order to actand take decisions that are in fact, inthe global public interest. Theseproposed measures will go some wayto address this.

broad and meaningful participation fromall stakeholders globally and is open tosuggestions on further improvement, andwill balance this against the availability ofresources.

§3.a.I.1 -‐ §3.a.I.4General Data

a. The GAC advises the ICANN Boardthat:


As part of the Board-‐initiated GNSO policydevelopment process to define the

The Board accepts this advice and directsthe ICANN org to continue to seek to

8


scorecard)





scorecard)


scorecard)

ProtectionRegulation(GDPR)/WHOIS

I. the 2007 GAC WHOIS Principles(attached) continue to reflectthe important public policyissues associated with WHOISservices. Accordingly, ICANNshould take these issues intoaccount as it moves forwardwith its planning to complywith the European Union’sGeneral Data ProtectionRegulation (GDPR). In theseprinciples, the GAC has notablyrecognized that WHOIS data(also known as RegistrationDirectory Services) is used for anumber of legitimate activities,including:

1. Assisting law enforcementauthorities in investigationsand in enforcing nationaland international laws,assisting in combattingagainst abusive use ofinternet communicationtechnologies;

2. Assisting businesses, otherorganizations, and users in

1. Take the GAC WHOIS Principlesinto account as it moves forwardwith planning to comply with theEuropean Union’s General DataProtection Regulation (GDPR).

The Board understands that the GAC hasrecognized that the WHOIS data is usedfor a number of legitimate activities,including:

1. Assisting law enforcementauthorities in investigations andin enforcing national andinternational laws, assisting incombatting against abusive useof internet communicationtechnologies;

2. Assisting businesses, otherorganizations, and users incombatting fraud, complyingwith relevant laws, andsafeguarding the interests of thepublic;

3. Combatting infringement andmisuse of intellectual property;and

purpose of collecting, maintaining andproviding access to gTLD registration data,and consider safeguards for protectingdata, the Next-‐Generation RegistrationDirectory Services (RDS) to replace WHOISPolicy Development Process WorkingGroup (WG) is closely following thedevelopments with regards to GDPR. Toassist in informing the RDS WG’sdeliberation on key concepts related tothe WG’s charter questions that areimpacted by data protection laws, such asthe GDPR, the WG has taken twoadditional steps:

(1) the WG solicited input from ccTLDRegistry Operators on theirapproaches to GDPR compliance,

and

(2) retained the services ofindependent legal counsel toanswer questions about theimpact of data protection laws onregistration data and directoryservices previously answered bysenior EU data protection experts(both inputs can be found here:https://community.icann.org/x/J1zwAw

balance the interest of maintaining theexisting WHOIS services to the extentpossible while complying with the GDPR.The Board also acknowledges that theWHOIS/RDS data is used for manyactivities, such as those described by thecommunity in the user stories posted onthe Data Protection and Privacy webpage.

The Board welcomes the GAC’s fullengagement with the community on theGDPR-‐related discussions and iscommitted to continuing to facilitate thisdiscussion in a transparent way. Anyassistance GAC members provide toencourage the full participation ofEuropean data protection agencies inICANN community conversations would beappreciated.

The Board is aware and receiving updatesfrom the organization on the ongoingfacilitation, under the guidance of Göranand GAC leadership, on a variety of topicsthat are of interest to the GAC.

The organization is grateful for theopportunity to hold these ongoingdialogues. One example of this is theregular calls between the ICANN org andthe GAC about GDPR. These calls provide

9


scorecard)





scorecard)


scorecard)

combatting fraud,complying with relevantlaws, and safeguarding theinterests of the public;

3. Combatting infringementand misuse of intellectualproperty; and

4. Contributing to userconfidence in the Internetas a reliable and efficientmeans of information andcommunication by helpingusers identify persons orentities responsible forcontent and servicesonline.

4. Contributing to user confidencein the Internet as a reliable andefficient means of informationand communication by helpingusers identify persons or entitiesresponsible for content andservices online.

The GNSO Council is concerned about thefuture of WHOIS in light of the impact ofGDPR and acknowledges that this topiccontinues to be under significantdiscussion in our community.

the opportunity to discuss the context ofdifferent issues.

§3.b.I.1 -‐ §3.b.I.2General DataProtectionRegulation(GDPR)/WHOIS

b. The GAC advises the ICANN Boardthat:

I. As it considers how to complywith the GDPR with regard toWHOIS, it should use its bestefforts to create a system thatcontinues to facilitate thelegitimate activities recognizedin the 2007 Principles,including by:


1. As it considers how to comply withGDPR with regard to WHOIS, use itsbest efforts to create a system thatcontinues to facilitate thelegitimate activities recognized inthe 2007 GAC WHOIS Principles.

The Board accepts this advice andwelcomes the GAC’s full engagement withthe community on the GDPR-‐relateddiscussions and is committed tocontinuing to facilitate this discussion in atransparent way. In a 21 December 2017blog from the ICANN org President andCEO, as well as in other fora, Göran Marbyhas emphasized that the organization hasmade it a high priority to find, to thegreatest extent possible, a path forward toensure compliance with the GDPR while

10


scorecard)





scorecard)


scorecard)

1. Keeping WHOIS quicklyaccessible for security andstability purposes, forconsumer protection andlaw enforcementinvestigations, and forcrime prevention efforts,through user-‐friendly andeasy access tocomprehensiveinformation to facilitatetimely action.

2. Keeping WHOIS quicklyaccessible to the public(including businesses andother organizations) forlegitimate purposes,including to combat fraudand deceptive conduct, tocombat infringement andmisuse of intellectualproperty, and to engage indue diligence for onlinetransactions andcommunications.

The Board understands that the GAC hasrecognized that these legitimate activitiesinclude:

1. Keeping WHOIS quickly accessiblefor security and stabilitypurposes, for consumerprotection and law enforcementinvestigations, and for crimeprevention efforts, through user-‐friendly and easy access tocomprehensive information tofacilitate timely action.

2. Keeping WHOIS quickly accessibleto the public (includingbusinesses and otherorganizations) for legitimatepurposes, including to combatfraud and deceptive conduct, tocombat infringement and misuseof intellectual property, and toengage in due diligence for onlinetransactions andcommunications.

maintaining WHOIS services. This remainsa critical point on the path to findworkable solutions to ensure bothcompliance with the law and ICANN’scontracts.

§3.c.I.1 -‐ §3.c.I.2General DataProtection

c. The GAC advises the ICANN Boardto:


The Board accepts the advice and notesthat the ICANN Org has submitted these

11


scorecard)





scorecard)


scorecard)

Regulation(GDPR)/WHOIS

I. seek information from itsoutside counsel tasked withproviding guidance on GDPRissues that addresses thefollowing issues:

1. What are the optionsunder the GDPR to ensurethe lawful availability ofWHOIS/RDS data forconsumer protection andlaw enforcementactivities? In particular,are there changes topolicy or the legalframework that should beconsidered with a view topreserving thefunctionality of the WHOISto the greatest extentpossible for thesepurposes and others alsorecognized as legitimate?This question includestasks carried out in thepublic interest and taskscarried out for alegitimate purpose,including preventing fraudand deceptive activities,

1. Seek information from its outsidecounsel that addresses thefollowing issues:

What are the options under theGDPR to ensure the lawfulavailability of WHOIS/RDS datafor consumer protection and lawenforcement activities and forthe public, including businessesand other organizations? Inparticular, are there changes topolicy or the legal frameworkthat should be considered with aview to preserving thefunctionality of the WHOIS to thegreatest extent possible for thesepurposes and others alsorecognized as legitimate? Thisquestion includes tasks carriedout in the public interest andtasks carried out for a legitimatepurpose, including preventingfraud and deceptive activities,investigating and combattingcrime, promoting andsafeguarding public safety,consumer protection, cyber-‐security etc.

questions to the Hamilton firm andreceived a response.

The GAC’s questions regarding GDPR wereshared with the Hamilton firm to consideras part of its next legal analysis. See:https://www.icann.org/en/system/files/files/gdpr-‐legal-‐analysis-‐part2-‐draft-‐questions-‐15nov17-‐en.pdf.

Hamilton replied to the questions in itssecond analysis, available here:https://www.icann.org/en/system/files/files/gdpr-‐memorandum-‐part2-‐18dec17-‐en.pdf.

12


scorecard)





scorecard)


scorecard)

investigating andcombatting crime,promoting andsafeguarding public safety,consumer protection,cyber-‐security etc.

2. What are the optionsunder the GDPR to ensurethe lawful availability ofWHOIS/RDS data for thepublic, includingbusinesses and otherorganizations? Thisquestion includes taskscarried out in the publicinterest and tasks carriedout for a legitimatepurpose, includingpreventing fraud anddeceptive activities,investigating andcombatting crime as wellas infringement andmisuse of intellectualproperty, promoting andsafeguarding public safety,consumer protection,cyber-‐security etc.

13


scorecard)





scorecard)


scorecard)

§3.d.I.General DataProtectionRegulation(GDPR)/WHOIS

d. The GAC advises the ICANN Boardthat:

I. it is urgent to address theseissues and that the GACshould be fully involved in thedesign and implementation ofany (including interim)solution and requests thatICANN practice transparencyvis-‐à-‐vis the multistakeholdercommunity in its GDPRactivities.

RATIONALEThis advice reflects the view ofgovernments that the continuedand lawful availability ofWHOIS/RDS data for consumerprotection, intellectual propertyrights protection and lawenforcement activities is a vitalpublic concern and that ICANNshould strive to explore all possiblemechanisms under the GDPR toensure that this data remainsavailable for legitimate activitiesthat protect the public and promotea safe, secure, and trustworthyonline environment.


1. Address these issues and toinvolve the GAC in the design andimplementation of any (includinginterim) solution and to practicetransparency with regard to themultistakeholder community inGDPR activities

The Board understands that the GACviews the continued and lawfulavailability of WHOIS/RDS data forconsumer protection, intellectualproperty rights protection and lawenforcement activities as a vital publicconcern. The Board also understands thatthe GAC wishes the Board to strive toexplore all possible mechanisms underthe GDPR to ensure this data remainsavailable for legitimate activities thatprotect the public and promote a safe,secure, and trustworthy onlineenvironment.

The Board accepts this advice andwelcomes the GAC’s full engagement withthe community on the GDPR-‐relateddiscussions and is committed tocontinuing to facilitate this discussion in atransparent way. The Board is aware andreceiving updates from the organizationon the ongoing facilitation, under theguidance of Göran and GAC leadership, ona variety of topics that are of interest tothe GAC. The organization is grateful forthe opportunity to hold these ongoingdialogues. One example of this is theregular calls between the ICANN org andthe GAC about GDPR. These calls providethe opportunity to discuss the context ofdifferent issues.

14


scorecard)





scorecard)


scorecard)

§4.a.I. Applicationsfor .amazon andrelated strings

a. The GAC advises the ICANN Boardto:

I. Continue facilitatingnegotiations between theAmazon Cooperation TreatyOrganization’s (ACTO) memberstates and the Amazoncorporation with a view toreaching a mutually acceptablesolution to allow for the use of.amazon as a top level domainname.

RATIONALEThe GAC recognizes the need to finda mutually acceptable solution forthe countries affected and theAmazon corporation to allow for theuse of .amazon as a top leveldomain name. The GAC considersthat the Board could continue toassist in facilitating the negotiationsbetween the parties.


1. Continue facilitating negotiationsbetween the Amazon CooperationTreaty Organization’s (ACTO)member states and the Amazoncorporation with the view ofreaching a mutually acceptablesolution to allow for the use of.amazon as a top level domainname.

The Board understands that the GACrecognizes the need to find a mutuallyacceptable solution for the affectedcountries and the Amazon corporation.The Board also understands that the GACconsiders that the Board could continueto assist in facilitating the negotiations.

The GNSO Council joins with the GAC inencouraging an agreement between theparties which will be mutuallyconstructive, but we also take note of theBoard’s recent resolution (1) adopting theIRP’s declaration for the Board toreconsider the .amazon applications and(2) delineating the time to ICANN61. Sincethis is the first test of accountability andtransparency under the new bylaws forICANN, we believe it is vital that ICANNhold fast to its commitment to the multi-‐stakeholder model and ICANN’s ownprocesses and procedures.”

The ICANN Board accepts the GAC adviceand has asked the ICANN org Presidentand CEO to facilitate negotiations betweenthe Amazon Cooperation TreatyOrganization’s (ACTO) member states andthe Amazon corporation.

arry - icann...6. next steps • next steps • official notice of renewal due to landlord – •...

Documents