Content for TS 33.310 Word version: 19.5.0

0… 5… 5.2… 5.2.4… 6.1.3c… 6.1a… 7… 8 9… 10… B… C… G… I… J…

J.1 Introduction J.2 Initial configuration J.3 Certificate enrolment and renewal J.4 Certificate revocation J.5 IANA registrations

J Certificate management for 5GC NFs using ACME |R19| p. 72

J.1 Introduction p. 72

This Annex describes the requirements to support ACME as an automated certificate management protocol for 5GC NFs. The NF acts as an ACME client and the operator CA/RA acts as an ACME server. The overall certificate management procedure follows RFC 8555. It consists of Initial configuration (clause J.2), Certificate enrolment and renewal (clause J.3), and Certificate revocation (clause J.4).

J.2 Initial configuration p. 72

J.2.1 NF instantiation and security assumptions p. 72

NF instantiation includes providing the NF with sufficient information for it to bootstrap its communication within the 5GC. It is assumed that the 5G NF has an authenticated channel to the OAM (e.g., established using an OAM-issued TLS client certificate or platform specific method) and is issued with the operator CA's root certificate, which is used to validate the ACME server's TLS certificate.

The communication between 5G NF and the operator CA is over HTTPS for authentication and confidentiality.

When a 5G NF fetches a resource from an ACME server, the server authenticates the requester and verifies any access control as described in RFC 8555. JWS based integrity protection is used as described in RFC 8555. Nonces are used to protect messages against replay-attacks as described in RFC 8555.

J.2.2 Account creation p. 72

In 5G SBA, it is recommended that the ACME account creation be authenticated and authorized. This prevents unauthorized entities from creating accounts and attempting to request certificates. Failure to do this could lead to resource exhaustion and an increased attack surface for obtaining mis-issued certificates.

The external account binding mechanism described in Section 7.3.4 of RFC 8555, allows the use of authorizations granted to the OAM for creating a new ACME account. The OAM acting as the external account verifier shares with the operator CA a symmetric MAC key bound to the ACME client and any other data which facilitates CA operation. This could include NF Instance ID, NF Type, or certificate profiles. The ACME server can use this data to validate a "newOrder" request as described in Section 7.4 of RFC 8555.

J.3 Certificate enrolment and renewal p. 72

J.3.1 Introduction p. 72

This clause describes the ACME certificate enrolment and renewal procedures for the 5GC SBA. The procedures are based on the ACME protocols specified in RFC 8555. The steps for certificate enrolment and renewal procedures have been grouped as follows: Certificate issuance (clause J.3.2) for order submission, and Challenge validation (clause J.3.3) for proving control of identifiers in the certificate, CSR, certificate download.

J.3.2 Certificate issuance p. 73

Certificate issuance as defined in RFC 8555 is used for certificate enrolment and renewal.

Pre-authorization is not used in ACME for 5G SBA, therefore:

The newAuthz resource is not supported.
The newOrder resource is used for all enrolment and renewal.

Clause 6.1.3c defines the certificate profiles for 5GC SBA. X.509 version 3 certificates are used for all entities in 5GC SBA. ACME supports X.509 version 3 certificates and the necessary extensions. Table J.3.2-1 lists the ACME challenge types, as described in Annex J clause J.3.3, used for each 5G SBA certificate profile.

Table J.3.2-1: ACME challenge types per 5G SBA certificate profile

5G SBA certificate type	ACME challenge type
TLS client	tkauth-01
TLS server	tkauth-01
OAuth 2.0 access token	tkauth-01
CCA token	tkauth-01

The policy-based certificate renewal can be used as described in the Annex I.2 of the present document.

J.3.3 Challenge validation p. 73

J.3.3.1 Introduction p. 73

The ACME challenge-type used for validation is the ACME Authority Token challenge type, "tkauth-01", as specified in RFC 9447. The validation method assumes a trust relationship between a CA and a Token Authority, i.e., that a CA is willing to accept the attestation of a Token Authority for particular types of identifiers as sufficient proof to issue a credential. When using ACME, the OAM system acts as a Token Authority that is trusted by the operator CA/RA. As such, the OAM is trusted to act as the authority for the NF Instance ID namespace within the 5GC.

J.3.3.2 "NfInstanceId" identifier type p. 73

A new ACME identifier type, "NfInstanceId", is defined in this clause. A NF uses its NF Instance ID as the value of the "NfInstanceId". The format of the value of the "NfInstanceId" is that of the NfInstanceId, as defined in TS 29.571:

NfInstanceId: string: String uniquely identifying a NF instance. The format of the NF Instance ID shall be a Universally Unique Identifier (UUID) version 4, as described in RFC 4122. The hexadecimal letters should be formatted as lower-case characters by the sender, and they shall be handled as case-insensitive by the receiver.
Example: "4ace9d34-2c69-4f99-92d5-a73a3fe8e23b"

An example of an ACME order object "identifiers" field containing a "NfInstanceId" is as follows:

"identifiers": [{"type":"NfInstanceId","value":"4ace9d34-2c69-4f99-92d5-a73a3fe8e23b"}]

In NF certificates, both client and server, the subjectAltName extension contains the NfInstanceId as a "uniformResourceIdentifier" formatted as a URN as described in clause 5.3.2 of TS 29.571. For example, "urn:uuid:4ace9d34-2c69-4f99-92d5-a73a3fe8e23b" is the string representation of the NF Instance ID "4ace9d34-2c69-4f99-92d5-a73a3fe8e23b" as a URN.

When processing a certificate order containing an identifier of type "NfInstanceId", a CA uses the Authority Token challenge type of "tkauth-01" with a "tkauth-type" of "atc", as defined in RFC 9447, to verify that the requesting ACME client has authenticated and authorized control over the requested resources represented by the "NfInstanceId" value as well as any other NF profile parameters included in the certificate order.

The NF's ACME client responds to the challenge by posting the Authority Token, as received from the OAM system, to the challenge URL identified in the returned ACME authorization object, an example of which follows:

POST /acme/chall/prV_B7yEyA4 HTTP/1.1
Host: boulder.example.com
Content-Type: application/jose+json
{
  "protected": base64url({
  "alg": "ES256",
  "kid": "https://example.com/acme/acct/evOfKhNU60wg",
  "nonce": "Q_s3MWoqT05TrdkM2MTDcw",
  "url": "https://boulder.example.com/acme/authz/asdf/0"
  }),
  "payload": base64url({
  "tkauth": "DGyRejmCefe7v4N...vb29HhjjLPSggwiE"
  }),
  "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ"
}

The "tkauth" field is, as defined in RFC 9448, a field in the challenge object specific to the tkauth-01 challenge type that contains an Authority Token as defined in the next clause.

J.3.3.3 NF Certificate Authority Token p. 74

A new Authority Token profile, NF Certificate Authority Token, is defined in this clause. The NF Certificate Authority Token is a profile instance of the ACME Authority Token defined in RFC 9447.

The NF Certificate Authority Token protected header meets the requirements for "Request Authentication", as specified in Section 6.2 of RFC 8555.

The NF Certificate Authority Token payload includes the mandatory claims "exp", "jti", and "atc":

"exp" claim, defined in Section 4.1.4 of RFC 7519, is included and contains the DateTime value of the date and time that the NF Certificate Authority Token expires.
"jti" claim, defined in Section 4.1.7 of RFC 7519, is included and contains a unique identifier for this NF Certificate Authority Token transaction.
"atc" claim, defined in RFC 9447, is included and contains a JSON object with the following mandatory elements:
- "tktype" key with a string value equal to "NfInstanceId" to identify this as a NF Instance ID claim.
- "tkvalue" key with a string value equal to value of the "NfInstanceId".
- "fingerprint" key constructed as defined in Section 8.1 of RFC 8555, corresponding to the computation of the "Thumbprint" step using the ACME account key credentials.

Additional elements for additional NF profile parameters can optionally be included, per RFC 9447 Section 4. These include the following:

"nftype" key with a string value equal to an NF Type as defined in RFC 9310,
"sans" key with value of an array of identifiers, as defined in clause 6.1.3c, to be included as SANs in addition to the NF Instance ID.

An example of the NF Certificate Authority Token is as follows:

{
  "protected": base64url({
    "typ":"JWT",
    "alg":"ES256",
    "x5u":"https://authority.example.org/cert"
  }),
  "payload": base64url({
    "exp":1640995200,
    "jti":"id6098364921",
    "atc":{"tktype":"NfInstanceId",
      "tkvalue":"4ace9d34-2c69-4f99-92d5-a73a3fe8e23b",
      "fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:
       D3:BA:B9:19:81:F8:50:9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3",
      "nftype" : "AMF",
      "sans" : ["amf1234.mcc.mnc.3ggp.org"]}
  }),
  "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ"
}

The Authority Token is acquired by the NF using a RESTful HTTP POST transaction within the NF's authenticated channel to the OAM as follows:

POST /at/account/:id/token HTTP/1.1
Host: authority.example.org
Content-Type: application/json

The request includes the account identifier as a string in the request parameter "id". This string is managed as an identifier specific to the Token Authority's relationship with an operator CA.

The body of the POST request contains a JSON object with key value pairs corresponding to values that are requested as the content of the claims in the issued token. An example is as follows:

{
   "tktype":"NfInstanceId",
   "tkvalue":"4ace9d34-2c69-4f99-92d5-a73a3fe8e23b",
   "fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3
     :BA:B9:19:81:F8:50:9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3",
   "nftype" : "AMF",
   "sans" : ["amf1234.mcc.mnc.3ggp.org"]}
}

If successful, the response to the POST request returns a 200 (OK) with a JSON body that contains, at a minimum, the NF Certificate Authority Token as a JSON object with a key of "token" and the base64url-encoded string representing the atc token. An example of a successful response is as follows:

HTTP/1.1 200 OK
Content-Type: application/json
{"token": "DGyRejmCefe7v4N...vb29HhjjLPSggwiE"}

If the request is not successful, the response indicates the error condition. Specifically, for the case that the account identifier provided does not exist, the response code 403 (Forbidden) is returned. Other 4xx and 5xx responses follow standard HTTP error condition conventions, as described in RFC 9110.

When creating the NF Certificate Authority Token, the Token Authority validates that the information contained in the token accurately represents the NF Instance ID and additional NF profile parameters the requesting party is authorized to represent based on their pre-established, verified, and secure relationship. Note that the fingerprint in the token request is not meant to be verified by the Token Authority but rather is meant to be signed as part of the token so that the party that requests the token can, as part of the challenge response, allow the ACME server to validate that the token requested and used came from the same party that controls the ACME client.

J.3.3.4 Validation of NF Certificate Authority Token p. 75

Upon receiving a response to the challenge, the operator CA's ACME server performs the following steps to determine the validity of the response.

Verify that the value of the "atc" claim is a well-formed JSON object containing the mandatory key values.
If there is an "x5u" parameter, verify the "x5u" parameter is an HTTPS URL with a reference to a certificate representing the trusted issuer of Authority Tokens for the ecosystem (i.e., the OAM system), as described in Section 4.1.5 of RFC 7515.
If there is an "x5c" parameter, verify the certificate array contains a certificate representing the trusted issuer of Authority Tokens for the ecosystem (i.e., the OAM system), as described in Section 4.1.6 of RFC 7515.
Verify the NF Certificate Authority Token signature using the public key of the certificate referenced by the token's "x5u" or "x5c" parameter.
Verify that an "atc" claim contains a "tktype" identifier with the value "NfInstanceId", a "tkvalue" identifier with an "NfInstanceId" value matching the identifier specified in the original challenge, a "fingerprint" that is valid and matches the account key of the client making the request, and optional elements corresponding to any addition NF profile parameters included in the certificate order (e.g., NF Type or SAN).
Verify that the remaining claims are valid (e.g., verify that token has not expired).

J.3.3.5 Use of JSON Web Signature p. 76

JSON Web Signature (JWS) objects, as defined in RFC 7515, can include an "x5u" header parameter to refer to a certificate that is used to validate the JWS signature. The URLs used in "x5u" are expected to provide the required certificate in response to a GET request, not a POST-as-GET, as required for the "certificate" URL in the ACME order object. This generally requires the ACME client to download the certificate and host it on a public URL to make it accessible to relying parties. Section 7 of RFC 9448, defines an optional mechanism for the certification authority (CA) to host the certificate directly and provide a URL that the ACME client owner can directly reference in the "x5u" of their signed NfInstanceId.

The following is an example of the use of "x5u" in the response when the certificate status is "valid".

HTTP/1.1 200 OK
Content-Type: application/json
Replay-Nonce: CGf81JWBsq8QyIgPCi9Q9X
Link: <https://example.com/acme/directory>;rel="index"
Location: https://example.com/acme/order/TOlocE8rfgo
{
  "status": "valid",
  "expires": "2024-05-20T14:09:07.99Z",
  "notBefore": "2024-05-01T00:00:00Z",
  "notAfter": "2024-05-08T00:00:00Z",
  "identifiers": [
    "type":"NfInstanceId",
    "value":"4ace9d34-2c69-4f99-92d5-a73a3fe8e23b"
  ],
  "authorizations": ["https://sti-ca.com/acme/authz/1234"],
  "finalize": "https://example.com/acme/order/TOlocE8rfgo/finalize",
  "certificate": "https://example.com/acme/cert/mAt3xBGaobw",
  "x5u": "https://example.com/cert-repo/giJI53km23.pem"
}

J.4 Certificate revocation p. 76

J.4.1 Introduction p. 76

The ACME protocol [72] supports an automated revocation of ACME enrolled and renewed certificates using established authenticated and authorized credentials (i.e., key pair) verified during ACME client account activation and certificate issuance. An end entity (e.g., ACME client in the NF) can use its account key pair or the key pair of the issued certificate to request revocation of its certificate by the CA (i.e., ACME server).

There are several practices associated with certificate revocation that are recommended.

This client-side certificate revocation procedure does not impact existing CA or OAM initiated revocation mechanisms, which are based on operator's implementation and outside the scope of this solution. The CA operator will continue to have the ability to revoke certificates that have been issued. In addition, production and distribution of certificate revocation status (i.e., via CRL or OCSP) is solely dependent on CA operator's implementation.
The ability to revoke certificates is limited to the original enrolling ACME client or if the ACME client has knowledge of the certificate private key.
When the ACME client is co-located with the NF in 5G SBA, the ACME client should not have privileges to request certificate revocation for other NFs.
The ACME client should maintain the valid account key pair for the NF Instance ID for which the certificate was issued and/or access to the key pair of the issued certificate being requested for revocation to properly sign the revocation request. Maintenance of the account key pair in a secure manner is left to implementation.
The certificate being requested for revocation should not have expired. Since expired certificates cannot be used, there is no justification to revoke expired certificates.
If the NF has been compromised and the ACME client is co-located, access to the ACME client may not be possible. In such instances, certificate revocation would use existing server-side operator's implementation.

J.4.2 ACME certificate revocation procedure p. 77

Prerequisites of the ACME certificate revocation procedure:

ACME client has been established per clause J.2.2 (Account creation)
Certificate has been enrolled or renewed by the CA (i.e., ACME server) and has not expired

The revocation request contains the certificate to be revoked and, optionally, the reason code for certificate revocation. Valid revocation reason codes are defined in CRLReason in RFC 5280.

To reduce potential impact of a DoS attack using compromised credentials, the CA should be configured to deny the ACME request for certificate revocation if the ACME client's credentials have been compromised or are believed to be compromised.

J.5 IANA registrations p. 77

J.5.1 New ACME Identifier Type p. 77

The present document defines a new ACME Identifier Type, "NfInstanceId", which is registered with the Internet Assigned Numbers Authority (IANA) as follows [77]:

Label: NfInstanceId
Reference: 3GPP TS 33.310

J.5.2 New ACME Validation Method p. 77

The present document defines a new ACME Validation Method, which is registered with the Internet Assigned Numbers Authority (IANA) as follows [77]:

Label: tkauth-01
Identifier Type: NfInstanceId
ACME: Y
Reference: 3GPP TS 33.310