Content for TS 33.310 Word version: 19.1.0

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

9.1 General 9.2 Architecture 9.3 Security Mechanisms 9.4 Certificate Profiles 9.4.1 General 9.4.2 Vendor Root CA Certificate 9.4.3 Vendor CA Certificate 9.4.4 Vendor Base Station Certificate 9.4.5 Operator Root CA Certificate 9.4.6 Operator RA/CA Certificate 9.4.7 Intermediate Operator CA Certificate 9.4.8 Operator Base Station Certificate 9.5 CMPv2 Profiling 9.5.1 General Requirements 9.5.2 Profile for the PKIMessage 9.5.3 Profile for the PKIHeader Field 9.5.4 Profile for the PKIBody Field 9.5.4.1 General 9.5.4.2 Initialization Request 9.5.4.3 Initialization Response 9.5.4.4 Key Update Request and Key Update Response 9.5.4.5 Certificate Confirm Request and Confirmation Response 9.6 CMPv2 transport
...

9 Certificate enrolment for base stations |R9| p. 41

9.1 General p. 41

The clause specifies certificate enrolment mechanisms for backhaul security. The decision on whether or not to apply the mechanisms is left to other 3GPP specifications.

9.2 Architecture p. 41

Figure 7 shows the general deployment architecture for certificate enrolment of a base station at an operator PKI.

Reproduction of 3GPP TS 33.310, Fig. 7: Overview of the security architecture

Figure 7: Overview of the security architecture

The base station is pre-provisioned with a public-private key pair by the vendor, and has the vendor-signed certificate of its public key pre-installed.

As RA/CA, an operator may deploy:

either a stand-alone CA implementing a CMPv2 server,
or, a CA having delegated certain tasks to an RA, which is in this case operating the CMPv2 server.

On initial contact to the operator network the base station establishes a communication channel to the RA/CA of the operator. Using CMPv2 [4] a request for a certificate is sent to the RA/CA. The network authenticates the messages from the base station based on the vendor-signed certificate of the base station and the vendor root certificate pre-installed in the network. The base station shall check the integrity protection on the messages from the RA/CA based on the operator root certificate provisioned in the base station. In a response message the base station receives the operator-signed certificate. During the execution of the CMPv2 protocol the base station has to successfully provide a Proof of Possession of the private key associated to the public key to be certified.

The operator root certificate may be provisioned in the base station prior to or during the CMPv2 protocol run. The protection of the operator root certificate during provisioning may be decided by operator security policy. If an operator root certificate provisioned prior to the CMPv2 protocol run is available the base station shall use it. Otherwise, the base station shall use the operator root certificate provisioned during the CMPv2 run. If no operator root certificate is provisioned at all then the base station shall abort the procedure.

After enrolment has been performed, the base station can use the operator-signed certificate to authenticate itself to the SEG of the operator, which is pre-installed with the operator root certificate. The base station then authenticates the SEG using the operator root certificate.

If at later stage of base station deployment the operator wants to renew the base station certificate, the same procedure will be executed with the old operator-signed certificate of the base station taking the place of the vendor-signed certificate in the initial enrolment.

9.3 Security Mechanisms p. 42

The enrolment of base stations shall use the CMPv2 protocol as specified in RFC 4210 and RFC 4211. The proof-of-possession methods as given by RFC 4210 and RFC 4211 shall be used.

The profiling of CMPv2 for the purpose of base station enrolment is given in subclause 9.5 of the present document.

9.4 Certificate Profiles p. 42

9.4.1 General p. 42

All certificates used during the enrolment process of base stations shall follow the requirements given in clause 6 of the present document. Profiling and exceptions are specified in the following subclauses.

9.4.2 Vendor Root CA Certificate p. 42

The root certificate of the vendor root CA shall follow the requirements given in subclause 6.1.2 for interconnection CA certificate profiles, with the following exceptions:

the vendor shall support distribution of certificate revocation information. The interface to provide revocation data is out of scope of the present document.

9.4.3 Vendor CA Certificate p. 42

If the vendor does not sign the base station certificate by its vendor root CA, the certificate of the CA signing the base station certificates and of any intermediate vendor CA shall follow the requirements given in subclause 6.1.4 for SEG CA certificate profiles, with the following exceptions:

the issuer name shall be the name of any vendor CA, given that the resulting chain of certificates starting with the base station certificates leads to the vendor root CA;
the path length shall be greater than 0 for the certificate of an intermediate CA not directly signing the vendor base station certificates;
the CRL distribution point extension in the certificate shall be optional;
the provisions on distribution of certificate revocation information given in subclause 9.4.2 shall apply.

9.4.4 Vendor Base Station Certificate p. 42

The base station certificate signed by a vendor CA shall follow the requirements given in subclause 6.1.3b for NE certificate profiles, with the following exceptions:

the issuer name is the name of the vendor CA signing the base station certificate;
the subject name shall be a globally unique fully qualified domain name (FQDN) given by the vendor. The exact definition of this FQDN is left to the vendor, given that the vendor ensures global uniqueness. The format of the subject name shall follow subclause 6.1.1 using the variant with an o attribute and a cn attribute, where the o attribute shall contain the vendor name, and the cn attribute shall contain the FQDN.
the subjectAltName with type dNSName shall contain the same FQDN as the subject field;

NOTE 1:
Availability of DNS is not required for the FQDN in the certificate.

NOTE 2:
An example for the vendor base station FQDN is <serialnumber>.<vendor>.com. Note that all labels comply with the requirements for labels in FQDNs (cf. RFC 1035). The representation in the subject field would be "o=<vendor name>, cn=<serialnumber>.<vendor>.com".
the provisions on the CRL distribution point extension in the certificate and on distribution of certificate revocation information given in subclause 9.4.3 shall apply.

9.4.5 Operator Root CA Certificate p. 43

The root certificate of the operator root CA shall follow the requirements given in subclause 6.1.2 for interconnection CA certificate profiles.

9.4.6 Operator RA/CA Certificate p. 43

If operating a standalone CA, the operator may deploy separate private keys for signing certificates and for signing the CMP messages or he may use one single private key for both purposes. In consequence the CA may have two or one certificate(s) being actively utilized in this transaction.

The operator may utilize a CA for signing certificates and delegate operation of the CMPv2 server to an RA. If RA and CA are different entities, the private keys as well as the subject names of the certificates used by the CA for signing base station certificates and by the RA for signing CMP messages are different.

The CA certificate used for signing certificates shall follow the requirements given in subclause 6.1.4 for SEG CA certificate profiles, with the following exception:

the issuer name shall be the name of any operator CA, given that the resulting chain of certificates starting with the CA certificate leads to the operator root CA.

The RA/CA certificate used for signing CMP messages shall follow the requirements given in subclause 6.1.3 for SEG certificate profiles, with the following exceptions:

the subject name shall be the same name as used in the "sender" field of the CMPv2 messages;
the issuer name shall be the name of any operator CA, given that the resulting chain of certificates starting with the RA/CA certificate leads to the operator root CA.

If the operator deploys one single private key for signing of the base station certificates and for signing of the CMP messages, for the single RA/CA certificate the same requirements as above for the CA certificate used for signing certificates apply with the following addition:

in addition to the key usage extensions specified in subclause 6.1.4, mandatory critical key usage extension bit digitalSignature shall be set.

9.4.7 Intermediate Operator CA Certificate p. 43

If the operator does not sign the RA/CA certificate by its operator root CA and if the RA/CA certificate(s) are not directly signed by the operator root CA, the certificate of any intermediate operator CA shall follow the requirements given in subclause 6.1.4 for SEG CA certificate profiles, with the following exceptions:

the issuer name shall be the name of any operator CA, given that the resulting chain of certificates starting with the RA/CA certificates leads to the operator root CA;
the path length shall be greater than 0.

9.4.8 Operator Base Station Certificate p. 43

The base station certificate signed by the operator RA/CA shall follow the requirements given in subclause 6.1.3b for NE certificate profiles.

Other documents may specify different base station certificate profiles according to their deployment scenario.

9.5 CMPv2 Profiling p. 44

9.5.1 General Requirements p. 44

The following requirements shall apply to CMPv2 usage end-to-end between base station and RA/CA:

This CMPv2 profile shall only include certificate request and key update functions. Revocation processing and PKCS#10 requests shall not be part of this CMPv2 profile.
For PKI Message Protection, this CMP profile shall only use an asymmetric algorithm. PasswordBasedMac is not used in the scope of the present document.
The base station shall be pre-provisioned with a private/public key pair (vendor key pair) and with the related vendor base station certificate signed by a vendor CA.
If there is a certificate chain from the base station certificate up to the vendor root CA, also the intermediate certificates shall be pre-provisioned to the base station.
The base station may be pre-provisioned with the operator root CA certificate.
If the base station is not pre-provisioned with the operator root CA certificate, then the base station shall take the operator root certificate from the certificates received in the initialization response. The selection shall be based on checking which root certificate can be used to validate the received base station certificate.

NOTE 1:
Certificate renewal for operator root certificates is not in scope of this clause on base station enrolment. Thus it is assumed that the base station always has a valid operator root certificate available for validation of key update responses.
The RA/CA shall authenticate initialization requests based on signatures which are validated against the vendor root CA.
The RA/CA shall authenticate key update requests based on signatures which are validated against the operator root CA.
The RA/CA shall be configured with the root certificate of the vendor and with the root certificate of the operator.
The RA/CA shall be configured with a RA/CA certificate which is signed either by the operator root CA or by an intermediate CA under the operator root CA.
If the RA/CA uses different private keys to sign the generated certificates and the CMPv2 messages, the RA/CA shall be configured with the two related certificates, i.e. the RA/CA certificate for signing signatures and the RA/CA certificate for signing CMP messages.
If the RA/CA certificate or certificates (two in case separate private keys are used for signing of certificates and CMP messages) are not signed directly by the operator root CA, also the certificates of the intermediate CAs shall be configured into the RA/CA.
The hash algorithms used before generating signatures in the protection field of PKIMessage and for proof-of-possession shall be the same as the hash algorithms specified in subclause 6.1.1 for certificate signatures. The signature algorithms shall be the same as that used in the related certificate profile.

The certificate profiles are specified in subclause 9.4.

9.5.2 Profile for the PKIMessage p. 45

The following profile shall be applied to the PKIMessage as specified in RFC 4210:

The support and usage of the optional protection field of type PKIProtection is required by this profile. The message-specific private key to be used in the base station is specified in the subclause 9.5.4 in the profiling of the single PKI message bodies for requests sent by the base station. For the RA/CA the RA/CA private key shall be used, or the separate RA/CA private key for signing CMP messages, if base station certificates and CMPv2 messages are signed by different private keys.
The support of the optional extraCerts field is required by this profile. The certificates within this field may be ordered in any order. The message-specific content of this field is specified in the subclause 9.5.4 in the profiling of the single PKI message bodies.
All CMPv2 messages used within this profile shall consist of exactly one PKIMessage, i.e. the size of the sequence for PKIMessages shall be 1 in all cases.

9.5.3 Profile for the PKIHeader Field p. 45

The following profile shall be applied to the PKIHeader field as specified in RFC 4210:

The sender and recipient fields shall contain the identities of the base station and the RA/CA. These identities shall be identical to the subject name present in the certificate for the public key whose related private key is used to sign the PKIMessage.

NOTE:
The subject name of RA/CA needs to be available before the CMPv2 run. The base station can obtain this subject name of RA/CA before the CMPv2 run via e.g., Initial IP Autoconfiguration procedure specified in TS 32.508 and TS 32.509.
As the field "protection" of PKIMessage is mandatory, also the field "protectionAlg" of PKIHeader is mandatory. The protectionAlg shall be of type MSG_SIG_ALG. The signature algorithm shall be based upon the algorithm contained in the algorithm field of the SubjectPublicKeyInfo field of the signer's certificate (belonging to the base station or the RA/CA). The hash algorithm used before signing the PKIMessage shall follow the same specification as given for usage before certificate signing in clause 6.1.1 of the present document.
The usage of the transactionID field is mandatory. The recommended procedures for handling of the transactionID given in [4] shall be followed. The base station shall set this field to a random number that is at least 8 bytes long for the first message and use the same random number in any subsequent message in the transaction.
The usage of the senderNonce and the recipNonce fields is mandatory. The length of the fields as recommended in [4] shall be used. The recipNonce in the very first message in the transaction should be set to 0 by the sender and shall be disregarded by the recipient of the message.

9.5.4 Profile for the PKIBody Field p. 45

9.5.4.1 General p. 45

The base station certificate enrolment shall support the following CMPv2 PKI message bodies:

Initialization Request (ir)
Initialization Response (ip)
Key Update Request (kur)
Key Update Response (kup)
Confirmation (pkiconf)
Certificate confirm (certconf)

Profiles for the single message bodies above are given in the subclauses below. If no specific profile is given, the provisions of RFC 4210 and RFC 4211 apply.

9.5.4.2 Initialization Request p. 46

The Initialization Request as specified in RFC 4210 shall contain exactly one CertReqMessages as specified in RFC 4210 and RFC 4211, i.e. the size of the sequence for CertReqMessages shall be 1 in all cases.

The following profile shall be applied to the CertReqMessage field and its sub-fields:

The subject field of the CertTemplate shall contain the suggested name of the base station if the base station has knowledge of it. Otherwise it shall be omitted.
The publicKey field of the CertTemplate shall be mandatory and shall contain the public key of the base station to be certified by the RA/CA. The private/public key pair may be pre-provisioned to the base station, or generated inside the base station for the CMPv2 protocol run. The format of this field shall follow RFC 5280.

NOTE 1:
RFC 3280 as referenced by RFC 4211 for the format of the publicKey field is obsolete. The present document generally references the follow-up RFC 5280.
The CertReqMessage shall contain a POP field of type ProofOfPossession. The POP field shall contain a signature field of type POPOSigningKey. The algorithmIdentifier field of the POPOSigningKey field shall contain the signing algorithm which is used by the base station to produce the Proof-of-Possession value, i.e. the signature within POPOSigningKey field.
If the poposkInput field of type POPOSigningKeyInput within POPOSigningKey field is used, the sender field within POPOSigningKeyInput shall be mandatory and shall contain the identity of the base station as given by the vendor of the base station and contained in the vendor-provided base station certificate.

NOTE 2:
According to RFC 4211, the poposkInput field is mandatory if either the subject field or the publicKey field of the CertTemplate field is omitted.

NOTE 3:
According to RFC 4211, the sender field of POPOSigningKeyInput is used only if an authenticated identity has been established by the sender. The present document assumes that the sender (i.e. base station) has a valid pre-provisioned vendor-signed certificate and therefore the sender's identity is considered authenticated and established.

The PKIMessage sent by the base station shall be signed by the vendor provided private key.

The extraCerts field of the PKIMessage carrying the initialization request shall be mandatory and shall contain the base station certificate provided by the vendor. If the base station certificate is not signed by the vendor root CA, also the intermediate certificates for the chain up to the vendor root certificate shall be included in the extraCerts field.

9.5.4.3 Initialization Response p. 46

The Initialization Response as specified in RFC 4210 shall contain exactly one generated base station certificate, i.e. the size of the sequence for CertResponse shall be 1 in all cases.

The following profile shall be applied to the CertRepMessage field and its sub-fields:

The generated certificate shall be transferred to the base station in the certifiedKeyPair field of the CertResponse field. The transfer shall not be encrypted (i.e. the certificate field in CertorEncCert shall be mandatory).

The extraCerts field of the PKIMessage carrying the initialization response shall be mandatory and shall contain the operator root certificate and the RA/CA certificate (or certificates if separate private keys are used for signing of certificates and CMP messages). If the RA/CA certificate(s) are not signed by the operator root CA, also the intermediate certificates for the chain(s) up to the operator root certificate shall be included in the extraCerts field. If additional (self-signed) Root CA certificates are required, they shall be carried in the extraCerts field or caPubs field of the PKIMessage. Since extraCerts field is not under CMP message integrity protection, CMP over TLS should be used as a security transport mechanism. Since CMP already supports integrity protection for caPubs field, the use of security transport mechanisms is optional.

9.5.4.4 Key Update Request and Key Update Response p. 47

The structure and content of these messages is identical to initialization requests and responses, thus the profiling given in the previous subclauses for Initialization Request and Initialization Response apply equally, with the following exceptions:

The PKIMessage sent by the base station shall be signed with the private key which is related to the last received operator provided base station certificate. The extraCertsField shall be mandatory and shall contain the base station certificate related to the private key used for signing the PKIMessage. Any intermediate CA certificates shall also be included, if the base station certificate is not signed directly by a root CA.
The PKIMessage carrying the key update response should not contain the operator root certificate in the extraCerts field.

9.5.4.5 Certificate Confirm Request and Confirmation Response p. 47

Initialization responses and key update responses shall always be followed by a Certificate Confirm request and Confirmation response message exchange.

The PKIMessage sent by the base station shall be signed by the same private key which was used in the preceding initialization request or key update request.

The extraCerts field of the PKIMessage carrying the Certificate Confirm request and Confirmation response shall be omitted.

9.6 CMPv2 transport p. 47

Transport of CMPv2 messages between end entities (network elements) and RA/CA shall be done using HTTP-based protocol as specified in RFC 6712 , with the exception that support for TLS is not mandated.

Support is mandatory for communication initiated by the end entities where every CMP request triggers a CMP response message from the CA or RA. Support for RA/CA initiated HTTP requests (i.e. announcements) is not mandatory.