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 29 August 2025.¶
Copyright (c) 2025 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 Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.¶
The ACME protocol [RFC8555] 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 [RFC1035] identifiers, dns-01 challenge specified in [RFC8555] and dns-account-01 challenges specified in [I-D.ietf-acme-dns-account-label] 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.¶
[RFC2136] 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 [RFC8945]. To set up the shared key used for the TSIG RR, [RFC2930] 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) [RFC2931].¶
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 [RFC8555].¶
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.¶
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 [RFC9499]. 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).¶
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.¶
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.¶
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 [RFC5280]. Since NFs in a 5G network may come from different vendors, they could benefit from a standardized certificate management protocol such as ACME [TR33.876]. 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 [TR33.776] 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.¶
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 [RFC8945].¶
OAM can securely perform certain maintenance operations on target ACME clients and the authoritative nameserver. See Section 7.¶
The authoritative nameserver is accessible by the CA/RA/ACME server.¶
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 [RFC8945] with the authoritative nameserver via TKEY [RFC2930]; 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 [RFC2136] message that configures an ACME DCV DNS record.¶
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.¶
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¶
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 Section 9 are not supported by the authoritative nameserver.¶
The ACME client can establish a TSIG transaction key with the authoritative nameserver through a TKEY exchange [RFC2930].¶
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.¶
The ACME client updates ACME DCV DNS records using DNS UPDATE messages [RFC2136]. Transactional security is to be applied to DNS UPDATE messages via TSIG, using a key established in previous steps.¶
This work follows [RFC3007] to authenticate DNS UPDATE messages.¶
The DNS update method specified in this document supports dns-01 from [RFC8555], dns-account-01 from [I-D.ietf-acme-dns-account-label] and other DNS based challenges.¶
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.¶
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.¶
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¶
DNS Updates via UDP messages are sent in plaintext, which may be vulnerable to eavesdropping and tampering. This can be mitigated by using DoT [RFC7858] or DoH [RFC8484].¶
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 [RFC2136]. Alternatively, DoT or DoH can be used so that the request can be protected by TLS.¶
As per Section 9, 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.¶
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).¶
Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, DOI 10.17487/RFC6291, , <https://www.rfc-editor.org/info/rfc6291>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC2136]
Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, , <https://www.rfc-editor.org/rfc/rfc2136>.
Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, , <https://www.rfc-editor.org/rfc/rfc5280>.
[RFC7858]
Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, , <https://www.rfc-editor.org/rfc/rfc7858>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, , <https://www.rfc-editor.org/rfc/rfc8555>.
[RFC8945]
Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D., Gudmundsson, O., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", STD 93, RFC 8945, DOI 10.17487/RFC8945, , <https://www.rfc-editor.org/rfc/rfc8945>.
Chariton, A., Omidi, A., Kasten, J., Loukos, F., and S. A. Janikowski, "Automated Certificate Management Environment (ACME) DNS Labeled With ACME Account ID Challenge", Work in Progress, Internet-Draft, draft-ietf-acme-dns-account-label-00, , <https://datatracker.ietf.org/doc/html/draft-ietf-acme-dns-account-label-00>.
Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, "Handling Long Lines in Content of Internet-Drafts and RFCs", RFC 8792, DOI 10.17487/RFC8792, , <https://www.rfc-editor.org/rfc/rfc8792>.
3rd Generation Partnership Project, "Technical Specification Group Services and System Aspects; Study of Automatic Certificate Management Environment (ACME) for the Service Based Architecture (SBA) (Release 19)", 3GPP TS:33.776 V0.3.0, , <https://www.3gpp.org/ftp/Specs/archive/33_series/33.776/33776-030.zip>.
[TR33.876]
3rd Generation Partnership Project, "Technical Specification Group Services and System Aspects; Study on automated certificate management in Service-Based Architecture (SBA) (Release 18)", 3GPP TS:33.876 V18.0.1, , <https://www.3gpp.org/ftp/Specs/archive/33_series/33.876/33876-i01.zip>.
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 [RFC2136] 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 Section 9.1, because each zone to be updated needs to be configured explicitly.¶
Command to generate TSIG key for f9657a41-610c-414a-828a-fc88250f9165.amf.tsig.:¶
tsig-keygen -a HMAC-SHA512 f9657a41-610c-414a-828a-fc88250f9165.am\
f.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.:¶
//named.conf
key "f9657a41-610c-414a-828a-fc88250f9165.amf.tsig." {
algorithm hmac-sha512;
secret "MhKYgOU+mb1nLegdky3zPydpIFlhhBD4ic9WcjbCBLHFh+Rb+my8of\
1pGcChMBfiWrnLdn0lnmL1t4iTMb4LNw==";
};
zone "5gc.mnc001.mcc001.3gppnetwork.org." {
type primary;
update-policy {
grant f9657a41-610c-414a-828a-fc88250f9165.amf.tsig. wildc\
ard *.f9657a41-610c-414a-828a-fc88250f9165.amf.5gc.mnc001.\
mcc001.3gppnetwork.org. TXT;
};
}