idnits 2.17.1 draft-wilson-dance-architecture-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (9 November 2021) is 898 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DANCE A. Wilson 3 Internet-Draft Valimail 4 Intended status: Informational S. Huque 5 Expires: 13 May 2022 Salesforce 6 O. Johansson 7 Edvina.net 8 9 November 2021 10 An Architecture for DNS-Bound Client and Sender Identities 11 draft-wilson-dance-architecture-01 13 Abstract 15 This architecture document defines terminology, interaction, and 16 authentication patterns, related to the use of DANE DNS records for 17 TLS client and messaging peer identity, within the context of 18 existing object security and TLS-based protocols. 20 Discussion Venues 22 This note is to be removed before publishing as an RFC. 24 Discussion of this document takes place on the DANE Authentication 25 for Network Clients Everywhere Working Group mailing list 26 (dance@ietf.org), which is archived at 27 https://mailarchive.ietf.org/arch/browse/dance/. 29 Source for this draft and an issue tracker can be found at 30 https://github.com/ashdwilson/draft-dance-architecture. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 13 May 2022. 49 Copyright Notice 51 Copyright (c) 2021 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Simplified BSD License text 60 as described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 67 3. Communication Patterns . . . . . . . . . . . . . . . . . . . 5 68 3.1. Client/Server . . . . . . . . . . . . . . . . . . . . . . 6 69 3.2. Peer2peer . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.3. Decoupled . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 4.1. Mutual TLS Authentication . . . . . . . . . . . . . . . . 7 73 4.1.1. Example 1: TLS authentication for HTTPS API 74 interaction, DANE preauthorization . . . . . . . . . 7 75 4.1.2. IoT: Device to cloud . . . . . . . . . . . . . . . . 8 76 4.1.3. Oauth2 . . . . . . . . . . . . . . . . . . . . . . . 9 77 4.1.4. Edge Computing . . . . . . . . . . . . . . . . . . . 9 78 4.1.5. SIP and WebRTC inter-domain privacy . . . . . . . . . 9 79 4.1.6. DNS over TLS client authentication . . . . . . . . . 10 80 4.1.7. SMTP, STARTTLS . . . . . . . . . . . . . . . . . . . 10 81 4.1.8. SSH client . . . . . . . . . . . . . . . . . . . . . 10 82 4.1.9. Network Access . . . . . . . . . . . . . . . . . . . 10 83 4.1.10. LoRaWAN . . . . . . . . . . . . . . . . . . . . . . . 11 84 4.2. Object Security . . . . . . . . . . . . . . . . . . . . . 11 85 4.2.1. Structured data messages: JOSE/COSE . . . . . . . . . 11 86 4.3. Operational anomaly reporting . . . . . . . . . . . . . . 12 87 4.3.1. MUD reporting for improper provisioning . . . . . . . 12 88 4.3.2. XARF for abuse reporting . . . . . . . . . . . . . . 12 89 4.4. Adjacent Ecosystem Components . . . . . . . . . . . . . . 12 90 4.4.1. Certification Authority . . . . . . . . . . . . . . . 12 91 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 92 5.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 12 93 5.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 12 94 5.3. Availability . . . . . . . . . . . . . . . . . . . . . . 12 95 5.3.1. DNS Scalability . . . . . . . . . . . . . . . . . . . 13 96 5.3.2. Change of ownership . . . . . . . . . . . . . . . . . 13 98 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 99 7. Normative References . . . . . . . . . . . . . . . . . . . . 13 100 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 103 1. Introduction 105 A digital identity, in an abstract sense, possesses at least two 106 features: an identifier (or name), and a means of proving ownership 107 of the identifier. One of the most resilient mechanisms for tying an 108 identifier to a method for proving ownership of the identifier is the 109 digital certificate, issued by a well-run Certification Authority 110 (CA). The CA acts as a mutually trusted third party, a root of 111 trust. 113 Certificate-based identities are limited in scope by the issuing CA, 114 or by the namespace of the application responsible for issuing or 115 validating the identity. 117 An example of this limitation is well-illustrated by organizational 118 Public Key Infrastructure (PKI). Organizational PKI is very often 119 coupled with email and LDAP systems, and can be used for associating 120 a human or machine identity identifier with a public key. Within the 121 organization, authentication systems already agree on the roots of 122 trust for validating entity certificates issued by organizational 123 PKI. 125 Attempting to use organizational PKI outside the organization can be 126 challenging. In order to authenticate a certificate, the 127 certificate's CA must be trusted. CAs have no way of controlling 128 identifiers in certificates issued by other CAs. Consequently, 129 trusting multiple CAs at the same time can enable entity identifier 130 collisions. Asking an entity to trust your CA implies trust in 131 anything that your CA signs. This is why many organizations operate 132 a private CA, and require devices connecting to the organization's 133 networks or applications to possess certificates issued by the 134 organization's CA. 136 These limitations make the implementation and ongoing maintenance of 137 a PKI costly, and have a chilling effect on the broader adoption of 138 certificate-based IoT device identity. If certificate-based device 139 identity were easier to manage, more broadly trusted, and less 140 operationally expensive, more organizations and applications would be 141 able to use it. 143 The lack of trust between PKI domains has lead to a lack of simple 144 and globally scalable solutions for secure end-to-end inter-domain 145 communication between entities, such as SIP phones, email and chat 146 accounts and IoT devices belonging to different organizations. 148 DANCE seeks to make PKI-based IoT device identity universally 149 discoverable, more broadly recognized, and less expensive to maintain 150 by using DNS as the constraining namespace and lookup mechanism. 151 DANCE builds on patterns established by the original DANE RFCs to 152 enable client and sending entity certificate, public key, and trust 153 anchor discovery. DANCE allows entities to possess a first-class 154 identity, which, thanks to DNS, may be trusted by any application 155 also trusting the DNS. A first-class identity is an application- 156 independent identity. 158 2. Conventions and Definitions 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 162 "OPTIONAL" in this document are to be interpreted as described in 163 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 164 capitals, as shown here. 166 *This section will be interesting to define. We have great examples 167 of identity terminology in the https://datatracker.ietf.org/doc/html/ 168 draft-sarikaya-t2trg-sbootstrapping-06 document, but this document 169 also admits that there is semantic drift on terms like 170 "bootstrapping", depending on who's talking.* 172 *Identity provisioning:* This refers to the set of tasks required to 173 securely provision an asymmetric key pair for the device, sign the 174 certificate (if the public credential is not simply a raw public 175 key), and publish the public key or certificate in DNS. Under some 176 circumstances, these steps are not all performed by the same party or 177 organization. A manufacturer may instantiate the key pair, and a 178 systems integrator may be responsible for issuing (and publishing) 179 the device certificate in DNS. In some circumstances, a manufacturer 180 may also publish device identity records in DNS. In this case, the 181 system integrator needs to perform network and application access 182 configuration, since the identity already exists in DNS. 184 *Security Domain:* DNS-bound client identity allows the device to 185 establish secure communications with any server with a DNS-bound 186 identity, as long as a network path exists, the entity is configured 187 to trust its communicating peer by name, and agreement on protocols 188 can be achieved. The act of joining a security domain, in the past, 189 may have involved certificate provisioning. Now, it can be as simple 190 as using a manufacturer-provisioned identity to join the device to 191 the network and application. [Is the security domain defined by how 192 broadly the identity is recognized, or by the breadth of the 193 application or network access policy?] 195 *Client:* This architecture document adopts the definition of 196 "Client" from RFC 8446: "The endpoint initiating the TLS connection" 198 *Server:* This architecture document adopts the definition of 199 "Server" from RFC 8446: "The endpoint that did not initiate the TLS 200 connection" 202 *Sending agent:* Software which encodes and transmits messages. A 203 sending agent may perform tasks related to generating cryptographic 204 signatures and/or encrypting messages before transmission. 206 *Receiving agent:* Software which interprets and processes messages. 207 A receiving agent may perform tasks related to the decryption of 208 messages, and verification of message signatures. 210 *Store-and-forward system:* A message handling system in-path between 211 the sending agent and the receiving agent. 213 *Hardware supplier role:* The entity which manufactures or assembles 214 the physical device. In many situations, multiple hardware suppliers 215 are involved in producing a given device. In some cases, the 216 hardware supplier may provision an asymmetric key pair for the device 217 and establish the device identity in DNS. In some cases, the 218 hardware supplier may ship a device with software pre-installed. 220 *Systems integrator:* The party responsible for configuration and 221 deployment of application components. In some cases, the systems 222 integrator also installs the software onto the device, and may 223 provision the device identity in DNS. 225 *Consumer:* The entity or organization which pays for the value 226 provided by the application, and defines the success criteria for the 227 output of the application. 229 3. Communication Patterns 230 3.1. Client/Server 232 Client/server communication patterns imply a direct connection 233 between an entity which provides a service (the server), and an 234 entity which initiates a connection to the server, called a client. 235 A secure implementation of this pattern includes a TLS-protected 236 session directly between the client and the server. A secure 237 implementation may also include public key-based mutual 238 authentication. 240 Extending DANE to include client identity allows the server to 241 authenticate clients independent of the private PKI used to issue the 242 client certificate. This reduces the complexity of managing the CA 243 certificate collection, and mitigates the possibility of client 244 identifier collision. 246 3.2. Peer2peer 248 The extension also allows an application to find an application 249 identity and set up a secure communication channel directly. This 250 pattern can be used in mesh networking, IoT and in many communication 251 protocols for multimedia sessions, chat and messaging. 253 3.3. Decoupled 255 Decoupled architecture, frequently incorporating store-and-forward 256 systems, provides no direct connection between the producer and 257 consumer of information. The producer (or sending agent) and 258 consumer (or receiving agent) are typically separated by at least one 259 layer of messaging-oriented middleware. The Messaging-oriented 260 middleware components may act as a server for the purpose of 261 establishing TLS sessions for the producer and consumer. This allows 262 the assertion of identity between the middleware and sending agent, 263 and the middleware and receiving agent. The trust relationship 264 between the sending agent and receiving agent is based on the 265 presumed trustworthiness of the middleware, unless an identity can be 266 attached to the message itself, independent of transport and 267 middleware components. 269 Within many existing store-and-forward protocols, certificates may be 270 transmitted within the signed message itself. An example of this is 271 S/MIME. Within IoT applications, we find that networks may be more 272 constrained. Including certificates in message payloads can present 273 an unnecessary overhead on constrained network links. Decoupled 274 applications benefit from an out-of-band public key discovery 275 mechanism, which may enable the retrieval of certificates only when 276 needed, and sometimes using a less expensive network connection. 278 4. Use Cases 280 4.1. Mutual TLS Authentication 282 Using DNS to convey certificate information for authenticating TLS 283 clients gives a not-yet-authenticated client the ability to trigger a 284 DNS lookup on the server side of the TLS connection. An opportunity 285 for DDOS may exist when malicious clients can trigger arbitrary DNS 286 lookups. For instance, an authoritative DNS server which has been 287 configured to respond slowly, may cause a high concurrency of in- 288 flight TLS authentication processes as well as open connections to 289 upstream resolvers. This sort of attack (of type slowloris) could 290 have a performance or availability impact on the TLS server. 292 4.1.1. Example 1: TLS authentication for HTTPS API interaction, DANE 293 preauthorization 295 * The client initiates a TLS connection to the server. 297 * The TLS server compares the dane_clientid (conveyed via the DANE 298 Client Identity extension) to a list of allowed client domains. 300 * If the dane_clientid is allowed, the TLS server then performs a 301 DNS lookup for the client's TLSA record. If the dane_clientid is 302 not allowed, authentication fails. 304 * If the client's TLSA record matches the presented certificate or 305 public key, the TLS handshake completes successfully and the 306 authenticated dane_clientid is presented to the web application in 307 the (TBD) header field. 309 This pattern has the following advantages: 311 * This pattern translates well to TLS/TCP load balancers, by using a 312 TCP TLV instead of an HTTP header. 314 * No traffic reaches the application behind the load balancer unless 315 DANE client authentication is successful. 317 4.1.1.1. Example 2: TLS authentication for HTTPS API interaction, DANE 318 matching in web application 320 * The client initiates a TLS connection to the server. 322 * The TLS server accepts any certificate for which the client can 323 prove possession of the corresponding private key. 325 * The TLS server passes the certificate to the web application in 326 (TBD) header field. 328 * The HTTP request body contains the dane_clientid, and is passed to 329 the web application. 331 * The web application compares the dane_clientid to a list of 332 allowed clients or client domains. 334 * If the dane_clientid is allowed, the web application makes the DNS 335 query for the TLSA records for dane_clientid 337 * If the presented certificate (which was authenticated by the TLS 338 server) matches at least one TLSA record for dane_clientid, 339 authentication succeeds. 341 This pattern has the following advantages: 343 * In a web application where a TLS-terminating load balancer sits in 344 front of a web application, the authentication logic in the load 345 balancer remains simple. 347 * The web application ultimately decides whether to make the DNS 348 query to support DANE authentication. This allows the web 349 application to reject clients with identifiers which are not 350 allowed, before making a DNS query for TLSA retrieval and 351 comparison. No need to manage an allow-list in the load balancer. 353 * This can be implemented with no changes to the TLS handshake. 355 4.1.2. IoT: Device to cloud 357 Direct device-to-cloud communication is common in simple IoT 358 applications. Authentication in these applications is usually 359 accomplished using shared credentials like API keys, or using client 360 certificates. Client certificate authentication frequently requires 361 the consumer to maintain a CA. The CA trust anchor certificate is 362 installed into the cloud application, and used in the TLS 363 authentication process. 365 Using DANE for device identity can allow parties other than the 366 implementer to operate the CA. A hardware manufacturer can provide a 367 pre-established identity, with the certificate or public key already 368 published in DNS. This makes PKI-based identity more approachable 369 for small organizations which currently lack the resources to operate 370 an organizational CA. 372 4.1.3. Oauth2 374 [This can be a broad topic. Should we include, or wait until a re- 375 chartering to update?] 377 4.1.4. Edge Computing 379 https://datatracker.ietf.org/doc/html/draft-hong-t2trg-iot-edge- 380 computing-01 (Edge Computing) may require devices to mutually 381 authenticate in the field. A practical example of this pattern is 382 the edge computing in construction use case 383 [https://datatracker.ietf.org/doc/html/draft-hong-t2trg-iot-edge- 384 computing-01#section-6.2.1]. Using traditional certificate-based 385 identity, the sensor and the gateway may have certificates issued by 386 the same organizational PKI. By using DANE for client and sender 387 identity, the sensor and the gateway may have identities represented 388 by the equipment supplier, and still be able to mutually 389 authenticate. Important sensor measurements forwarded by the gateway 390 to the cloud may bear the DNS name and signature of the originating 391 sensor, and the cloud application may authenticate the measurement 392 independent of the gateway which forwarded the information to the 393 application. 395 4.1.5. SIP and WebRTC inter-domain privacy 397 End to end security in SIP is currently based on a classical S/MIME 398 model which has not received much implementation. There are also SIP 399 standards that build upon a trust chained anchored on the HTTP trust 400 chain (SIP identity, STIR). WebRTC has a trust model between the web 401 browser and the servers using TLS, but no inter-domain trust 402 infrastructure. WebRTC lacks a definition of namespace to map to 403 DNS, where SIP is based on an email-style addressing scheme. For 404 WebRTC the application developer needs to define the name space and 405 mapping to DNS. 407 By using DNS as a shared root of trust SIP and WebRTC end points can 408 anchor the keys used for DTLS/SRTP media channel setup. In addition, 409 SIP devices can establish security in the SIP messaging by using DNS 410 to find the callee's and the callers digital identity. 412 [https://datatracker.ietf.org/doc/html/draft-johansson-sipcore-dane- 413 sip] 415 *NOTE: include reference to earlier drafts for SIP + DANE* 417 4.1.6. DNS over TLS client authentication 419 4.1.7. SMTP, STARTTLS 421 4.1.8. SSH client 423 4.1.9. Network Access 425 4.1.9.1. EAP-TLS with RADIUS 427 4.1.9.1.1. Terminology 429 *Supplicant:* The entity which acts as the TLS client in the EAP-TLS 430 authentication protocol. This term is defined in IEEE 802.1x. The 431 suppliant acts as a client in the EAPOL (EAP over LAN) protocol, 432 which is terminated at the authenticator (defined below). 434 *Authentication server:* The entity which acts as the TLS server in 435 the EAP-TLS protocol. RADIUS (RFC 2865) is a frequently-used 436 authentication server protocol. 438 *Authenticator:* The authenticator is the device which acts as a 439 server the EAPOL (EAP over LAN) protocol, and is a client of the 440 authentication server. The authenticator is responsible for passing 441 EAP messages between the supplicant and the authentication server, 442 and for ensuring that only authenticated supplicants gain access to 443 the network. 445 https://datatracker.ietf.org/doc/html/rfc5216 (EAP-TLS) is a mature 446 and widely-used protocol for network authentication, for IoT and IT 447 equipment. IEEE 802.1x defines the encapsulation of EAP over LAN 448 access technologies, like IEEE 802.11 wireless and IEEE 802.3 449 ethernet. RADIUS is a protocol and server technology frequently used 450 for supporting the server side of EAP-TLS authentication. Guidance 451 for implementing RADIUS strongly encourages the use of a single 452 common CA for all supplicants, to mitigate the possibility of 453 identifier collisions across PKIs. The use of DANE for client 454 identity can allow the safe use of any number of CAs. DNS acts as a 455 constraining namespace, which prevents two unrelated CAs from issuing 456 valid certificates bearing the same identifier. Certificates 457 represented in DNS are valid, and all others are un-trusted. 459 4.1.9.2. RADSEC 461 The RADIUS protocol has a few recognized security problems. 462 https://datatracker.ietf.org/doc/html/rfc6614 (RADSEC) addresses the 463 challenges related to the weakness of MD5-based authentication and 464 confidentiality over untrusted networks by establishing a TLS session 465 between the RADIUS protocol client and the RADIUS protocol server. 466 RADIUS datagrams are then transmitted between the authenticator and 467 authentication server within the TLS session. Updating the RADSEC 468 standard to include the use of DANE for client and server identity 469 would allow a RADIUS server and client to mutually authenticate, 470 independent of the client's and server's issuing CAs. The benefit 471 for this use case is that a hosted RADIUS service may mutually 472 authenticate any client device, like a WiFi access point or ethernet 473 switch, via RADSEC, without requiring the distribution of CA 474 certificates. 476 4.1.10. LoRaWAN 478 *We should ask S. if he wants to contribute to this section* 480 4.2. Object Security 482 4.2.1. Structured data messages: JOSE/COSE 484 JOSE and COSE provide formats for exchanging authenticated and 485 encrypted structured data. JOSE defines the x5u field in 486 https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.5 487 (RFC7515), and COSE defines a field of the same name in 488 https://datatracker.ietf.org/doc/html/draft-ietf-cose- 489 x509-08#section-2 (draft-ietf-cose-x509) which can be used for out- 490 of-band x.509 certificate discovery. By adopting DANE for out-of- 491 band certificate discovery, CBOR and JSON data may be authenticated, 492 even if the originating sending agent not have IP connectivity, 493 provided that the sending agent's certificate is discoverable in DNS 494 and the receiving agent has access to DNS. 496 4.3. Operational anomaly reporting 498 4.3.1. MUD reporting for improper provisioning 500 4.3.2. XARF for abuse reporting 502 4.4. Adjacent Ecosystem Components 504 4.4.1. Certification Authority 506 5. Security Considerations 508 5.1. Confidentiality 510 DNS clients should use DNS over TLS with trusted DNS resolvers to 511 protect the identity of authenticating peers. 513 5.2. Integrity 515 The integrity of public keys represented in DNS is most important. 516 An altered public key can enable device impersonation, and the denial 517 of existence for a valid identity can cause devices to become un- 518 trusted by the network or the application. DNS records should be 519 validated by the DNS stub resolver, using the DNSSEC protocol. 521 Compartmentalizing failure domains within an application is a well- 522 known architectural best practice. Within the context of protecting 523 DNS-based identities, this compartmentalization may manifest by 524 hosting an identity zone on a DNS server which only supports the 525 resource record types essential for representing device identities. 526 This can prevent a compromised identity zone DNS server from 527 presenting records essential for impersonating web sites under the 528 organization's domain name. 530 The naming pattern suggested in 531 https://datatracker.ietf.org/doc/html/draft-huque-dane-client-cert 532 (https://datatracker.ietf.org/doc/html/draft-huque-dane-client-cert) 533 includes an underscore label (_device) which also prevents the 534 issuance of Web PKI-validating certificates in the event a DNS server 535 hosting a client identity zone, which is capable of presenting A and 536 AAAA records, is compromised. 538 5.3. Availability 539 5.3.1. DNS Scalability 541 In the use case for IoT an implementation must be scalable to a large 542 amount of devices. In many cases, identities may also be very short 543 lived as revocation is performed by simply removing a DNS record. A 544 zone will have to manage a large amount of changes as devices are 545 constantly added and de-activated. 547 In these cases it is important to consider the architecture of the 548 DNS zone and when possible use a tree-like structure with many 549 subdomain parts, much like reverse DNS records or how telephone 550 numbers are represented in the ENUM standard (RFC 6116). 552 If an authoritative resolver were configured to respond quite slowly 553 (think slow loris), is it possible to cause a DoS on the TLS server 554 via complete exhaustion of TCP connections? 556 The availability of a client identity zone is essential to permitting 557 clients to authenticate. If the DNS infrastructure hosting client 558 identities becomes unavailable, then the clients represented by that 559 zone cannot be authenticated. 561 *OEJ: We may want to have a discussion with the IETF DNS directorate. 562 The scalability section above is from a discussion with one of the 563 members...* 565 5.3.2. Change of ownership 567 What happens if an organization owning the client identity goes out 568 of business? What's the best way to transfer an identifier to 569 another zone? 573 6. IANA Considerations 575 This document has no IANA actions. 577 7. Normative References 579 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 580 Requirement Levels", BCP 14, RFC 2119, 581 DOI 10.17487/RFC2119, March 1997, 582 . 584 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 585 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 586 May 2017, . 588 Acknowledgments 590 TODO acknowledge. 592 Authors' Addresses 594 Ash Wilson 595 Valimail 597 Email: ash.d.wilson@gmail.com 599 Shumon Huque 600 Salesforce 602 Email: shuque@gmail.com 604 Olle Johansson 605 Edvina.net 607 Email: oej@edvina.net