idnits 2.17.1 draft-wilson-dane-pkix-cd-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6698], [RFC7671]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (8 March 2021) is 1145 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'TLSCLIENTID' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Wilson 3 Internet-Draft Valimail 4 Updates: 6698, 7671 (if approved) S. Huque 5 Intended status: Standards Track Salesforce 6 Expires: 9 September 2021 8 March 2021 8 PKI-Authenticated Certificate Discovery Using DANE TLSA records 9 draft-wilson-dane-pkix-cd-00 11 Abstract 13 The DNS-Based Authentication of Named Entities (DANE) TLSA 14 specification [RFC6698] and The DNS-Based Authentication of Named 15 Entities (DANE) Protocol: Updates and Operational Guidance [RFC7671] 16 describe how to publish Transport Layer Security (TLS) server 17 certificates or public keys in the DNS. This document updates 18 [RFC6698] and [RFC7671]. It describes how to use the TLSA record to 19 enable entity and CA certificate discovery for object security and 20 trust chain discovery use cases, and how to use PKIX validation for 21 TLSA records queried without the benefit of DNSSEC. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 9 September 2021. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Background and Motivation . . . . . . . . . . . . . . . . . . 2 57 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Authentication Model . . . . . . . . . . . . . . . . . . . . 3 61 3.1. Object Signing And Encryption . . . . . . . . . . . . . . 3 62 3.2. Trust Anchors . . . . . . . . . . . . . . . . . . . . . . 3 63 3.3. Trust Model For DNS-Based Identities . . . . . . . . . . 4 64 3.4. DNS Naming Convention Or Labeling Format . . . . . . . . 4 65 3.5. Trust Anchor Discovery . . . . . . . . . . . . . . . . . 5 66 4. Update to DANE . . . . . . . . . . . . . . . . . . . . . . . 6 67 5. PKIX Constraints . . . . . . . . . . . . . . . . . . . . . . 6 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Background and Motivation 76 1.1. Background 78 A digital identity consists of at least two essential elements: a 79 name, and a method for proving ownership of the name. Digital 80 identities are often represented using X.509 certificates [RFC5280], 81 which bind a name to a public key under a certificate authority's 82 signature. This allows all entities which trust the certificate 83 authority to trust that the public key associated with the name in 84 the certificate is authentic and unaltered. The public key may be 85 used for authentication, in the establishment of a secure session 86 between two entities using a protocol like TLS or DTLS. The public 87 key in the certificate may also be used to provide object security 88 mechanisms like cryptographic signature verification or payload 89 encryption. The certificate discovery process for object security 90 usually relies on either in-band transmission of the certificate by 91 the sender (IEEE 802.11p DSRC), or out-of-band via a proprietary API 92 presented by the certificate authority. 94 1.2. Motivation 96 Internet of Things (IoT) applications increasingly need to 97 authenticate messages sent through decoupled applications. Without 98 some sort of message security mechanism in place, trust in sender 99 identity is assumed based on the trustworthiness of all systems and 100 networks involved in handling the message between the sending entity 101 and the recipient. This document proposes the use of the DANE TLSA 102 record for certificate discovery, and provides an optional method for 103 certificate authentication, in the event DNSSEC is not available. 105 2. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in BCP 110 14 [RFC2119] [RFC8174] when, and only when, they appear in all 111 capitals, as shown here. 113 3. Authentication Model 115 3.1. Object Signing And Encryption 117 An entity which generates a cryptographic signature for a message has 118 an associated name in DNS, where a TLSA record may be found 119 containing the entity's certificate. The entity's certificate 120 contains the public key which can be used to authenticate the 121 signature. 123 Likewise, an entity which can receive messages encrypted using a 124 public key (either directly, or by way of a key-wrapping technique) 125 has a DNS-based identity where a public key suitable for message 126 encryption can be found. 128 3.2. Trust Anchors 130 A PKIX-CD identity has a discoverable certificate and trust anchor. 131 The trust anchor MAY be used by a TLS server to populate a local 132 certificate store for the purpose of enabling traditional PKI-based 133 mutual TLS. This approach comes with constraints and caveats, as 134 described in Security (Section 7), below. The use of PKIX-CD for 135 enabling mutual TLS is a wrapper for PKI-based mutual authentication, 136 and does not change the way that TLS operates. This approach 137 provides a transitional state from PKIX-based DANE to DNSSEC-based 138 DANE for mutual TLS authentication. Trust anchor discovery MAY 139 happen on-the-fly within the TLS handshake only when using DNSSEC- 140 based DANE. 142 3.3. Trust Model For DNS-Based Identities 144 DNSSEC SHOULD be used to ensure the integrity of the certificate 145 presented via the TLSA record. For a variety of reasons, DNSSEC is 146 not ubiquitous across the entire DNS namespace. For zones which are 147 not protected by DNSSEC, the CA certificate which can be used to 148 verify the certificates presented by the TLSA records MUST be 149 retrieved from a known location derived from the identity's full DNS 150 name. 152 3.4. DNS Naming Convention Or Labeling Format 154 This document defines a specific label or DNS naming format for the 155 TLSA DNS records which carry entity certificates, and this format is 156 compatible with the [TLSCLIENTID]. This is necessary to provide a 157 well-known location for securely retrieving a CA certificate which 158 can be used to verify certificates retrieved from DNS without the 159 benefit of DNSSEC. 161 For a device identity with DNS name 162 a1b2c3._device.subdomain.organization.example, we can decompose the 163 DNS name into a few important parts: 165 * a1b2c3: device identifier 167 * _device: identity grouping label 169 * subdomain: organizational label 171 * organization.example: organizational domain 173 * _device.subdomain.organization.example: identity domain 175 The device identifier MAY consist of multiple labels, but for 176 simplicity's sake we will represent it here as only one label. 178 The identity grouping label is the rightmost label prefixed by an 179 underscore, to the left of the organizational domain. This does not 180 need to be immediately adjacent to the organizational domain; labels 181 MAY exist between the identity grouping label and the organizational 182 domain. In the above example, this is _device. Another example 183 might be abc123._messagesender.subdomain.example.net, where the 184 identity grouping label would be _messagesender. 186 The organizational label(s) is any label existing between the 187 identity grouping label and the organizational domain. 189 The organizational domain is the domain that was registered with a 190 domain name registrar. 192 The identity domain is all labels from the top-level domain label 193 through the identity grouping label. 195 3.5. Trust Anchor Discovery 197 In order to authenticate device certificates presented in TLSA 198 records, without DNSSEC, we must safely obtain a CA certificate which 199 can be used to verify the entity certificate. 201 Using the components of the device name, together with the 202 authorityKeyIdentifier (AKI) found in the entity certificate 203 (described in [RFC5280]), we can compose the URL where the signing 204 certificate should be found. 206 The process whereby the signing certificate URL can be constructed 207 for a device named a1b2c3._device.environment.example.net is as 208 follows: 210 1. Perform a DNS query for 211 a1b2c3._device.environment.organization.example rrtype==TLSA. 213 2. Extract the AKI from the certificate. We will use AA-BB-CC as 214 the placeholder in this example. 216 3. Identify the organizational domain: organization.example 218 4. Identify any organizational labels: environment 220 5. Identify the identity grouping label, and remove the underscore 221 prefix: device 223 6. Using the following pattern, create the hostname: ${IDENTITY_GROU 224 PING_LABEL}.${ORGANIZATIONAL_LABELS}.${ORGANIZATIONAL_DOMAIN}: 225 device.environment.organization.example 227 7. Adding HTTPS and the AKI, build the authority URI: 228 https://device.environment.organization.example/.well-known/ca/ 229 AA-BB-CC.pem 231 The file found at the URL MUST contain exactly one PEM-encoded CA 232 certificate. The HTTPS server presenting the file MUST use TLS with 233 a certificate that can be validated to the TLS client's client root 234 certificate store, if DANE is not used for the server's identity. 235 The certificate in the PEM file does not need to chain to the TLS 236 client's root certificate store. 238 A PEM-encoded certificate being presented by a server possessing a 239 DANE or Web PKI-validated identity is sufficient to indicate the 240 trustworthiness of the CA certificate for validating certificates 241 presented for associated identities. In this example, the 242 certificate found at 243 https://device.environment.organization.example/.well-known/ca/AA-BB- 244 CC.pem MAY be cached and used to validate PKIX-CD certificates with 245 identities matching *._device.environment.example.net, if the 246 certificates contain AKI AA-BB-CC. 248 Benefits of this approach: 250 * This method uses an HTTPS server as a content-addressable storage 251 mechanism for public keys in CA certificates. The HTTPS server 252 MAY host any number of CA certificates, and the HTTPS server does 253 not need to provide any directory listing service. This makes the 254 discovery of CA certificates possible by already knowing an 255 identity's AKI, and the entire CA bundle for the zone is not 256 required to be distributable as a bundle. 258 * Device identities exist in a zone apart from other identities, 259 which may have granular management access controls applied. 261 * The DNS record used for locating the CA certificates does not 262 exist in the same zone as the records it is used to verify. The 263 zone where the authority record is located may have granular rules 264 applied which create compartmentalized failure zones. If the 265 device identity zone is compromised, altered certificates will not 266 validate unless the authority server can also be impersonated. 268 4. Update to DANE 270 The method of certificate discovery via TLSA records, without DNSSEC, 271 SHALL be referred to as PKIX-CD, and shall use the DANE Certificate 272 Usage value of 4. The presence of the certificate usage value 4 273 indicates that the party requesting the certificate is responsible 274 for validating it using the CA certificate located at the authority 275 URL, which can be composed using the process described above. 277 5. PKIX Constraints 279 The certificates presented with PKIX-CD MUST contain the 280 subjectAlternativeName OID, with at least one dNSName which matches 281 the DNS name used to retrieve the certificate. A certificate which 282 is delivered without the benefit of DNSSEC, even if the CA's 283 signature is valid, MUST NOT be trusted without alignment between the 284 DNS name used to retrieve the certificate and one DNSName attribute 285 within the certificate. The SubjectAlternativeName field MAY have 286 other entries in addition to the one which aligns with the DNS name 287 where the certificate can be discovered. 289 6. IANA Considerations 291 This document includes no request to IANA. 293 7. Security Considerations 295 This document updates RFC 6698 by defining the use of the TLSA record 296 for discovering client TLS certificates and associated CA 297 certificates. However, the security model presented here is quite 298 different than the security model presented in RFC 6698. RFC 6698 299 relies on DNSSEC as the public key infrastructure (PKI) used for 300 validating certificates (or certificate metadata) presented via TLSA 301 resource records in DNS. This draft proposes the use of Web PKI as 302 the root of trust, in the event the zone presenting TLSA records for 303 this use case is not protected by DNSSEC. Web PKI's root of trust is 304 in the browser CA bundle, and the substitution of Web PKI for the 305 DNSSEC PKI trades the security implications of DNSSEC for Web PKI. 307 Because PKIX-CD can provide an avenue for certificate chain 308 discovery, care must be taken to ensure that identities are 309 authenticated via the correct chain. There may be a desire to 310 locally cache all discovered CA certificates into a general 311 certificate store. This must not happen without certain controls in 312 place. Without the identity consumer (authenticator) ensuring that 313 the signing certificate for a particular zone is only used to verify 314 certificates ONLY from that particular zone, cross-domain 315 impersonation (is this a cousin of the confused deputy problem?) may 316 be possible. An example of this is an application where 317 organization.example and supplier.example both present identities via 318 PKIX-CD. If the CA certificates from organization.example and 319 supplier.example are loaded into a local certificate store and used 320 for authenticating certificates from both zones, then devices under 321 supplier.example may be deemed authentic even if signed by 322 organization.example. 324 8. References 326 8.1. Normative References 328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 329 Requirement Levels", BCP 14, RFC 2119, 330 DOI 10.17487/RFC2119, March 1997, 331 . 333 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 334 Housley, R., and W. Polk, "Internet X.509 Public Key 335 Infrastructure Certificate and Certificate Revocation List 336 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 337 . 339 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 340 of Named Entities (DANE) Transport Layer Security (TLS) 341 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 342 2012, . 344 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 345 Authentication of Named Entities (DANE) Protocol: Updates 346 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 347 October 2015, . 349 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 350 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 351 May 2017, . 353 [TLSCLIENTID] 354 Huque, S. and V. Dukhovni, "TLS Extension for DANE Client 355 Identity", . 358 Authors' Addresses 360 Ash Wilson 361 Valimail 363 Email: ash.d.wilson@gmail.com 365 Shumon Huque 366 Salesforce 368 Email: shuque@gmail.com