DANCE A. Wilson Internet-Draft Valimail Intended status: Informational S. Huque Expires: 25 April 2022 Salesforce O. Johansson Edvina.net 22 October 2021 An Architecture for DNS-Bound Client and Sender Identities draft-wilson-dance-architecture-00 Abstract TODO Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 25 April 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Wilson, et al. Expires 25 April 2022 [Page 1] Internet-Draft DNS-Bound Identities October 2021 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Communication Patterns . . . . . . . . . . . . . . . . . . . 4 3.1. Client/Server . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Peer2peer . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Decoupled . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Mutual TLS Authentication . . . . . . . . . . . . . . . . 5 4.1.1. Device to cloud . . . . . . . . . . . . . . . . . . . 5 4.1.2. Oauth2 . . . . . . . . . . . . . . . . . . . . . . . 6 4.1.3. Edge Computing . . . . . . . . . . . . . . . . . . . 6 4.1.4. SIP and WebRTC inter-domain privacy . . . . . . . . . 6 4.1.5. DNS over TLS client authentication . . . . . . . . . 7 4.1.6. SMTP, STARTTLS . . . . . . . . . . . . . . . . . . . 7 4.1.7. Network Access . . . . . . . . . . . . . . . . . . . 7 4.1.8. LoRaWAN . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Object Security . . . . . . . . . . . . . . . . . . . . . 7 4.2.1. Structured data messages: JOSE/COSE . . . . . . . . . 8 4.3. Operational anomaly reporting . . . . . . . . . . . . . . 8 4.3.1. MUD reporting for improper provisioning . . . . . . . 8 4.3.2. XARF for abuse reporting . . . . . . . . . . . . . . 8 4.4. Adjacent Ecosystem Components . . . . . . . . . . . . . . 8 4.4.1. Certification Authority . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 8 5.2. Availability . . . . . . . . . . . . . . . . . . . . . . 9 5.2.1. DNS Scalability . . . . . . . . . . . . . . . . . . . 9 5.2.2. Change of ownership . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction A digital identity, in an abstract sense, possesses at least two features: an identifier (or name), and a means of proving ownership of the identifier. One of the most resilient mechanisms for tying an identifier to a method for proving ownership of the identifier is the digital certificate, issued by a well-run Certification Authority (CA). The CA acts as a mutually trusted third party, a root of trust. Certificate-based identities are limited in scope by the issuing CA, or by the namespace of the application responsible for issuing or validating the identity. Wilson, et al. Expires 25 April 2022 [Page 2] Internet-Draft DNS-Bound Identities October 2021 An example of this limitation is well-illustrated by organizational Public Key Infrastructure (PKI). Organizational PKI is very often coupled with email and LDAP systems, and can be used for associating a human or machine identity identifier with a public key. Within the organization, authentication systems already agree on the roots of trust for validating entity certificates issued by organizational PKI. Attempting to use organizational PKI outside the organization can be challenging. In order to authenticate a certificate, the certificate's CA must be trusted. CAs have no way of controlling identifiers in certificates issued by other CAs. Consequently, trusting multiple CAs at the same time can enable entity identifier collisions. Asking an entity to trust your CA implies trust in anything that your CA signs. This is why many organizations operate a private CA, and require devices connecting to the organization's networks or applications to possess certificates issued by the organization's CA. These limitations make the implementation and ongoing maintenance of a PKI costly, and have a chilling effect on the broader adoption of certificate-based IoT device identity. If certificate-based device identity were easier to manage, more broadly trusted, and less operationally expensive, more organizations and applications would be able to use it. The lack of trust between PKI domains has lead to a lack of simple and globally scalable solutions for secure end-to-end inter-domain communication between entities, such as SIP phones, email and chat accounts and IoT devices belonging to different organizations. DANCE seeks to make PKI-based IoT device identity universally discoverable, more broadly recognized, and less expensive to maintain by using DNS as the constraining namespace and lookup mechanism. DANCE builds on patterns established by the original DANE RFCs to enable client and sending entity certificate, public key, and trust anchor discovery. DANCE allows entities to possess a first-class identity, which, thanks to DNS, may be trusted by any application also trusting the DNS. A first-class identity is an application- independent identity. 2. Conventions and Definitions {::boilerplate bcp14-tagged} Wilson, et al. Expires 25 April 2022 [Page 3] Internet-Draft DNS-Bound Identities October 2021 *This section will be interesting to define. We have great examples of identity terminology in the https://datatracker.ietf.org/doc/html/ draft-sarikaya-t2trg-sbootstrapping-06 document, but this document also admits that there is semantic drift on terms like "bootstrapping", depending on who's talking.* *Identity provisioning:* This refers to the set of tasks required to securely provision an asymmetric key pair for the device, sign the certificate (if the public credential is not simply a raw public key), and publish the public key or certificate in DNS. Under some circumstances, these steps are not all performed by the same party or organization. A manufacturer may instantiate the key pair, and a systems integrator may be responsible for issuing (and publishing) the device certificate in DNS. In some circumstances, a manufacturer may also publish device identity records in DNS. In this case, the system integrator needs to perform network and application access configuration, since the identity already exists in DNS. *Security Domain:* DNS-bound client identity allows the device to establish secure communications with any server with a DNS-bound identity, as long as a network path exists, the entity is configured to trust its communicating peer by name, and agreement on protocols can be achieved. The act of joining a security domain, in the past, may have involved certificate provisioning. Now, it can be as simple as using a manufacturer-provisioned identity to join the device to the network and application. Is the security domain defined by how broadly the identity is recognized, or by the breadth of the application or network access policy? 3. Communication Patterns 3.1. Client/Server Client/server communication patterns imply a direct connection between an entity which provides a service (the server), and an entity which initiates a connection to the server, called a client. A secure implementation of this pattern includes a TLS-protected session directly between the client and the server. A secure implementation may also include public key-based mutual authentication. Extending DANE to include client identity allows the server to authenticate clients independent of the private PKI used to issue the client certificate. This reduces the complexity of managing the CA certificate collection, and mitigates the possibility of client identifier collision. Wilson, et al. Expires 25 April 2022 [Page 4] Internet-Draft DNS-Bound Identities October 2021 3.2. Peer2peer The extension also allows an application to find an application identity and set up a secure communication channel directly. This pattern can be used in mesh networking, IoT and in many communication protocols for multimedia sessions, chat and messaging. 3.3. Decoupled Decoupled architecture, sometimes referred to as store-and-forward, provides no direct connection between the producer and consumer of information. The producer and consumer are typically separated by at least one layer of messaging-oriented middleware. The Messaging- oriented middleware components may act as a server for the purpose of establishing TLS sessions for the producer and consumer. This allows the assertion of identity between the middleware and producer, and the middleware and consumer. The trust relationship between the producer and consumer is based on the presumed trustworthiness of the middleware, unless an identity can be attached to the message itself, independent of transport and middleware components. Within many existing store-and-forward protocols, certificates may be transmitted within the signed message itself. An example of this is S/MIME. Within IoT applications, we find that networks may be more constrained. Including certificates in message payloads can present an unnecessary overhead on constrained network links. Decoupled applications benefit from an out-of-band public key discovery mechanism, which may enable the retrieval of certificates only when needed, and sometimes using a less expensive network connection. 4. Use Cases 4.1. Mutual TLS Authentication 4.1.1. Device to cloud Direct device-to-cloud communication is common in simple IoT applications. Authentication in these applications is usually accomplished using shared credentials like API keys, or using client certificates. Client certificate authentication requires the implementer to manage a certification authority. The CA trust anchor certificate is installed into the cloud application, and used in the TLS authentication process. Wilson, et al. Expires 25 April 2022 [Page 5] Internet-Draft DNS-Bound Identities October 2021 Using DANE for device identity can allow parties other than the implementer to operate the CA. A hardware secure element provider can provide a pre-established identity, with the certificate or public key already published in DNS. This can make PKI-based identity more approachable for small organizations which currently lack the resources to operate an organizational CA. 4.1.2. Oauth2 [This can be a broad topic. Should we include, or wait until a re- chartering to update?] 4.1.3. Edge Computing https://datatracker.ietf.org/doc/html/draft-hong-t2trg-iot-edge- computing-01 (Edge Computing) may require devices to mutually authenticate in the field. A practical example of this pattern is the edge computing in construction use case [https://datatracker.ietf.org/doc/html/draft-hong-t2trg-iot-edge- computing-01#section-6.2.1]. Using traditional certificate-based identity, the sensor and the gateway may have certificates issued by the same organizational PKI. By using DANE for client and sender identity, the sensor and the gateway may have identities represented by the equipment supplier, and still be able to mutually authenticate. Important sensor measurements forwarded by the gateway to the cloud may bear the DNS name and signature of the originating sensor, and the cloud application may authenticate the measurement independent of the gateway which forwarded the information to the application. 4.1.4. SIP and WebRTC inter-domain privacy End to end security in SIP is currently based on a classical S/MIME model which has not received much implementation. There are also SIP standards that build upon a trust chained anchored on the HTTP trust chain (SIP identity, STIR). WebRTC has a trust model between the web browser and the servers using TLS, but no inter-domain trust infrastructure. WebRTC lacks a definition of namespace to map to DNS, where SIP is based on an email-style addressing scheme. For WebRTC the application developer needs to define the name space and mapping to DNS. By using DNS as a shared root of trust SIP and WebRTC end points can anchor the keys used for DTLS/SRTP media channel setup. In addition, SIP devices can establish security in the SIP messaging by using DNS to find the callee's and the callers digital identity. Wilson, et al. Expires 25 April 2022 [Page 6] Internet-Draft DNS-Bound Identities October 2021 [https://datatracker.ietf.org/doc/html/draft-johansson-sipcore-dane- sip] *NOTE: include reference to earlier drafts for SIP + DANE* 4.1.5. DNS over TLS client authentication 4.1.6. SMTP, STARTTLS 4.1.7. Network Access 4.1.7.1. EAP-TLS https://datatracker.ietf.org/doc/html/rfc5216 (EAP-TLS) is frequently used for network authentication, for IoT and traditional IT equipment. RADIUS is a protocol and server technology frequently used for supporting the server side of EAP-TLS authentication. Guidance for implementing RADIUS strongly encourages the use of a single common CA for all supplicants. The use of DANE for client identity can allow the safe use of any number of CAs. DNS acts as a constraining namespace, which prevents two unrelated CAs from issuing valid certificates bearing the same identifier. Certificates represented in DNS are valid, and all others are un-trusted. 4.1.7.2. RADSEC The RADIUS protocol has a few recognized security problems. https://datatracker.ietf.org/doc/html/rfc6614 (RADSEC) addresses the challenges related to the weakness of MD5-based authentication and confidentiality over untrusted networks by establishing a TLS session between the client and the RADIUS server. RADIUS datagrams are then transmitted within the TLS session. Updating the RADSEC standard to include the use of DANE for client and server identity would allow a RADIUS server and client to mutually authenticate, independent of the client's and server's issuing CAs. The benefit for this use case is that a hosted RADIUS service may mutually authenticate any client device, like a WiFi access point or ethernet switch, via RADSEC, without requiring the distribution of CA certificates. 4.1.8. LoRaWAN *We should ask S. if he wants to contribute to this section* 4.2. Object Security Wilson, et al. Expires 25 April 2022 [Page 7] Internet-Draft DNS-Bound Identities October 2021 4.2.1. Structured data messages: JOSE/COSE JOSE and COSE provide formats for exchanging authenticated and encrypted structured data. JOSE defines the x5u field in https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.5 (RFC7515), and COSE defines a field of the same name in https://datatracker.ietf.org/doc/html/draft-ietf-cose- x509-08#section-2 (draft-ietf-cose-x509) which can be used for out- of-band x.509 certificate discovery. By adopting DANE for out-of- band certificate discovery, CBOR and JSON data may be authenticated, even if the originating entity does not have IP connectivity, provided that the originating entity's certificate is discoverable in DNS and the authenticating system has access to the DNS. 4.3. Operational anomaly reporting 4.3.1. MUD reporting for improper provisioning 4.3.2. XARF for abuse reporting 4.4. Adjacent Ecosystem Components 4.4.1. Certification Authority 5. Security Considerations 5.1. Confidentiality DNS clients should use DNS over TLS with trusted DNS resolvers to protect the identity of authenticating peers. Integrity The integrity of public keys represented in DNS is most important. An altered public key can enable device impersonation, and the denial of existence for a valid identity can cause devices to become un-trusted by the network or the application. Compartmentalizing failure domains within an application is a well- known architectural best practice. Within the context of protecting DNS-based identities, this compartmentalization may manifest by hosting an identity zone on a DNS server which only supports the resource record types essential for representing device identities. This can prevent a compromised identity zone DNS server from presenting records essential for impersonating web sites under the organization's domain name. Wilson, et al. Expires 25 April 2022 [Page 8] Internet-Draft DNS-Bound Identities October 2021 The naming pattern suggested in (client identity draft) includes an underscore label (_device) which also prevents the issuance of Web PKI-validating certificates in the event a DNS server hosting a client identity zone, which is capable of presenting A and AAAA records, is compromised. 5.2. Availability 5.2.1. DNS Scalability In the use case for IoT an implementation must be scalable to a large amount of devices. In many cases, identities may also be very short lived as revocation is performed by simply removing a DNS record. A zone will have to manage a large amount of changes as devices are constantly added and de-activated. In these cases it is important to consider the architecture of the DNS zone and when possible use a tree-like structure with many subdomain parts, much like reverse DNS records or how telephone numbers are represented in the ENUM standard (RFC 6116). If an authoritative resolver were configured to respond quite slowly (think slow loris), is it possible to cause a DoS on the TLS server via complete exhaustion of TCP connections? The availability of a client identity zone is essential to permitting clients to authenticate. If the DNS infrastructure hosting client identities becomes unavailable, then the clients represented by that zone cannot be authenticated. *OEJ: We may want to have a discussion with the IETF DNS directorate. The scalability section above is from a discussion with one of the members...* 5.2.2. Change of ownership What happens if an organization owning the client identity goes out of business? What's the best way to transfer an identifier to another zone? 6. IANA Considerations This document has no IANA actions. Wilson, et al. Expires 25 April 2022 [Page 9] Internet-Draft DNS-Bound Identities October 2021 Appendix A. Acknowledgments TODO acknowledge. Authors' Addresses Ash Wilson Valimail Email: ash.d.wilson@gmail.com Shumon Huque Salesforce Email: shuque@gmail.com Olle Johansson Edvina.net Email: oej@edvina.net Wilson, et al. Expires 25 April 2022 [Page 10]