]> Vigil Security, LLC

Herndon, VA US housley@vigilsec.com

sn3rd

Washington, DC US sean@sn3rd.com

Ericsson

Kista Sweden john.mattsson@ericsson.com

Ericsson

Saint Laurent, QC Canada daniel.migault@ericsson.com

Security Internet-Draft This document specifies the certificate extension for including Network Function Types (NFTypes) for the 5G System in X.509v3 public key certificates as profiled in RFC 5280.

Introduction The 3rd Generation Partnership Project (3GPP) has specified several Network Functions (NFs) as part of the service-based architecture within the 5G System. The 49 NF types that are defined for 3GPP Release 17 listed in Table 6.1.6.3.3-1 of , and each NF type is identified by a short ASCII string. Operators of 5G systems make use of an internal PKI to identify interface instances in the NFs in a 5G system. X.509v3 public key certificates are used, and the primary function of a certificate is to bind a public key to the identity of an entity that holds the corresponding private key, known as the certificate subject. The certificate subject and the subjectAltName certificate extension can be used to support identity-based access control decisions. This document specifies the NFTypes certificate extension, which provides a list of NF Types associated with the certificate subject. The NFTypes certificate extension can be used to support role-based access control decisions. The NFTypes certificate extension can be used by operators of 5G systems or later. The certificate extension supports many different forms of role-based access control in support of the diversity of activities that NFs are trusted to perform in the overall system. An NF activity might include the implementation of filtering policies. Another NF activity might provide an access controlled resource. Different levels of confidence that the NFTypes are proper assigned are needed in these two examples, yet both contribute to the overall security of the 5G system.

Terminology 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.

Certificate Subject Identification Several patterns for certificate subject names are provided in Section 6.1.1 of for the Network Domain Security (NDS) Authentication Framework (AF) for 3GPP Release 17. For example, the certificate subject name for an NF instance follows one of these patterns: ), o=, cn= cn=, (ou=), dc=, dc= ]]> When either pattern is used, the cn= portion is a DirectoryString; however, , limits the character set to either PrintableString or UTF8String. Note that the PrintableString has a much more limited set of characters that can be represented, and as a result, Section 6.1.1 of requires the o= and cn= portions of the subject name to use UTF8String. When the first pattern is used, the o= portion of the name contains the home domain as specified in Section 28.2 of to identify the public land mobile network, and it takes the following form: .mcc.3gppnetwork.org ]]> where MNC designates the Mobile Network Code, and MCC designates the Mobile Country Code. The certificates are expected to include the SubjectAltName certificate extension that contains a fully qualified domain name (FQDN), where the FQDN designates the NF as defined in Section 28.3.2.5 of . For example, the SubjectAltName certificate extension for an NF instance implementing the AMF might include these FQDNs: The certificates for entities that can act as TLS clients or servers are also expected to include a uniformResourceIdentifier in the SubjectAltName certificate extension that contains the NF Instance ID as specified in Clause 5.3.2 of . For example, the SubjectAltName certificate extension for an NF Instance ID might be: Following these patterns facilitates the use of the certificate subject and the subjectAltName certificate extension to support identity-based access control decisions. When the second pattern is used, the dc= portion of the name contains a single domain component. For example, hostname.example.net would appear in the certificate subject as:

Network Functions Certificate Extension This section specifies the NFTypes certificate extension, which provides a list of NF Types associated with the certificate subject. The NFTypes certificate extension MAY be included in public key certificates . The NFTypes extension MUST be identified by the following object identifier: This extension MUST NOT be marked critical. The NFTypes extension MUST have the following syntax: The NFTypes MUST contain only the ASCII strings. The NFTypes MUST contain at least one NFType. The NFTypes MUST NOT contain the same NFType more than once. Each NFType MUST contain at least one ASCII character, and each NFType MUST NOT contain more than 32 ASCII characters. The NFType is of type IA5String to permit inclusion of the character underscore character ('_'), which is not part of the PrintableString character set.

ASN.1 Module This section provides an ASN.1 module for the NFTypes certificate extension, and it follows the conventions established in and .

Security Considerations The Security Considerations of are applicable to this document. The ASCII strings that specify the NF Types are not standard; an operator MAY build its own NF Type. Since the NF Type is used for role-based access control decisions, the operator that specifies their own ASCII string for an NF Type MUST ensure that the new NF Type does not match an existing one. Use of the same ASCII string by two different operators for different roles could lead to confusion or incorrect access control decisions. The certificate extension supports many different forms of role-based access control in support of the diversity of activities that NFs are trusted to perform in the overall system. An NF activity might include the implementation of filtering policies. Another NF activity might provide an access controlled resource. Different levels of confidence that the NFTypes are proper assigned are needed in these two examples, yet both contribute to the overall security of the 5G system. As a result, different operators might have different trust models for NFTypes certificate extension.

Privacy Considerations In some security protocols, such as TLS 1.2 , certificates are exchanged in the clear. In other security protocols, such as TLS 1.3 , the certificates are encrypted. The inclusion of NFType certificate extension can help an observer determine which systems are of most interest based on the plaintext certificate transmission.

IANA Considerations For the NFType certificate extension in , IANA is requested to assign an object identifier (OID) for the certificate extension. The OID for the certificate extension should be allocated in the "SMI Security for PKIX Certificate Extension" registry (1.3.6.1.5.5.7.1). For the ASN.1 Module in , IANA is requested to assign an object identifier (OID) for the module identifier. The OID for the module should be allocated in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0).

Acknowledgements Many thanks to Ben Smeets and Michael Li for their review and comments.

References Normative References 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] ITU-T 3rd Generation Partnership Project 3rd Generation Partnership Project 3rd Generation Partnership Project 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. 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. Informative References This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative version. There are no bits- on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. 3rd Generation Partnership Project

Appendix A. NFType Strings Table 6.1.6.3.3-1 of defines the ASCII strings for the NF Types specified in 3GPP documents, which are listed below in alphabetical order. This list is not exhaustive.