From 4e1d280039b06e70a6b9e0cacb347402b135a2df Mon Sep 17 00:00:00 2001 From: "Olle E. Johansson" Date: Wed, 4 Sep 2024 17:21:04 +0200 Subject: [PATCH 1/8] Add example headings on all examples Signed-off-by: Olle E. Johansson --- draft-ietf-dance-architecture.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/draft-ietf-dance-architecture.md b/draft-ietf-dance-architecture.md index 3768cfa..fd43692 100644 --- a/draft-ietf-dance-architecture.md +++ b/draft-ietf-dance-architecture.md @@ -229,7 +229,7 @@ This pattern has the following advantages: - 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. -### IoT: Device to cloud +### Example 4: IoT: Device to cloud Direct device-to-cloud communication is common in simple IoT applications. Authentication in these applications is usually accomplished using shared credentials like API keys, or using client certificates. @@ -240,7 +240,7 @@ Using client DANE for device identity can allow parties other than the implement A hardware manufacturer can provide a pre-established identity, with the certificate or public key already published in DNS. This makes PKI-based identity more approachable for small organizations which currently lack the resources to operate an organizational CA. -### LoRaWAN +### Example 5: LoRaWAN For the end-device onboarding in LoRaWAN, the "network server" and the "join server" {{?RFC8376}} needs to establish mutual TLS authentication in order to exchange configuration parameters. @@ -250,7 +250,7 @@ Self-signed certificate based mutual-TLS authentication method is the alternativ DANE based client identity allows the server to authenticate clients during the TLS handhsake. Thus, independent of the private PKI used to issue the client's self-signed certificate, the "network server" and the "join server" could be mutually authenticated. -### Edge Computing +### Example 6: Edge Computing {{?I-D.hong-t2trg-iot-edge-computing}} may require devices to mutually authenticate in the field. A practical example of this pattern is the edge computing in construction use case {{?I-D.hong-t2trg-iot-edge-computing, Section 6.2.1}} @@ -262,7 +262,7 @@ Important sensor measurements forwarded by the gateway to the cloud may bear the the originating sensor, and the cloud application may authenticate the measurement independent of the gateway which forwarded the information to the application. -### Domain Users +### Example 7: 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. @@ -274,7 +274,7 @@ Any DANCEr may however define alternate derivation procedures to obtain the DNS 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. -### SIP and WebRTC inter-domain privacy +### Example 8: SIP and WebRTC inter-domain privacy End to end security in SIP is currently based on a classical S/MIME model which has not received much implementation. There are also SIP standards that build upon a trust chain anchored on the HTTP trust chain (SIP identity, STIR). @@ -288,7 +288,7 @@ In addition, SIP devices can establish security in the SIP messaging by using DN For an example, read {{?I-D.johansson-sipcore-dane-sip}}(SIPDANE). -### DNS over TLS client authentication +### Example 9: DNS over TLS client authentication DNS-over-TLS client authentication is applicable to most portions of the transport segments of the DNS infrastructure. @@ -315,7 +315,7 @@ internal zone, or to distinguish between subscribers to different performance ti In the ideal implementation, client and server would bidirectionally authenticate, using DANE client certificates to bootstrap TLS transport security. -### SMTP, STARTTLS +### Example 10: SMTP, STARTTLS SMTP has included the ability to upgrade in-protocol to TLS using the STARTTLS {{?RFC7817}} command. When upgrading the connection, the client checks the server certificate using the DNS-ID mechanisms described in {{!RFC9525}}. @@ -326,7 +326,7 @@ The use of client TLS certificates has not yet become common, in part because it For mail-transfer-agent (MTA) to MTA communications, the use of a TLSA RR as described in {{!I-D.ietf-dance-client-auth}} permits the SMTP server to check the identity of the parties trying to send email. There are many use cases, but a major one is often dealing with authenticated relaying of email. -### SSH client +### Example 11: SSH client SSH servers have for some time been able to put their host keys into DNS using {{?RFC4255}}. @@ -346,7 +346,7 @@ Separation of authorization and authentication in this case would involve puttin The DNS record used could be TLSA, but it is possible with some protocol work that it could instead be SSHFP. Since SSH can trust CA certificates from X.509, those may be published for user authentication. -### Network Access +### Example 12: Network Access Network access refers to an authentication process by which a node is admitted securely onto network infrastructure. This is most common for wireless networks (wifi, 802.15.4), but has also routinely been done for wired infrastructure using 802.1X mechanisms with EAPOL. @@ -398,7 +398,7 @@ RADIUS datagrams are then transmitted between the authenticator and authenticati Updating the RADSEC standard to include the use of DANE for client and server identity would allow a RADIUS server and client to mutually authenticate, independent of the client’s and server’s issuing CAs. The benefit for this use case is that a hosted RADIUS service may mutually authenticate any client device, like a WiFi access point or ethernet switch, via RADSEC, without requiring the distribution of CA certificates. -### Structured data messages: JOSE/COSE +### Example 13: Structured data messages: JOSE/COSE JOSE and COSE provide formats for exchanging authenticated and encrypted structured data. JOSE defines the x5u field in {{?RFC7515, Section 4.1.5}}, and COSE defines a field of the same name in {{?I-D.ietf-cose-x509, Section 2}}. From 10aebf574329ec9fb913d0537fbbe9625bc5923d Mon Sep 17 00:00:00 2001 From: "Olle E. Johansson" Date: Wed, 4 Sep 2024 17:38:23 +0200 Subject: [PATCH 2/8] Add an initial text on requirements on "how to dance" documents Signed-off-by: Olle E. Johansson --- draft-ietf-dance-architecture.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/draft-ietf-dance-architecture.md b/draft-ietf-dance-architecture.md index fd43692..9c8c587 100644 --- a/draft-ietf-dance-architecture.md +++ b/draft-ietf-dance-architecture.md @@ -407,6 +407,20 @@ There is, as yet, no URI scheme which says that the key can be found via the DNS In order to make use of x5u, a DANCEr would have to define a new URI scheme that explained how to get the right key from DNS. +# Protocol implementations + +For each protocol implementation, a specific usage document needs to be published. In this document, +the DANCE protocol requirements and usage needs to be specified (this is refered above as the "How to DANCE" document). +These documents should as a minimum contain the following sections: + +- Specifics on naming: How the name of the client is defined and how this is related to the name in + a DNS zone. This defines the organization of the related DNS zone. Whether a flat namespace is used, + or a way to use a DNS Zone hierarchy is applied to this usage. (see notes above on DNS zone design) +- Privacy: If the subject name is a personal identifier, how to protect that name from being exposed + in the DNS zone. {{?RFC7929}} describes one way to handle privacy for personal identifiers in DNS. +- TTL: Recommended TTL settings for records in this usage +- Security: Security considerations for this usage + # Security Considerations ## Confidentiality From fb6a8f938073629bce6a22f32e76adabeb381d68 Mon Sep 17 00:00:00 2001 From: "Olle E. Johansson" Date: Fri, 18 Oct 2024 15:35:22 +0200 Subject: [PATCH 3/8] Upgrade upload-artifact to v4 Closes issue #73 --- .github/workflows/archive.yml | 2 +- .github/workflows/ghpages.yml | 2 +- .github/workflows/publish.yml | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/.github/workflows/archive.yml b/.github/workflows/archive.yml index bfad094..7e52cd2 100644 --- a/.github/workflows/archive.yml +++ b/.github/workflows/archive.yml @@ -28,6 +28,6 @@ jobs: token: ${{ github.token }} - name: "Save Archive" - uses: actions/upload-artifact@v2 + uses: actions/upload-artifact@v4 with: path: archive.json diff --git a/.github/workflows/ghpages.yml b/.github/workflows/ghpages.yml index 118cb52..0f1080e 100644 --- a/.github/workflows/ghpages.yml +++ b/.github/workflows/ghpages.yml @@ -53,7 +53,7 @@ jobs: token: ${{ github.token }} - name: "Archive Built Drafts" - uses: actions/upload-artifact@v2 + uses: actions/upload-artifact@v4 with: path: | draft-*.html diff --git a/.github/workflows/publish.yml b/.github/workflows/publish.yml index dd94df9..f6b8a51 100644 --- a/.github/workflows/publish.yml +++ b/.github/workflows/publish.yml @@ -46,6 +46,6 @@ jobs: make: upload - name: "Archive Submitted Drafts" - uses: actions/upload-artifact@v2 + uses: actions/upload-artifact@v4 with: path: "draft-*-[0-9][0-9].xml" From f3bec65e56bc008a583b57969753bb94cc2114bb Mon Sep 17 00:00:00 2001 From: "Olle E. Johansson" Date: Fri, 18 Oct 2024 15:28:47 +0200 Subject: [PATCH 4/8] Remove "TBD" as these are documented in the other draft Closes #55 --- draft-ietf-dance-architecture.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/draft-ietf-dance-architecture.md b/draft-ietf-dance-architecture.md index 9c8c587..11e6d2f 100644 --- a/draft-ietf-dance-architecture.md +++ b/draft-ietf-dance-architecture.md @@ -190,7 +190,8 @@ This sort of attack (of type slowloris) could have a performance or availability - The TLS server compares the dane_clientid (conveyed via the DANE Client Identity extension) to a list of allowed client domains. - 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 not allowed, authentication fails. -- If the client's TLSA record matches the presented certificate or public key, the TLS handshake completes successfully and the authenticated dane_clientid is presented to the web application in the (TBD) header field. +- If the client's TLSA record matches the presented certificate or public key, the TLS handshake completes + successfully and the authenticated dane_clientid is presented to the web application in a header field. This pattern has the following advantages: @@ -201,7 +202,7 @@ This pattern has the following advantages: - The client initiates a TLS connection to the server. - The TLS server accepts any certificate for which the client can prove possession of the corresponding private key. -- The TLS server passes the certificate to the web application in (TBD) header field. +- The TLS server passes the certificate to the web application in a header field. - The HTTP request body contains the dane_clientid, and is passed to the web application. - The web application compares the dane_clientid to a list of allowed clients or client domains. - If the dane\_clientid is allowed, the web application makes the DNS query for the TLSA records for dane\_clientid From eb957c1d58663bc21ebb8b765f2c077dfb2dfd8b Mon Sep 17 00:00:00 2001 From: "Olle E. Johansson" Date: Fri, 18 Oct 2024 15:25:00 +0200 Subject: [PATCH 5/8] Add reference to new RFC for internationalised email addresses in x509 SubjectAltName Closes #68 --- draft-ietf-dance-architecture.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-dance-architecture.md b/draft-ietf-dance-architecture.md index 9c8c587..76ad1fa 100644 --- a/draft-ietf-dance-architecture.md +++ b/draft-ietf-dance-architecture.md @@ -173,11 +173,11 @@ Decoupled applications benefit from an out-of-band public key discovery mechanis The client sets up a TLS connection to a server, attaches a client certificate with one subjectAltName element dNSName indicating the DNS owner name of the client {{?RFC5280}}. -If the client is a user, their user identity is added in one subjectAltName element otherName holding their uid attribute {{?RFC4519}}. +If the client is a user, their user identity is added in one subjectAltName element +otherName holding their uid attribute {{?RFC4519}} or email address {{?RFC9598}}. 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 DNS lookup on the server side of the TLS connection. An opportunity for DDOS may exist when malicious clients can trigger arbitrary DNS lookups. From e6d0f73aa7ad9f6b4ea43f6fc84522fe5dc5724d Mon Sep 17 00:00:00 2001 From: "Olle E. Johansson" Date: Fri, 18 Oct 2024 15:45:33 +0200 Subject: [PATCH 6/8] remove open question Close #54 --- draft-ietf-dance-architecture.md | 1 - 1 file changed, 1 deletion(-) diff --git a/draft-ietf-dance-architecture.md b/draft-ietf-dance-architecture.md index 9c8c587..f03350a 100644 --- a/draft-ietf-dance-architecture.md +++ b/draft-ietf-dance-architecture.md @@ -110,7 +110,6 @@ any server with a DNS-bound identity, as long as a network path exists, the enti its communicating peer by its DNS owner name, and agreement on protocols can be achieved. The act of joining a security domain, in the past, may have involved certificate provisioning. Now, it can be as simple as using a manufacturer-provisioned identity to join the device to the network and application. -[Is the security domain defined by how broadly the identity is recognized, or by the breadth of the application or network access policy?] **Client:** This architecture document adopts the definition of "Client" from RFC 8446: "The endpoint initiating the TLS connection" From 98b588e98b4abffaa3d172b60d328e0a427dd433 Mon Sep 17 00:00:00 2001 From: "Olle E. Johansson" Date: Fri, 18 Oct 2024 16:40:46 +0200 Subject: [PATCH 7/8] Remove all the "circumstances" and provide a bullet list of examples. Close issue #53 --- draft-ietf-dance-architecture.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/draft-ietf-dance-architecture.md b/draft-ietf-dance-architecture.md index 9c8c587..994d49d 100644 --- a/draft-ietf-dance-architecture.md +++ b/draft-ietf-dance-architecture.md @@ -96,11 +96,15 @@ A first-class identity is an application-independent identity. **How to DANCE with ENTITY:** This architecture document delegates many details of how DANCE can be used with some specific protocol to a document with the name "How to DANCE with _entity_". **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 device 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. -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. +These steps may not be performed by the same party or organization. Examples: + +- A device manufacturer may instantiate the key pair, and a systems integrator may be + responsible for issuing (and publishing) the device certificate in DNS. +- A device manufacturer publish device identity records in DNS. The system integrator + needs to perform network and 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 that has been taught to use DANE, usually through a _How to DANCE with_ document. From 4f2a2fe8f003d94051ecb89d0434c09dc2258af1 Mon Sep 17 00:00:00 2001 From: Wes Hardaker Date: Wed, 22 Jan 2025 11:00:33 -0800 Subject: [PATCH 8/8] update stream and version number --- draft-ietf-dance-architecture.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-dance-architecture.md b/draft-ietf-dance-architecture.md index 81ca893..c9b93de 100644 --- a/draft-ietf-dance-architecture.md +++ b/draft-ietf-dance-architecture.md @@ -2,8 +2,9 @@ # title: "An Architecture for DNS-Bound Client and Sender Identities" abbrev: "DNS-Bound Identities Architecture" -docname: draft-ietf-dance-architecture-latest +docname: draft-ietf-dance-architecture-latest-08 category: info +stream: IETF ipr: trust200902 area: Internet