| Internet-Draft | DANE PKIX Certificate Discovery | March 2021 |
| Wilson & Huque | Expires 9 September 2021 | [Page] |
The DNS-Based Authentication of Named Entities (DANE) TLSA specification [RFC6698] and The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance [RFC7671] describe how to publish Transport Layer Security (TLS) server certificates or public keys in the DNS. This document updates [RFC6698] and [RFC7671]. It describes how to use the TLSA record to enable entity and CA certificate discovery for object security and trust chain discovery use cases, and how to use PKIX validation for TLSA records queried without the benefit of DNSSEC.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 9 September 2021.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
A digital identity consists of at least two essential elements: a name, and a method for proving ownership of the name. Digital identities are often represented using X.509 certificates [RFC5280], which bind a name to a public key under a certificate authority's signature. This allows all entities which trust the certificate authority to trust that the public key associated with the name in the certificate is authentic and unaltered. The public key may be used for authentication, in the establishment of a secure session between two entities using a protocol like TLS or DTLS. The public key in the certificate may also be used to provide object security mechanisms like cryptographic signature verification or payload encryption. The certificate discovery process for object security usually relies on either in-band transmission of the certificate by the sender (IEEE 802.11p DSRC), or out-of-band via a proprietary API presented by the certificate authority.¶
Internet of Things (IoT) applications increasingly need to authenticate messages sent through decoupled applications. Without some sort of message security mechanism in place, trust in sender identity is assumed based on the trustworthiness of all systems and networks involved in handling the message between the sending entity and the recipient. This document proposes the use of the DANE TLSA record for certificate discovery, and provides an optional method for certificate authentication, in the event DNSSEC is not available.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
An entity which generates a cryptographic signature for a message has an associated name in DNS, where a TLSA record may be found containing the entity's certificate. The entity's certificate contains the public key which can be used to authenticate the signature.¶
Likewise, an entity which can receive messages encrypted using a public key (either directly, or by way of a key-wrapping technique) has a DNS-based identity where a public key suitable for message encryption can be found.¶
A PKIX-CD identity has a discoverable certificate and trust anchor. The trust anchor MAY be used by a TLS server to populate a local certificate store for the purpose of enabling traditional PKI-based mutual TLS. This approach comes with constraints and caveats, as described in Security (Section 7), below. The use of PKIX-CD for enabling mutual TLS is a wrapper for PKI-based mutual authentication, and does not change the way that TLS operates. This approach provides a transitional state from PKIX-based DANE to DNSSEC-based DANE for mutual TLS authentication. Trust anchor discovery MAY happen on-the-fly within the TLS handshake only when using DNSSEC-based DANE.¶
DNSSEC SHOULD be used to ensure the integrity of the certificate presented via the TLSA record. For a variety of reasons, DNSSEC is not ubiquitous across the entire DNS namespace. For zones which are not protected by DNSSEC, the CA certificate which can be used to verify the certificates presented by the TLSA records MUST be retrieved from a known location derived from the identity's full DNS name.¶
This document defines a specific label or DNS naming format for the TLSA DNS records which carry entity certificates, and this format is compatible with the [TLSCLIENTID]. This is necessary to provide a well-known location for securely retrieving a CA certificate which can be used to verify certificates retrieved from DNS without the benefit of DNSSEC.¶
For a device identity with DNS name a1b2c3._device.subdomain.organization.example, we can decompose the DNS name into a few important parts:¶
The device identifier MAY consist of multiple labels, but for simplicity's sake we will represent it here as only one label.¶
The identity grouping label is the rightmost label prefixed by an underscore, to the left of the organizational domain. This does not need to be immediately adjacent to the organizational domain; labels MAY exist between the identity grouping label and the organizational domain. In the above example, this is _device. Another example might be abc123._messagesender.subdomain.example.net, where the identity grouping label would be _messagesender.¶
The organizational label(s) is any label existing between the identity grouping label and the organizational domain.¶
The organizational domain is the domain that was registered with a domain name registrar.¶
The identity domain is all labels from the top-level domain label through the identity grouping label.¶
In order to authenticate device certificates presented in TLSA records, without DNSSEC, we must safely obtain a CA certificate which can be used to verify the entity certificate.¶
Using the components of the device name, together with the authorityKeyIdentifier (AKI) found in the entity certificate (described in [RFC5280]), we can compose the URL where the signing certificate should be found.¶
The process whereby the signing certificate URL can be constructed for a device named a1b2c3._device.environment.example.net is as follows:¶
The file found at the URL MUST contain exactly one PEM-encoded CA certificate. The HTTPS server presenting the file MUST use TLS with a certificate that can be validated to the TLS client's client root certificate store, if DANE is not used for the server's identity. The certificate in the PEM file does not need to chain to the TLS client's root certificate store.¶
A PEM-encoded certificate being presented by a server possessing a DANE or Web PKI-validated identity is sufficient to indicate the trustworthiness of the CA certificate for validating certificates presented for associated identities. In this example, the certificate found at https://device.environment.organization.example/.well-known/ca/AA-BB-CC.pem MAY be cached and used to validate PKIX-CD certificates with identities matching *._device.environment.example.net, if the certificates contain AKI AA-BB-CC.¶
Benefits of this approach:¶
The method of certificate discovery via TLSA records, without DNSSEC, SHALL be referred to as PKIX-CD, and shall use the DANE Certificate Usage value of 4. The presence of the certificate usage value 4 indicates that the party requesting the certificate is responsible for validating it using the CA certificate located at the authority URL, which can be composed using the process described above.¶
The certificates presented with PKIX-CD MUST contain the subjectAlternativeName OID, with at least one dNSName which matches the DNS name used to retrieve the certificate. A certificate which is delivered without the benefit of DNSSEC, even if the CA's signature is valid, MUST NOT be trusted without alignment between the DNS name used to retrieve the certificate and one DNSName attribute within the certificate. The SubjectAlternativeName field MAY have other entries in addition to the one which aligns with the DNS name where the certificate can be discovered.¶
This document includes no request to IANA.¶
This document updates RFC 6698 by defining the use of the TLSA record for discovering client TLS certificates and associated CA certificates. However, the security model presented here is quite different than the security model presented in RFC 6698. RFC 6698 relies on DNSSEC as the public key infrastructure (PKI) used for validating certificates (or certificate metadata) presented via TLSA resource records in DNS. This draft proposes the use of Web PKI as the root of trust, in the event the zone presenting TLSA records for this use case is not protected by DNSSEC. Web PKI's root of trust is in the browser CA bundle, and the substitution of Web PKI for the DNSSEC PKI trades the security implications of DNSSEC for Web PKI.¶
Because PKIX-CD can provide an avenue for certificate chain discovery, care must be taken to ensure that identities are authenticated via the correct chain. There may be a desire to locally cache all discovered CA certificates into a general certificate store. This must not happen without certain controls in place. Without the identity consumer (authenticator) ensuring that the signing certificate for a particular zone is only used to verify certificates ONLY from that particular zone, cross-domain impersonation (is this a cousin of the confused deputy problem?) may be possible. An example of this is an application where organization.example and supplier.example both present identities via PKIX-CD. If the CA certificates from organization.example and supplier.example are loaded into a local certificate store and used for authenticating certificates from both zones, then devices under supplier.example may be deemed authentic even if signed by organization.example.¶