draft-ietf-dance-architecture-03.txt   draft-ietf-dance-architecture-04.txt 
DANCE A. Wilson DANCE A. Wilson
Internet-Draft Valimail Internet-Draft Valimail
Intended status: Informational S. Huque Intended status: Informational S. Huque
Expires: 2 August 2024 Salesforce Expires: 26 September 2024 Salesforce
O. Johansson O. Johansson
Edvina.net Edvina.net
M. Richardson M. Richardson
Sandelman Software Works Inc Sandelman Software Works Inc
30 January 2024 25 March 2024
An Architecture for DNS-Bound Client and Sender Identities An Architecture for DNS-Bound Client and Sender Identities
draft-ietf-dance-architecture-03 draft-ietf-dance-architecture-04
Abstract Abstract
This architecture document defines terminology, interaction, and This architecture document defines terminology, interaction, and
authentication patterns, related to the use of DANE DNS records for authentication patterns, related to the use of DANE DNS records for
TLS client and messaging peer identity, within the context of TLS client and messaging peer identity, within the context of
existing object security and TLS-based protocols. existing object security and TLS-based protocols.
Discussion Venues Discussion Venues
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 2 August 2024. This Internet-Draft will expire on 26 September 2024.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 27 skipping to change at page 2, line 27
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Communication Patterns . . . . . . . . . . . . . . . . . . . 6 3. Communication Patterns . . . . . . . . . . . . . . . . . . . 6
3.1. Client/Server . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Client/Server . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Peer2peer . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Peer2peer . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Decoupled . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Decoupled . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Client authentication . . . . . . . . . . . . . . . . . . . . 7 4. Client authentication . . . . . . . . . . . . . . . . . . . . 7
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. Example 1: TLS authentication for HTTPS API 4.1.1. Example 1: TLS authentication for HTTPS API
interaction, DANE preauthorization . . . . . . . . . 7 interaction, DANE pattern assurance . . . . . . . . . 8
4.1.2. IoT: Device to cloud . . . . . . . . . . . . . . . . 9 4.1.2. IoT: Device to cloud . . . . . . . . . . . . . . . . 10
4.1.3. LoRaWAN . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.3. LoRaWAN . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.4. Edge Computing . . . . . . . . . . . . . . . . . . . 9 4.1.4. Edge Computing . . . . . . . . . . . . . . . . . . . 11
4.1.5. SIP and WebRTC inter-domain privacy . . . . . . . . . 10 4.1.5. Domain Users . . . . . . . . . . . . . . . . . . . . 11
4.1.6. DNS over TLS client authentication . . . . . . . . . 10 4.1.6. SIP and WebRTC inter-domain privacy . . . . . . . . . 12
4.1.7. SMTP, STARTTLS . . . . . . . . . . . . . . . . . . . 10 4.1.7. DNS over TLS client authentication . . . . . . . . . 12
4.1.8. SSH client . . . . . . . . . . . . . . . . . . . . . 10 4.1.8. SMTP, STARTTLS . . . . . . . . . . . . . . . . . . . 12
4.1.9. Network Access . . . . . . . . . . . . . . . . . . . 11 4.1.9. SSH client . . . . . . . . . . . . . . . . . . . . . 12
4.2. Object Security . . . . . . . . . . . . . . . . . . . . . 13 4.1.10. Network Access . . . . . . . . . . . . . . . . . . . 13
4.2.1. Structured data messages: JOSE/COSE . . . . . . . . . 13 4.2. Object Security . . . . . . . . . . . . . . . . . . . . . 15
4.3. Operational anomaly reporting . . . . . . . . . . . . . . 13 4.2.1. Structured data messages: JOSE/COSE . . . . . . . . . 15
4.3.1. MUD reporting for improper provisioning . . . . . . . 13 4.3. Operational anomaly reporting . . . . . . . . . . . . . . 15
4.3.2. XARF for abuse reporting . . . . . . . . . . . . . . 13 4.3.1. MUD reporting for improper provisioning . . . . . . . 15
4.4. Adjacent Ecosystem Components . . . . . . . . . . . . . . 13 4.3.2. XARF for abuse reporting . . . . . . . . . . . . . . 15
4.4.1. Certification Authority . . . . . . . . . . . . . . . 13 4.4. Adjacent Ecosystem Components . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 4.4.1. Certification Authority . . . . . . . . . . . . . . . 15
5.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 16
5.3. Availability . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 16
5.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.3. Availability . . . . . . . . . . . . . . . . . . . . . . 16
5.4.1. DNS Scalability . . . . . . . . . . . . . . . . . . . 15 5.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.4.2. Change of ownership for IoT devices . . . . . . . . . 16 5.4.1. DNS Scalability . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5.4.2. Change of ownership for IoT devices . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.2. Informative References . . . . . . . . . . . . . . . . . 17 7.1. Normative References . . . . . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
A digital identity, in an abstract sense, possesses at least two A digital identity, in an abstract sense, possesses at least two
features: an identifier (or name), and a means of proving ownership features: an identifier (or name), and a means of proving ownership
of the identifier. One of the most resilient mechanisms for tying an of the identifier. One of the most resilient mechanisms for tying an
identifier to a method for proving ownership of the identifier is the identifier to a method for proving ownership of the identifier is the
digital certificate, issued by a well-run Certification Authority digital certificate, issued by a well-run Certification Authority
(CA). The CA acts as a mutually trusted third party, a root of (CA). The CA acts as a mutually trusted third party, a root of
trust. trust.
skipping to change at page 3, line 42 skipping to change at page 3, line 43
trust for validating entity certificates issued by organizational trust for validating entity certificates issued by organizational
PKI. PKI.
Attempting to use organizational PKI outside the organization can be Attempting to use organizational PKI outside the organization can be
challenging. In order to authenticate a certificate, the challenging. In order to authenticate a certificate, the
certificate’s CA must be trusted. CAs have no way of controlling certificate’s CA must be trusted. CAs have no way of controlling
identifiers in certificates issued by other CAs. Consequently, identifiers in certificates issued by other CAs. Consequently,
trusting multiple CAs at the same time can enable entity identifier trusting multiple CAs at the same time can enable entity identifier
collisions. Asking an entity to trust your CA implies trust in collisions. Asking an entity to trust your CA implies trust in
anything that your CA signs. This is why many organizations operate anything that your CA signs. This is why many organizations operate
a private CA, and require devices connecting to the organization’s a private CA, and require users and devices connecting to the
networks or applications to possess certificates issued by the organization’s networks or applications to possess certificates
organization’s CA. issued by the organization’s CA.
These limitations make the implementation and ongoing maintenance of These limitations make the implementation and ongoing maintenance of
a PKI costly, and have a chilling effect on the broader adoption of a PKI costly, and have a chilling effect on the broader adoption of
certificate-based IoT device identity. If certificate-based device certificate-based IoT device identity and user identity. If
identity were easier to manage, more broadly trusted, and less certificate-based device and user identity were easier to manage,
operationally expensive, more organizations and applications would be more broadly trusted, and less operationally expensive, more
able to use it. organizations and applications would be able to use it.
The lack of trust between PKI domains has lead to a lack of simple 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 and globally scalable solutions for secure end-to-end inter-domain
communication between entities, such as SIP phones, email and chat communication between entities, such as SIP phones, email and chat
accounts and IoT devices belonging to different organizations. accounts and IoT devices belonging to different organizations.
DANCE seeks to make PKI-based IoT device identity universally DANCE seeks to make PKI-based user and IoT device identity
discoverable, more broadly recognized, and less expensive to maintain universally discoverable, more broadly recognized, and less expensive
by using DNS as the constraining namespace and lookup mechanism. to maintain by using DNS as the constraining namespace and lookup
DANCE builds on patterns established by the original DANE RFCs to mechanism. DANCE builds on patterns established by the original DANE
enable client and sending entity certificate, public key, and trust RFCs to enable client and sending entity certificate, public key, and
anchor discovery. DANCE allows entities to possess a first-class trust anchor discovery. DANCE allows entities to possess a first-
identity, which, thanks to DNS, may be trusted by any application class identity, which, thanks to DNSSEC, may be trusted by any
also trusting the DNS. A first-class identity is an application- application also trusting the DNS. A first-class identity is an
independent identity. application-independent identity.
2. Conventions and Definitions 2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
*This section will be interesting to define. We have great examples *This section will be interesting to define. We have great examples
skipping to change at page 4, line 43 skipping to change at page 4, line 50
*How to Dance with ENTITY:* This architecture document delegates many *How to Dance with ENTITY:* This architecture document delegates many
details of how DANCE can be used with some specific protocol to a details of how DANCE can be used with some specific protocol to a
document with the names "How to Dance with _entity_". document with the names "How to Dance with _entity_".
*Identity provisioning:* This refers to the set of tasks required to *Identity provisioning:* This refers to the set of tasks required to
securely provision an asymmetric key pair for the device, sign the securely provision an asymmetric key pair for the device, sign the
certificate (if the public credential is not simply a raw public certificate (if the public credential is not simply a raw public
key), and publish the public key or certificate in DNS. Under some key), and publish the public key or certificate in DNS. Under some
circumstances, these steps are not all performed by the same party or circumstances, these steps are not all performed by the same party or
organization. A manufacturer may instantiate the key pair, and a organization. A device manufacturer may instantiate the key pair,
systems integrator may be responsible for issuing (and publishing) and a systems integrator may be responsible for issuing (and
the device certificate in DNS. In some circumstances, a manufacturer publishing) the device certificate in DNS. In some circumstances, a
may also publish device identity records in DNS. In this case, the manufacturer may also publish device identity records in DNS. In
system integrator needs to perform network and application access this case, the system integrator needs to perform network and
configuration, since the identity already exists in DNS. application access configuration, since the identity already exists
in DNS. A user may instantiate a key pair, based upon which an
organization's CA may produce a certificate after internally assuring
the user identity, and the systems integrator may publish the CA root
certificate in DNS.
*DANCEr:* A DANCEr is the term which is used to describe a protocol *DANCEr:* A DANCEr is the term which is used to describe a protocol
that has been taught to use DANE, usually through a _How to Dance that has been taught to use DANE, usually through a _How to Dance
with_ document. with_ document.
*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 *Security Domain:* DNS-bound client identity allows the device to
establish secure communications with any server with a DNS-bound establish secure communications with any server with a DNS-bound
identity, as long as a network path exists, the entity is configured identity, as long as a network path exists, the entity is configured
to trust its communicating peer by name, and agreement on protocols to trust its communicating peer by its DNS owner name, and agreement
can be achieved. The act of joining a security domain, in the past, on protocols can be achieved. The act of joining a security domain,
may have involved certificate provisioning. Now, it can be as simple in the past, may have involved certificate provisioning. Now, it can
as using a manufacturer-provisioned identity to join the device to be as simple as using a manufacturer-provisioned identity to join the
the network and application. [Is the security domain defined by how device to the network and application. [Is the security domain
broadly the identity is recognized, or by the breadth of the defined by how broadly the identity is recognized, or by the breadth
application or network access policy?] of the application or network access policy?]
*Client:* This architecture document adopts the definition of *Client:* This architecture document adopts the definition of
"Client" from RFC 8446: "The endpoint initiating the TLS connection" "Client" from RFC 8446: "The endpoint initiating the TLS connection"
*User:* A client whose name consists of a user identity and a DNS
owner name prefixed with a _user label.
*Server:* This architecture document adopts the definition of *Server:* This architecture document adopts the definition of
"Server" from RFC 8446: "The endpoint that did not initiate the TLS "Server" from RFC 8446: "The endpoint that did not initiate the TLS
connection" connection"
*Sending agent:* Software which encodes and transmits messages. A *Sending agent:* Software which encodes and transmits messages. A
sending agent may perform tasks related to generating cryptographic sending agent may perform tasks related to generating cryptographic
signatures and/or encrypting messages before transmission. signatures and/or encrypting messages before transmission.
*Receiving agent:* Software which interprets and processes messages. *Receiving agent:* Software which interprets and processes messages.
A receiving agent may perform tasks related to the decryption of A receiving agent may perform tasks related to the decryption of
skipping to change at page 6, line 30 skipping to change at page 6, line 37
entity which initiates a connection to the server, called a client. entity which initiates a connection to the server, called a client.
A secure implementation of this pattern includes a TLS-protected A secure implementation of this pattern includes a TLS-protected
session directly between the client and the server. A secure session directly between the client and the server. A secure
implementation may also include public key-based mutual implementation may also include public key-based mutual
authentication. authentication.
Extending DANE to include client identity allows the server to Extending DANE to include client identity allows the server to
authenticate clients independent of the private PKI used to issue the authenticate clients independent of the private PKI used to issue the
client certificate. This reduces the complexity of managing the CA client certificate. This reduces the complexity of managing the CA
certificate collection, and mitigates the possibility of client certificate collection, and mitigates the possibility of client
identifier collision. identifier collision. If the client is a user, the certificate holds
an additional user identity supplied under the prerogative of a DNS
owner name, which reduces the complexity of authenticating both
internal and external users, through protocol mechanisms like SASL
EXTERNAL [RFC4422].
3.2. Peer2peer 3.2. Peer2peer
The extension also allows an application to find an application The extension also allows an application to find an application
identity and set up a secure communication channel directly. This identity and set up a secure communication channel directly. This
pattern can be used in mesh networking, IoT and in many communication pattern can be used in mesh networking, IoT and in many communication
protocols for multimedia sessions, chat and messaging. protocols for multimedia sessions, chat and messaging, where each
endpoint may represent a device or a user.
3.3. Decoupled 3.3. Decoupled
Decoupled architecture, frequently incorporating store-and-forward Decoupled architecture, frequently incorporating store-and-forward
systems, provides no direct connection between the producer and systems, provides no direct connection between the producer and
consumer of information. The producer (or sending agent) and consumer of information. The producer (or sending agent) and
consumer (or receiving agent) are typically separated by at least one consumer (or receiving agent) are typically separated by at least one
layer of messaging-oriented middleware. The Messaging-oriented host running messaging-oriented middleware. The Messaging-oriented
middleware components may act as a server for the purpose of middleware components may act as a server for the purpose of
establishing TLS sessions for the producer and consumer. This allows establishing TLS sessions for the producer and consumer. This allows
the assertion of identity between the middleware and sending agent, the assertion of identity between the middleware and sending agent,
and the middleware and receiving agent. The trust relationship and the middleware and receiving agent. The trust relationship
between the sending agent and receiving agent is based on the between the sending agent and receiving agent is based on the
presumed trustworthiness of the middleware, unless an identity can be presumed trustworthiness of the middleware, unless an identity can be
attached to the message itself, independent of transport and attached to the message itself, independent of transport and
middleware components. middleware components.
Within many existing store-and-forward protocols, certificates may be Within many existing store-and-forward protocols, certificates may be
skipping to change at page 7, line 20 skipping to change at page 7, line 35
an unnecessary overhead on constrained network links. Decoupled an unnecessary overhead on constrained network links. Decoupled
applications benefit from an out-of-band public key discovery applications benefit from an out-of-band public key discovery
mechanism, which may enable the retrieval of certificates only when mechanism, which may enable the retrieval of certificates only when
needed, and sometimes using a less expensive network connection. needed, and sometimes using a less expensive network connection.
4. Client authentication 4. Client authentication
4.1. Overview 4.1. Overview
The client sets up a TLS connection to a server, attaches a client The client sets up a TLS connection to a server, attaches a client
certificate with a subjectAltName dNSName indicating the name of the certificate with one subjectAltName element dNSName indicating the
client. In the TLS connection the DANE-client-id extension is used DNS onwer name of the client. If the client is a user, their user
to tell the server to use the certificate dNSName to find a DANE identity is added in one subjectAltName element otherName holding
record including the public key of the certificate to be able to their uid attribute [RFC4519].
validate. If the server can validate the DNSSEC response, the server
validates the certificate and completes the TLS connection setup.
Using DNS to convey certificate information for authenticating TLS In the TLS connection the DANE-client-id extension is used to tell
the server to use the certificate dNSName to find a DANE record
including the public key of the certificate to be able to validate.
If the server can validate the DNSSEC response, the server validates
the certificate and completes the TLS connection setup. (PKIX offers
rfc822Name with userid@domain.name as alternative for a user's uid &
dNSName, but it is limited to ASCII and suggests email only).
Using DANE to convey certificate information for authenticating TLS
clients gives a not-yet-authenticated client the ability to trigger a clients gives a not-yet-authenticated client the ability to trigger a
DNS lookup on the server side of the TLS connection. An opportunity DNS lookup on the server side of the TLS connection. An opportunity
for DDOS may exist when malicious clients can trigger arbitrary DNS for DDOS may exist when malicious clients can trigger arbitrary DNS
lookups. For instance, an authoritative DNS server which has been lookups. For instance, an authoritative DNS server which has been
configured to respond slowly, may cause a high concurrency of in- configured to respond slowly, may cause a high concurrency of in-
flight TLS authentication processes as well as open connections to flight TLS authentication processes as well as open connections to
upstream resolvers. This sort of attack (of type slowloris) could upstream resolvers. This sort of attack (of type slowloris) could
have a performance or availability impact on the TLS server. have a performance or availability impact on the TLS server.
4.1.1. Example 1: TLS authentication for HTTPS API interaction, DANE 4.1.1. Example 1: TLS authentication for HTTPS API interaction, DANE
preauthorization pattern assurance
* The client initiates a TLS connection to the server. * The client initiates a TLS connection to the server.
* The TLS server compares the dane_clientid (conveyed via the DANE * The TLS server compares the dane_clientid (conveyed via the DANE
Client Identity extension) to a list of allowed client domains. Client Identity extension) to a list of allowed client domains.
* If the dane_clientid is allowed, the TLS server then performs a * If the dane_clientid is allowed, the TLS server then performs a
DNS lookup for the client's TLSA record. If the dane_clientid is DNS lookup for the client's TLSA record. If the dane_clientid is
not allowed, authentication fails. not allowed, authentication fails.
skipping to change at page 9, line 7 skipping to change at page 9, line 26
balancer remains simple. balancer remains simple.
* The web application ultimately decides whether to make the DNS * The web application ultimately decides whether to make the DNS
query to support DANE authentication. This allows the web query to support DANE authentication. This allows the web
application to reject clients with identifiers which are not application to reject clients with identifiers which are not
allowed, before making a DNS query for TLSA retrieval and allowed, before making a DNS query for TLSA retrieval and
comparison. No need to manage an allow-list in the load balancer. comparison. No need to manage an allow-list in the load balancer.
* This can be implemented with no changes to the TLS handshake. * This can be implemented with no changes to the TLS handshake.
4.1.1.2. Example 3: TLS user authentication for an LDAP query
* The LDAP client initiates a TLS connection the the server,
conveying the user's domain via the DANE Client Identity
extension.
* If the dane_clientid is allowed and begins with a _user label, the
TLS server then performs a DNS lookup for TLSA records holding the
user's CA, and includes them when requesting a client certificate.
* If the client's certificate is signed by a CA found in the TLSA
records and the certificate's dNSName prefixed with a _user label
matches the dane_clientid then the client identity is
authenticated to consist of the lowercase uid in the certificate,
an "@" symbol and the lowercase UTF-8 representation of the
certificate's dNSName (which lacks the "_user." prefix).
* The LDAP server responds to SASL EXTERNAL authentication by
obtaining the authenticated user identity in userid@domain.name
form and, if so requested, attempts to change to an authorization
identity.
This pattern has the following advantages:
* SASL authentication under TLS encryption is common to many
protocols, including new ones.
* This LDAP example demonstrates the potential of authentication
with realm crossover support as a precursor to fine access control
to possibly sensitive data.
* User identities cannot be iterated in DNS; TLS 1.3 conceals the
client certificate; TLS in general conceals the user's choice of
authorization identity during SASL EXTERNAL.
* This can be implemented with no changes to the TLS handshake.
4.1.2. IoT: Device to cloud 4.1.2. IoT: Device to cloud
Direct device-to-cloud communication is common in simple IoT Direct device-to-cloud communication is common in simple IoT
applications. Authentication in these applications is usually applications. Authentication in these applications is usually
accomplished using shared credentials like API keys, or using client accomplished using shared credentials like API keys, or using client
certificates. Client certificate authentication frequently requires certificates. Client certificate authentication frequently requires
the consumer to maintain a CA. The CA trust anchor certificate is the consumer to maintain a CA. Before client DANE, the CA trust
installed into the cloud application, and used in the TLS anchor certificate would be installed into the cloud application, and
authentication process. used in the TLS authentication process.
Using DANE for device identity can allow parties other than the Using client DANE for device identity can allow parties other than
implementer to operate the CA. A hardware manufacturer can provide a the implementer to operate the CA. A hardware manufacturer can
pre-established identity, with the certificate or public key already provide a pre-established identity, with the certificate or public
published in DNS. This makes PKI-based identity more approachable key already published in DNS. This makes PKI-based identity more
for small organizations which currently lack the resources to operate approachable for small organizations which currently lack the
an organizational CA. resources to operate an organizational CA.
4.1.3. LoRaWAN 4.1.3. LoRaWAN
For the end-device onboarding in LoRaWAN, the "network server" and For the end-device onboarding in LoRaWAN, the "network server" and
the "join server" [RFC8376] needs to establish mutual TLS the "join server" [RFC8376] needs to establish mutual TLS
authentication in order to exchange configuration parameters. authentication in order to exchange configuration parameters.
Certificate Authority based mutual TLS authentication doesn't work in Certificate Authority based mutual TLS authentication doesn't work in
LoRaWAN due to the non availability of the CA trust store in the LoRaWAN due to the non availability of the CA trust store in the
LoRaWAN network stack. Self-signed certificate based mutual-TLS LoRaWAN network stack. Self-signed certificate based mutual-TLS
authentication method is the alternative solution. authentication method is the alternative solution.
skipping to change at page 9, line 52 skipping to change at page 11, line 18
computing-01 (Edge Computing) may require devices to mutually computing-01 (Edge Computing) may require devices to mutually
authenticate in the field. A practical example of this pattern is authenticate in the field. A practical example of this pattern is
the edge computing in construction use case the edge computing in construction use case
[https://datatracker.ietf.org/doc/html/draft-hong-t2trg-iot-edge- [https://datatracker.ietf.org/doc/html/draft-hong-t2trg-iot-edge-
computing-01#section-6.2.1]. Using traditional certificate-based computing-01#section-6.2.1]. Using traditional certificate-based
identity, the sensor and the gateway may have certificates issued by identity, the sensor and the gateway may have certificates issued by
the same organizational PKI. By using DANE for client and sender the same organizational PKI. By using DANE for client and sender
identity, the sensor and the gateway may have identities represented identity, the sensor and the gateway may have identities represented
by the equipment supplier, and still be able to mutually by the equipment supplier, and still be able to mutually
authenticate. Important sensor measurements forwarded by the gateway authenticate. Important sensor measurements forwarded by the gateway
to the cloud may bear the DNS name and signature of the originating to the cloud may bear the DNS owner name and signature of the
sensor, and the cloud application may authenticate the measurement originating sensor, and the cloud application may authenticate the
independent of the gateway which forwarded the information to the measurement independent of the gateway which forwarded the
application. information to the application.
4.1.5. SIP and WebRTC inter-domain privacy 4.1.5. Domain Users
The allocation of user identities is the prerogative of a domain, in
line with the nesting suggested in URI notation. Domains may even
choose to assign domain user identities to services, possibly with
easily recognised identities like +mail+archive@domain.name. Domains
who publish TLSA records for a CA under a _user name underneath their
domain allow the validation of user identities as mentioned in a
certificate as TLS client or peer identities. This mechanism is not
restricted to domain-internal users, but can be used to validate
users under any domain.
Since ENUM maps telephone numbers to DNS owner names, it is possible
to employ these same mechanisms for telephone number users. Any
DANCEr may however define alternate derivation procedures to obtain
the DNS owner name for a phone number from specialised PKIX or LDAP
attributes such as telephoneNumber, telexNumber, homePhone, mobile
and pager.
There is no reason why other uses, such as store-and-forward with S/
MIME, could not benefit from this DNS-based PKI, as long as they
remain mindful that anything in the certificate is the prerogative of
the domain publishing the TLSA record, and the only reliable identity
statements are for resources underneath the domain -- notably, the
assignment of uid names.
4.1.6. SIP and WebRTC inter-domain privacy
End to end security in SIP is currently based on a classical S/MIME 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 model which has not received much implementation. There are also SIP
standards that build upon a trust chained anchored on the HTTP trust standards that build upon a trust chained anchored on the HTTP trust
chain (SIP identity, STIR). WebRTC has a trust model between the web chain (SIP identity, STIR). WebRTC has a trust model between the web
browser and the servers using TLS, but no inter-domain trust browser and the servers using TLS, but no inter-domain trust
infrastructure. WebRTC lacks a definition of namespace to map to infrastructure. WebRTC lacks a definition of namespace to map to
DNS, where SIP is based on an email-style addressing scheme. For DNS, where SIP is based on an email-style addressing scheme. For
WebRTC the application developer needs to define the name space and WebRTC the application developer needs to define the name space and
mapping to DNS. mapping to DNS.
By using DNS as a shared root of trust SIP and WebRTC end points can 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, anchor the keys used for DTLS/SRTP media channel setup. In addition,
SIP devices can establish security in the SIP messaging by using DNS SIP devices can establish security in the SIP messaging by using DNS
to find the callee’s and the callers digital identity. to find the callee’s and the callers digital identity.
[I-D.johansson-sipcore-dane-sip](SIPDANE) [I-D.johansson-sipcore-dane-sip](SIPDANE)
4.1.6. DNS over TLS client authentication 4.1.7. DNS over TLS client authentication
Issue #7 Issue #7
4.1.7. SMTP, STARTTLS 4.1.8. SMTP, STARTTLS
Issue #8 Issue #8
4.1.8. SSH client 4.1.9. SSH client
SSH servers have for some time been able to put their host keys into SSH servers have for some time been able to put their host keys into
DNS using [RFC4255]. DNS using [RFC4255].
In many SSH server implementations the list of users that is In many SSH server implementations the list of users that is
authorized to login to an account is given by listing their public authorized to login to an account is given by listing their public
keys in a per-user file ("authorized_keys"). The file provides both keys in a per-user file ("authorized_keys"). The file provides both
authorization (who may login), and authentication (how they prove authorization (who may login), and authentication (how they prove
their identity). While this is an implementation detail, doing both their identity). While this is an implementation detail, doing both
in one place has been one of Secure Shell's major reason for success. in one place has been one of Secure Shell's major reason for success.
However, there are downsides to this: a user can not easily replace However, there are downsides to this: a user can not easily replace
their key without visiting every host they are authorized to access their key without visiting every host they are authorized to access
and update the key on that host. Separation of authorization and and update the key on that host. Separation of authorization and
authentication in this case would involve putting the key material in authentication in this case would involve putting the key material in
a third place, such as in a DANE record in DNS, and then listing only a third place, such as in a DANE record in DNS, and then listing only
the DNS name in the authorization file: the DNS owner name in the authorization file:
* A user who wants to update their key need only update DNS in that * A user who wants to update their key need only update DNS in that
case. case.
* A user who has lost access to their key, but can still update DNS * A user who has lost access to their key, but can still update DNS
(or can have a colleague update it) would more easily be able to (or can have a colleague update it) would more easily be able to
recover. recover.
* An administrator who controls the domain would be able to remove a * An administrator who controls the domain would be able to remove a
departing user's key from DNS, preventing the user from departing user's key from DNS, preventing the user from
authenticating in the future. authenticating in the future.
The DNS record used could be TLSA, but it is possible with some The DNS record used could be TLSA, but it is possible with some
protocol work that it could instead be SSHFP. protocol work that it could instead be SSHFP. Since SSH can trust CA
certificates from X.509, those may be published for user
authentication.
4.1.9. Network Access 4.1.10. Network Access
Network access refers to an authentication process by which a node is Network access refers to an authentication process by which a node is
admitted securely onto network infrastructure. This is most common admitted securely onto network infrastructure. This is most common
for wireless networks (wifi, 802.15.4), but has also routine been for wireless networks (wifi, 802.15.4), but has also routine been
done for wired infrastructure using 802.1X mechanisms with EAPOL. done for wired infrastructure using 802.1X mechanisms with EAPOL.
While there are EAP protocols that do not involve certificates, such While there are EAP protocols that do not involve certificates, such
as EAPSIM ([RFC4186], the use of symmetric key mechanisms as the as EAPSIM ([RFC4186], the use of symmetric key mechanisms as the
"network key" is common in many homes. The use of certificate based "network key" is common in many homes. The use of certificate based
mechanisms are expected to increase, due to challenges, such as mechanisms are expected to increase, due to challenges, such as
Randomized and Changing MAC addresses (RCM), as described in Randomized and Changing MAC addresses (RCM), as described in
[I-D.ietf-madinas-use-cases]. [I-D.ietf-madinas-use-cases].
4.1.9.1. EAP-TLS with RADIUS 4.1.10.1. EAP-TLS with RADIUS
Enterprise EAP methods use a version of TLS to form a secure Enterprise EAP methods use a version of TLS to form a secure
transport. Client and server-side certificates are used as transport. Client and server-side certificates are used as
credentials. EAP-TLS does not run over TCP, but rather over a credentials. EAP-TLS does not run over TCP, but rather over a
reliable transport provided by EAP. To keep it simple the EAP reliable transport provided by EAP. To keep it simple the EAP
"window" is always one, and there are various amounts of overhead "window" is always one, and there are various amounts of overhead
that needs to be accounted for, and the EAP segment size is often that needs to be accounted for, and the EAP segment size is often
noticeably smaller than the normal ethernet 1500 bytes. [RFC3748] noticeably smaller than the normal ethernet 1500 bytes. [RFC3748]
does guarantee a minimum payload of 1020 bytes. does guarantee a minimum payload of 1020 bytes.
skipping to change at page 12, line 21 skipping to change at page 14, line 21
that issued the client side certificate, and so already has access to that issued the client side certificate, and so already has access to
the entire client certificate. Transferring the client certificate the entire client certificate. Transferring the client certificate
is redundant. That is, the authenticator already has access to the is redundant. That is, the authenticator already has access to the
entire certificate, but the client does not know this to tbe case, so entire certificate, but the client does not know this to tbe case, so
it sends the entire certificate anyway. it sends the entire certificate anyway.
The use of DANE Client IDs in TLS as described in The use of DANE Client IDs in TLS as described in
[I-D.ietf-dance-tls-clientid] reduces the redundant bytes of [I-D.ietf-dance-tls-clientid] reduces the redundant bytes of
certificate sent. certificate sent.
4.1.9.1.1. Terminology 4.1.10.1.1. Terminology
*Supplicant:* The entity which acts as the TLS client in the EAP-TLS *Supplicant:* The entity which acts as the TLS client in the EAP-TLS
authentication protocol. This term is defined in IEEE 802.1x. The authentication protocol. This term is defined in IEEE 802.1x. The
suppliant acts as a client in the EAPOL (EAP over LAN) protocol, suppliant acts as a client in the EAPOL (EAP over LAN) protocol,
which is terminated at the authenticator (defined below). which is terminated at the authenticator (defined below).
*Authentication server:* The entity which acts as the TLS server in *Authentication server:* The entity which acts as the TLS server in
the EAP-TLS protocol. RADIUS (RFC 2865) is a frequently-used the EAP-TLS protocol. RADIUS (RFC 2865) is a frequently-used
authentication server protocol. authentication server protocol.
skipping to change at page 13, line 5 skipping to change at page 15, line 5
ethernet. RADIUS is a protocol and server technology frequently used ethernet. RADIUS is a protocol and server technology frequently used
for supporting the server side of EAP-TLS authentication. Guidance for supporting the server side of EAP-TLS authentication. Guidance
for implementing RADIUS strongly encourages the use of a single for implementing RADIUS strongly encourages the use of a single
common CA for all supplicants, to mitigate the possibility of common CA for all supplicants, to mitigate the possibility of
identifier collisions across PKIs. The use of DANE for client identifier collisions across PKIs. The use of DANE for client
identity can allow the safe use of any number of CAs. DNS acts as a identity can allow the safe use of any number of CAs. DNS acts as a
constraining namespace, which prevents two unrelated CAs from issuing constraining namespace, which prevents two unrelated CAs from issuing
valid certificates bearing the same identifier. Certificates valid certificates bearing the same identifier. Certificates
represented in DNS are valid, and all others are un-trusted. represented in DNS are valid, and all others are un-trusted.
4.1.9.2. RADSEC 4.1.10.2. RADSEC
The RADIUS protocol has a few recognized security problems. The RADIUS protocol has a few recognized security problems.
https://datatracker.ietf.org/doc/html/rfc6614 (RADSEC) addresses the https://datatracker.ietf.org/doc/html/rfc6614 (RADSEC) addresses the
challenges related to the weakness of MD5-based authentication and challenges related to the weakness of MD5-based authentication and
confidentiality over untrusted networks by establishing a TLS session confidentiality over untrusted networks by establishing a TLS session
between the RADIUS protocol client and the RADIUS protocol server. between the RADIUS protocol client and the RADIUS protocol server.
RADIUS datagrams are then transmitted between the authenticator and RADIUS datagrams are then transmitted between the authenticator and
authentication server within the TLS session. Updating the RADSEC authentication server within the TLS session. Updating the RADSEC
standard to include the use of DANE for client and server identity standard to include the use of DANE for client and server identity
would allow a RADIUS server and client to mutually authenticate, would allow a RADIUS server and client to mutually authenticate,
skipping to change at page 14, line 34 skipping to change at page 16, line 34
This can prevent a compromised identity zone DNS server from This can prevent a compromised identity zone DNS server from
presenting records essential for impersonating web sites under the presenting records essential for impersonating web sites under the
organization’s domain name. organization’s domain name.
The naming pattern suggested in The naming pattern suggested in
https://datatracker.ietf.org/doc/html/draft-huque-dane-client-cert https://datatracker.ietf.org/doc/html/draft-huque-dane-client-cert
(https://datatracker.ietf.org/doc/html/draft-huque-dane-client-cert) (https://datatracker.ietf.org/doc/html/draft-huque-dane-client-cert)
includes an underscore label (_device) which also prevents the includes an underscore label (_device) which also prevents the
issuance of Web PKI-validating certificates in the event a DNS server issuance of Web PKI-validating certificates in the event a DNS server
hosting a client identity zone, which is capable of presenting A and hosting a client identity zone, which is capable of presenting A and
AAAA records, is compromised. AAAA records, is compromised. An alternative underscore label _user
separates the TLSA records with the domain CA from the TLSA records
for devices.
5.3. Availability 5.3. Availability
One of the advantages of DNS is that it has more than fourty years of One of the advantages of DNS is that it has more than fourty years of
demonstrated scaling. It is a distributed database with a caching demonstrated scaling. It is a distributed database with a caching
mechanism, and properly configured, it has proven resilient to many mechanism, and properly configured, it has proven resilient to many
kinds of outages and attacks. kinds of outages and attacks.
A key part of this availability is the proper use of Time To Live A key part of this availability is the proper use of Time To Live
(TTL) values for resource records. A cache is allowed to hang on to (TTL) values for resource records. A cache is allowed to hang on to
skipping to change at page 15, line 15 skipping to change at page 17, line 20
On the other hand, lower TTLs cause the queries to occur more often, On the other hand, lower TTLs cause the queries to occur more often,
which may reveal more information to an observer about which devices which may reveal more information to an observer about which devices
are active. Encrypted transports like DoT/DoH/DoQ make these queries are active. Encrypted transports like DoT/DoH/DoQ make these queries
far less visible. In addition to the on-path observer being able to far less visible. In addition to the on-path observer being able to
see more, the resolver logs also may be a source of information. It see more, the resolver logs also may be a source of information. It
also allows for more opportunities for an attacker to affect the also allows for more opportunities for an attacker to affect the
response time of the queries. response time of the queries.
5.4. Privacy 5.4. Privacy
If the name of the identity proven by a certificate is directly or If the DNS owner name of the identity proven by a certificate is
indirectly relatable to a person, privacy needs to be considered when directly or indirectly relatable to a person, privacy needs to be
forming the name of the DNS resource record for the certificate. considered when forming the name of the DNS resource record for the
When creating the name of the RR, effects of DNS zone walking and certificate. This privacy is implied for domain users inasfar as the
possible harvesting of identities in the DNS zone will have to be domain CA does not mention users. When creating the DNS owner name,
considered. The name of the RR may note have to have a direct effects of DNS zone walking and possible harvesting of identities in
relation to the name of the subject of the certificate. the DNS zone will have to be considered. The DNS owner name may not
have to have a direct relation to the name of the subject or the
subjectAltName of the certificate. If there is such a relation, a
DANCEr may specify support for CA certificates, stored under a
wildcard in DNS.
Further work has do be done in this area. Further work has do be done in this area.
AW: Consider if an approach like the email local-part hashing used in AW: Consider if an approach like the email local-part hashing used in
SMIMEA https://datatracker.ietf.org/doc/html/rfc8162 SMIMEA https://datatracker.ietf.org/doc/html/rfc8162
(https://datatracker.ietf.org/doc/html/rfc8162) might work for this. (https://datatracker.ietf.org/doc/html/rfc8162) might work for this.
If the identifier/local-part is hashed and the certificate If the identifier/local-part is hashed and the certificate
association is a SHA256 or SHA512 hash, the effort required to walk a association is a SHA256 or SHA512 hash, the effort required to walk a
zone would not produce much useful information. zone would not produce much useful information.
skipping to change at page 17, line 33 skipping to change at page 19, line 48
[I-D.ietf-dance-tls-clientid] [I-D.ietf-dance-tls-clientid]
Huque, S. and V. Dukhovni, "TLS Extension for DANE Client Huque, S. and V. Dukhovni, "TLS Extension for DANE Client
Identity", Work in Progress, Internet-Draft, draft-ietf- Identity", Work in Progress, Internet-Draft, draft-ietf-
dance-tls-clientid-03, 8 January 2024, dance-tls-clientid-03, 8 January 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-dance- <https://datatracker.ietf.org/doc/html/draft-ietf-dance-
tls-clientid-03>. tls-clientid-03>.
[I-D.ietf-madinas-use-cases] [I-D.ietf-madinas-use-cases]
Henry, J. and Y. Lee, "Randomized and Changing MAC Address Henry, J. and Y. Lee, "Randomized and Changing MAC Address
Use Cases and Requirements", Work in Progress, Internet- Use Cases", Work in Progress, Internet-Draft, draft-ietf-
Draft, draft-ietf-madinas-use-cases-07, 11 January 2024, madinas-use-cases-09, 29 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-madinas- <https://datatracker.ietf.org/doc/html/draft-ietf-madinas-
use-cases-07>. use-cases-09>.
[I-D.johansson-sipcore-dane-sip] [I-D.johansson-sipcore-dane-sip]
Johansson, O. E., "TLS sessions in SIP using DNS-based Johansson, O. E., "TLS sessions in SIP using DNS-based
Authentication of Named Entities (DANE) TLSA records", Authentication of Named Entities (DANE) TLSA records",
Work in Progress, Internet-Draft, draft-johansson-sipcore- Work in Progress, Internet-Draft, draft-johansson-sipcore-
dane-sip-00, 6 October 2014, dane-sip-00, 6 October 2014,
<https://datatracker.ietf.org/doc/html/draft-johansson- <https://datatracker.ietf.org/doc/html/draft-johansson-
sipcore-dane-sip-00>. sipcore-dane-sip-00>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
skipping to change at page 18, line 16 skipping to change at page 20, line 29
Authentication Protocol Method for Global System for Authentication Protocol Method for Global System for
Mobile Communications (GSM) Subscriber Identity Modules Mobile Communications (GSM) Subscriber Identity Modules
(EAP-SIM)", RFC 4186, DOI 10.17487/RFC4186, January 2006, (EAP-SIM)", RFC 4186, DOI 10.17487/RFC4186, January 2006,
<https://www.rfc-editor.org/rfc/rfc4186>. <https://www.rfc-editor.org/rfc/rfc4186>.
[RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely
Publish Secure Shell (SSH) Key Fingerprints", RFC 4255, Publish Secure Shell (SSH) Key Fingerprints", RFC 4255,
DOI 10.17487/RFC4255, January 2006, DOI 10.17487/RFC4255, January 2006,
<https://www.rfc-editor.org/rfc/rfc4255>. <https://www.rfc-editor.org/rfc/rfc4255>.
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
Authentication and Security Layer (SASL)", RFC 4422,
DOI 10.17487/RFC4422, June 2006,
<https://www.rfc-editor.org/rfc/rfc4422>.
[RFC4501] Josefsson, S., "Domain Name System Uniform Resource [RFC4501] Josefsson, S., "Domain Name System Uniform Resource
Identifiers", RFC 4501, DOI 10.17487/RFC4501, May 2006, Identifiers", RFC 4501, DOI 10.17487/RFC4501, May 2006,
<https://www.rfc-editor.org/rfc/rfc4501>. <https://www.rfc-editor.org/rfc/rfc4501>.
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol
(LDAP): Schema for User Applications", RFC 4519,
DOI 10.17487/RFC4519, June 2006,
<https://www.rfc-editor.org/rfc/rfc4519>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/rfc/rfc7515>. 2015, <https://www.rfc-editor.org/rfc/rfc7515>.
[RFC7593] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam [RFC7593] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam
Architecture for Network Roaming", RFC 7593, Architecture for Network Roaming", RFC 7593,
DOI 10.17487/RFC7593, September 2015, DOI 10.17487/RFC7593, September 2015,
<https://www.rfc-editor.org/rfc/rfc7593>. <https://www.rfc-editor.org/rfc/rfc7593>.
[RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
 End of changes. 39 change blocks. 
120 lines changed or deleted 208 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/