]> Huawei Int. Pte Ltd

Singapore li.ruochen@huawei.com

Huawei Int. Pte Ltd

Singapore wang.haiguang.shieldlab@huawei.com

Huawei Int. Pte Ltd

Singapore lei.zhongding@huawei.com

Automated Certificate Management Environment This document outlines how ACME DNS based challenges can be performed via DNS dynamic updates. Status information for this document may be found at . Discussion of this document takes place on the WG Working Group mailing list (), which is archived at . Subscribe at .

Introduction The ACME protocol provides a means to automate certificate issuance that allows a CA/RA to verify that a client has control of identifiers in the requested certificate via domain control validation (DCV) challenges. For DNS identifiers, dns-01 challenge specified in and dns-account-01 challenges specified in require the client to create a DNS resource record (RR) on the authoritative nameserver under the domain "<challenge-specific-label>.<domain-to-validate>" to prove control of the domain in the DNS identifier. However, the procedure to update DNS records is not specified. defines the DNS UPDATE message which instructs an authoritative nameserver to add or delete RRs or RRsets from a specified zone. It can further be secured using a message authentication code (MAC) in a TSIG RR . To set up the shared key used for the TSIG RR, specifies the TKEY RR which can be used to establish or delete this shared secret, where the message that carries the TKEY RR needs to be authenticated using TSIG with a previously established secret or SIG(0) . This document outlines how an ACME client can perform DNS resource record updates to complete ACME DNS based challenges automatically, and how to do so securely via authenticated DNS update messages. The procedures defined in this document are designed to facilitate implementation and bridge the gap in . [[Comment: is being updated at . Relevant sections in this document will be updated if this draft is accepted.]]

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Terminology OAM (or O&M): Operations and management, as per (), an entity or system that is responsible for management of resources in a network.

General Architecture OAM is responsible for configuration of ACME clients in a network. OAM first configures a domain name and an initial authentication key for the ACME client, and sets relevant resource records and access control settings on the authoritative nameserver . The ACME client then applies for a certificate for that domain name from the ACME server through ACME protocol with DNS-based challenges that requires configuring certain DNS records. The ACME client completes a challenge by establishing a transaction key using the initial authentication key, and then provision the required resource records on the authoritative nameserver, authenticated using the transaction key. The ACME server then fetches the resource records to validate the challenge, and proceeds with certificate issuance.

It is assumed that the ACME client and the authoritative nameserver can be managed by OAM (i.e. OAM is capable of and authorized for configuring the ACME client and the authoritative nameserver).

Use Cases The procedures outlined in this document provide a standardized way for ACME clients to respond to DNS based challenges. They can be applied to scenarios where clients use DNS based challenges to apply for certificates via ACME. They are especially useful if there are a large number of clients from different vendors.

Cloud Computing In a typical cloud environment, there can be hundreds or even thousands of entities (applications, servers, etc.) that require certificates, and certificates often need to be renewed or replaced. Managing these certificates manually is error-prone, time-consuming, and can lead to security vulnerabilities and operational inefficiencies. Therefore, the cloud environment could benefit from ACME which allows each entity to apply for its own certificate automatically. DNS based ACME Challenges cam be used for entities that do not act as web servers.

5G Core Network The 5G core networks are service-based and consist of network functions (NFs) that communicate with one another via TLS connections, authenticated using X.509 (PKIX) certificates . Since NFs in a 5G network may come from different vendors, they could benefit from a standardized certificate management protocol such as ACME . While ACME has proved to be very effective for the web, special considerations are needed if we want to deploy it in 5G networks which have more constraints. Section 5 of outlines some key issues regarding application of ACME in a 5G system. Notably, 5.1 ACME initial trust framework and 5.3 Aspects of challenge validation point out that there is a need to define procedures for an NF to follow when proving its identity to ACME servers. Similar to the cloud scenario, some 5G NFs are consumer NFs that do not expose web servers. They can therefore benefit from DNS based ACME challenges that do not require setting up a web server.

Procedure Overview Assumptions: OAM has pre-established trust relationship with the authoritative nameserver, so that it is able to update DNS records and configurations of the authoritative nameserver. This can be carried out through DNS UPDATE messages authenticated with TSIG . OAM can securely perform certain maintenance operations on target ACME clients and the authoritative nameserver. See . The authoritative nameserver is accessible by the CA/RA/ACME server. General Procedure: OAM configures an initial TSIG authentication key on the ACME client for authenticating it against the authoritative nameserver on which ACME DCV DNS records are hosted. OAM also registers the initial authentication key on the authoritative nameserver and configures its permissions. The ACME client uses initial authentication parameters to establish a transaction key for TSIG with the authoritative nameserver via TKEY ; or the ACME client uses the initial authentication key as the transaction key. The ACME client uses the transaction key to authenticate its DNS UPDATE message that configures an ACME DCV DNS record.

│ │ │ │ │ │ │2 Transaction authentication │ │ │key establishment using │ │ │initial authentication key │ │ │─────────────────────────────>│ │ │ │ ┌─────────────────────────────────────────┐ │ │ACME client applies for certificate via │ │ │ACME, and proceed to the next step │ │ │after receiving a DNS based challenge │ │ └─────────────────────────────────────────┘ │ │ │ 3 DNS update using the │ │ │ previously established │ │ │ transaction key │ │ │─────────────────────────────>│ │ │ │ ┌──────────────────────────────────────────┐ │ │The DNS based challenge can be validated │ │ │by the ACME server │ │ ┌└──────────────────────────────────────────┘ ┌──────┴──────┐ │OAM│ │ACME Client│ │Authoritative│ │ │ └───────────┘ │Nameserver │ └───┘ └─────────────┘ ]]>

Maintenance Functions In order to set up initial authentication keys for ACME clients that apply for certificates to be authenticated by the authoritative nameserver, the ACME clients and the authoritative nameserver need to support certain maintenance operations from the OAM system. For ACME clients: Adjusting configurations (authoritative nameserver address, ACME server address, etc.) OAM to generate the symmetric TSIG key and configure it on the ACME client For the authoritative nameserver: Adjusting configurations (TSIG key, etc.) Updating DNS records (editing zone files)

Certificate Issuance Procedure

Initial Authentication Key OAM configures the target ACME client's initial authentication key, and configures the corresponding parameters on the authoritative nameserver, so that the authoritative nameserver can verify the identity of the ACME client. OAM generates a TSIG secret key for the ACME client OAM configures the ACME client's domain name and TSIG secret key OAM provisions the TSIG secret key to the authoritative nameserver

Transaction Key Establishment After setting up the initial authentication key, the ACME client possesses a key that can be used to authenticate DNS messages sent to the authoritative nameserver. However, using the same key over a long period of time may not be desirable. It is therefore RECOMMENDED to establish a separate TSIG transaction key for this purpose. The transaction key can be safely deleted after use or after a short period of time. Although NOT RECOMMENDED, the ACME client can use the initial authentication key as the transaction key, if key establishment methods specified here or access control settings in are not supported by the authoritative nameserver.

TSIG Transaction Key Establishment The ACME client can establish a TSIG transaction key with the authoritative nameserver through a TKEY exchange . Note that the TKEY RR provides an inception field and an expiration field that define a validity interval for the TSIG key to be established. It is RECOMMENDED to set a short interval (within a day) so that the key can be safely discarded afterwards.

Domain Control Validation

ACME Client Performs DNS Update The ACME client updates ACME DCV DNS records using DNS UPDATE messages . Transactional security is to be applied to DNS UPDATE messages via TSIG, using a key established in previous steps. This work follows to authenticate DNS UPDATE messages.

ACME Challenges The DNS update method specified in this document supports dns-01 from , dns-account-01 from and other DNS based challenges.

Access Control for Authentication Keys The authoritative nameserver MUST be pre-configured for fine-grained access control for TSIG keys used for DCV and/or transaction key establishment. This section specifies how DCV update keys and transaction key establishment keys are to be configured.

DCV Update Permissioning The authoritative nameserver SHALL implement fine-grained permissioning to only allow each ACME client's transactional TSIG keys to be used for updating ACME DCV DNS records relevant to the ACME client's assigned domain. As an example, the authoritative nameserver MAY be configured to allow keys under domains with a format of _acme-dns-key.<domain-to-validate>[.<tkey-domain>] to be used to UPDATE (add or remove) one or many of the DCV DNS records below: TXT records under _acme-challenge.<domain-to-validate> (dns-01) TXT records under _*._acme-challenge.<domain-to-validate> (dns-account-01) Note that the authoritative nameserver MAY also verify that the wildcard in the domain name above is a valid base32 encoded string.

Transaction Key Establishment Permissioning When using TKEY RR to establish transactional TSIG keys, the key used for authenticating the key establishment SHALL only be allowed to perform key establishment for specific domains (key ids). As an example, the authoritative nameserver MAY be configured to allow keys under domains with a format of _key-exchange-key.<key-domain>[.<tkey-domain>] to be used to establish the following transaction keys: TSIG key under _acme-dns-key.<key-domain>.<tkey-domain>, established via a TKEY RR

Security Considerations DNS Updates via UDP messages are sent in plaintext, which may be vulnerable to eavesdropping and tampering. This can be mitigated by using DoT or DoH . The TSIG authentication mechanism incorporates a validity period, which is set by the client and verified by the server, to defend against replay attack. However, DNS update requests, even using TSIG for authentication, are not idempotent, and therefore a replay attack is possible within the validity period. This can be avoided by using marker RRs in the Update request, as per section 5 of . Alternatively, DoT or DoH can be used so that the request can be protected by TLS. As per , the initial authentication keys and transaction authentication keys should be configured with fine-grained permission control to prevent access to unauthorized resources. When establishing transactional TSIG keys via TKEY, it is RECOMMENDED to set a short validity interval (e.g., within a day), and use each transactional TSIG key only once or for a short period of time. This work follows recommendations set out in by integrating challenge types proposed in .

Operational Considerations ACME clients SHOULD clean up DCV DNS records once the respective ACME challenges are completed, i.e., once the "status" field of the challenge is "valid" or "invalid". ACME clients SHOULD delete transactional TSIG keys stored on the authoritative nameserver after use (via TKEY RRs).

IANA Considerations This document has no IANA actions.

At first glance, the acronym "OAM" seems to be well-known and well-understood. Looking at the acronym a bit more closely reveals a set of recurring problems that are revisited time and again. This document provides a definition of the acronym "OAM" (Operations, Administration, and Maintenance) for use in all future IETF documents that refer to OAM. There are other definitions and acronyms that will be discussed while exploring the definition of the constituent parts of the "OAM" term. This memo documents an Internet Best Current Practice. This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Using this specification of the UPDATE opcode, it is possible to add or delete RRs or RRsets from a specified zone. Prerequisites are specified separately from update operations, and can specify a dependency upon either the previous existence or nonexistence of an RRset, or the existence of a single RR. [STANDARDS-TRACK] This document describes a Transaction Key (TKEY) RR that can be used in a number of different modes to establish shared secret keys between a DNS resolver and server. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. This document describes a protocol for transaction-level authentication using shared secrets and one-way hashing. It can be used to authenticate dynamic updates to a DNS zone as coming from an approved client or to authenticate responses as coming from an approved name server. No recommendation is made here for distributing the shared secrets; it is expected that a network administrator will statically configure name servers and clients using some out-of-band mechanism. This document obsoletes RFCs 2845 and 4635. Independent Internet Systems Consortium RFC 8945 provides efficient authentication of Domain Name System (DNS) protocol messages using shared secret keys and the Transaction Signature (TSIG) resource record (RR). However, it provides no mechanism for setting up such keys other than configuration. This document describes the Transaction Key (TKEY) RR that can be used in a variety of modes to establish shared secret keys between a DNS resolver and server. This document obsoletes RFC 2930. Independent Contributor Spirl Google Google Google This document outlines a new DNS-based challenge type for the ACME protocol that enables multiple independent systems to authorize a single domain name concurrently. By adding a unique label to the DNS validation record name, the dns-account-01 challenge avoids CNAME delegation conflicts inherent to the dns-01 challenge type. This is particularly valuable for multi-region or multi-cloud deployments that wish to rely upon DNS-based domain control validation and need to independently obtain certificates for the same domain. This document describes the minor but non-interoperable changes in Request and Transaction signature resource records ( SIG(0)s ) that implementation experience has deemed necessary. [STANDARDS-TRACK] This document proposes a method for performing secure Domain Name System (DNS) dynamic updates. [STANDARDS-TRACK] This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. Brave Software Salesforce Aiven Akamai Technologies Many application services on the Internet need to verify ownership or control of a domain in the Domain Name System (DNS). The general term for this process is "Domain Control Validation", and can be done using a variety of methods such as email, HTTP/HTTPS, or the DNS itself. This document focuses only on DNS-based methods, which typically involve the Application Service Provider requesting a DNS record with a specific format and content to be visible in the domain to be verified. There is wide variation in the details of these methods today. This document provides some best practices to avoid known problems. 3rd Generation Partnership Project 3GPP TS:33.776 V0.3.0 3rd Generation Partnership Project 3GPP TS:33.876 V18.0.1

Example DNS Authoritative Nameserver Configurations Note: '\' line wrapping per .

BIND9 In BIND9, TSIG keys, while not stored in DNS, also have FQDNs as key names. In the named configuration file, a zone can be configured to support updates using a key identified by an FQDN using the update-policy statement. Note that it is not possible to configure BIND9 to support the general access control strategy specified in , because each zone to be updated needs to be configured explicitly. Command to generate TSIG key for f9657a41-610c-414a-828a-fc88250f9165.amf.tsig.:

Example named configuration that grants the key permission to update TXT records for *.f9657a41-610c-414a-828a-fc88250f9165.amf.5gc.mnc001.mcc001.3gppnetwork.org.: