X.509 Certificate Extended Key Usage (EKU) for 5G Network Functions
Extracted elements (17)
Although vendor-defined KeyPurposeIds can be safely ignored when unrecognized (as non-critical extensions), using them outside their intended vendor-controlled environment causes interoperability issues. Standard KeyPurposeIds are defined here to ensure interoperability across implementations and are intentionally scoped broadly enough for use beyond 5G deployments.
Existing RFC 5280 KeyPurposeIds (id-kp-serverAuth, id-kp-clientAuth) cover server and client authentication for 5G NFs, but no standard KeyPurposeIds existed for JWT signing, HTTP JSON object encryption (JWE), or OAuth 2.0 access token signing. This gap necessitated defining new purpose-specific identifiers rather than relying on anyExtendedKeyUsage.
Without specific EKU constraints, a Network Function that generates keys and requests a certificate could obtain one misusable for tasks it is not entitled to perform. For example, a NF service consumer could use a client certificate to impersonate NF service producers or sign Client Credentials Assertions, violating the principle of segregation of duties.
The id-kp-jwt KeyPurposeId covers both JWS signature validation and JWE decryption contexts for JWT; the distinction between the two is determined solely by the Key Usage (KU) extension value — digitalSignature/nonRepudiation for JWS, keyEncipherment for JWE — not by separate KeyPurposeIds.
The NF-EKU ASN.1 module (id-mod-nf-eku, OID arc 1.3.6.1.5.5.7.0 decimal 108) is defined using IMPLICIT TAGS and follows ITU-T X.680 and X.690 (BER/CER/DER encoding rules). Implementers must use this module to ensure consistent OID assignment and encoding across 5G NF certificate implementations.
If the certificate requester knows the certificate users are mandated to use these KeyPurposeIds, it MUST enforce their inclusion in the certificate request and MUST ensure that the KeyUsage extension is set to digitalSignature or nonRepudiation for signature operations and/or keyEncipherment for secret key encryption.
If the EKU extension is present in a certificate, then the certificate MUST only be used for one of the purposes indicated, as specified in RFC 5280. If multiple key purposes are indicated, the application need not recognize all purposes as long as the intended purpose is present.
Network Functions that verify the signature of a CCA (JWT), decrypt JSON objects in HTTP messages using JWE, or verify OAuth 2.0 access token signatures SHOULD require that the corresponding KeyPurposeIds (id-kp-jwt, id-kp-httpContentEncrypt, id-kp-oauthAccessTokenSigning) be specified in the EKU extension of the presented certificate.
The procedures and practices employed by a Certification Authority MUST ensure that the correct values for the EKU extension as well as the KU extension are inserted in each certificate that is issued. Inclusion of the new KeyPurposeIds does not preclude inclusion of other KeyPurposeIds.
The inclusion of the EKU extension can reveal the purpose of a certificate to observers. In protocols like TLS 1.2 where certificates are exchanged in the clear, or via Certificate Transparency logs for publicly issued certificates, an attacker can monitor logs to identify what function a certificate is serving within a 5G system.
id-kp-httpContentEncrypt (OID 1.3.6.1.5.5.7.3.38) is a new KeyPurposeId indicating the certificate's public key is certified for encrypting JSON objects in HTTP messages (e.g., encrypting the CEK using RSAES-OAEP to produce the JWE Encrypted Key between SEPPs). The KU extension must be set to keyEncipherment.
id-kp-jwt (OID 1.3.6.1.5.5.7.3.37) is a new KeyPurposeId for use in the EKU extension of X.509 v3 certificates, indicating the certificate's public key is certified for validating the JWS Signature in a JWT (e.g., Client Credentials Assertion in 5G). The KU extension must be set to digitalSignature or nonRepudiation.
id-kp-oauthAccessTokenSigning (OID 1.3.6.1.5.5.7.3.39) is a new KeyPurposeId indicating the certificate's public key is certified for signing OAuth 2.0 access tokens for service authorization using JWS. The KU extension must be set to digitalSignature or nonRepudiation.
IANA registered the ASN.1 module OID id-mod-nf-eku (decimal 108) in the 'SMI Security for PKIX Module Identifier' registry (arc 1.3.6.1.5.5.7.0), referencing RFC 9509.
IANA registered three new OIDs in the 'SMI Security for PKIX Extended Key Purpose' registry (arc 1.3.6.1.5.5.7.3): decimal 37 = id-kp-jwt, decimal 38 = id-kp-httpContentEncrypt, decimal 39 = id-kp-oauthAccessTokenSigning, all referencing RFC 9509.
The new EKU KeyPurposeIds reduce existing security risks by providing a means to identify whether a certificate is intended for JWT Claims Set signing, OAuth 2.0 access token signing, or JWE content-encryption key encryption, thereby mitigating cross-protocol attacks that arise when certificate purpose is not restricted.
To further reduce cross-protocol attack risk, relying parties MAY prohibit specific combinations of KeyPurposeIds using the Excluded KeyPurposeId and Permitted KeyPurposeId mechanism defined in RFC 9336. Examples of excluded identifiers include anyExtendedKeyUsage or a certificate with no EKU extension at all.