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/ |