Content for TS 33.401 Word version: 17.3.0

1… 4 5… 6… 6.2… 7… 7.2.5… 7.2.8 7.2.9… 7.3… 8… 9… 10… 11… 15… A… B… C… C.1.6 C.2… C.2.7 C.2.8 C.3… C.4.7 D… E… E.2… E.3… F… G… H… I… K…

D.1 Introduction D.2 Solution D.2.1 General D.2.2 Security Procedures D.2.3 USIM Binding Aspects D.2.4 Enrolment procedures for RNs D.2.5 Secure management procedures for RNs D.2.6 Certificate and subscription handling D.3 Secure channel profiles D.3.1 General D.3.2 APDU secure channel profile D.3.3 Key agreement based on certificate exchange D.3.4 Key agreement for pre-shared key (psk) case D.3.5 Identities used in key agreement
...

D (Normative) Security for Relay Node Architectures |R10| p. 127

D.1 Introduction p. 127

This Annex provides the security procedures applied to relay nodes. Security requirements and security features applied to relay nodes can be found in the main body of the present specification.

The overall stage 2 description for relay nodes can be found in TS 23.401 and TS 36.300.

The basic idea of the solution for relay node security presented in this Annex is realizing a one-to-one binding of an RN and a USIM called USIM-RN. Such a one-to-one binding is realized in this solution either by using symmetric pre-shared keys (psk) or by certificates. In the psk case, the binding needs to be pre-established in the UICC and in the RN prior to deployment; in the certificate case, the binding needs to be pre-established only in the UICC prior to deployment. The use of certificates has the advantage that there is a standardized procedure for enrolling the private key corresponding to the certificate in the secure environment of the RN while the use of a psk requires manual operation for establishing the psk. A further advantage is that the name (identity) in the certificate can be given at time of enrolment, and does not have to be pre-established. On the other hand, the use of a psk has the advantage that no PKI is required and the procedure after pre-establishment of the psk is simpler. When using certificates for this one-to-one binding, a part of the usual certificate handling is replaced by subscription handling, as explained in Annex D.2.6.

The certificate-based procedures are mandatory to support.

The pre-shared-key-based procedures are mandatory to support.

When using certificates the UICC inserted in the RN shall contain two USIMs: a USIM-RN which shall perform any communication only via a secure channel, and a USIM-INI communicating with the RN without secure channel and used for initial IP connectivity purposes prior to RN attachment. The UICC shall establish a secure channel only with a particular relay node, as detailed in the procedures described in Annex D.2.2. The UICC verifies this relay node by means of data pre-established in the UICC.

When using psk only the USIM-RN is required. This USIM-RN shall perform any communication only via a secure channel.

D.2.2 Security Procedures p. 127

The start-up of an RN shall proceed in the following steps, which are arranged in three phases. The Preparation Phase and Phase II procedures are the same for the certificate-based and the PSK-based case. Phase I procedures differ between the certificate-based case and the pre-shared key based case. If one of the steps fails in any of the involved entities the procedure shall be aborted by that entity, and the steps that follow the failed step shall not be executed (but the sending of failure messages is possible).

Preparation Phase:

The RN platform secure environment shall perform an integrity check of the RN platform. This shall include checking the integrity of the sensitive parts of the boot process and proceeding with the boot process only if the integrity checks of all these parts are successful.

Phase I: Procedures prior to the RN attach procedure (certificate-based case)

For the certificate-based case, the RN may skip Phase I attachment if the RN has an operator certificate available and a valid CRL list (if needed).

Ec1)

Void.

Ec2)

The RN shall attach as a UE using USIM-INI if step Ec3 needs to be performed.

Ec3)

The RN shall obtain an operator certificate through the enrolment procedure defined in TS 33.310 unless an operator certificate is already available. Details can be found in clause D.2.4. The RN may optionally establish a secure connection to an OAM server. Details can be found in clause D.2.5. The RN shall retrieve a CRL from a suitable server if no valid CRL is available locally in the RN and the RN supports and is configured to perform CRL checks. For revocation checking of UICC certificates see clause D.2.6. For the handling of CRLs for UICC certificates see also clause D.3.3.4.

Ec4)

After completing step Ec3, the RN shall detach from the network and de-activate the USIM-INI if it attached in step Ec2. If the UICC needs to be configured over the air (OTA) this may also be done in this step.

Ec5)

The RN platform secure environment and the UICC shall establish a Secure Channel between RN and USIM-RN according to ETSI TS 102 484 [29] clause 7 "Secured APDU" with TLS handshake. This TLS handshake shall be initiated by the RN and use certificates on both sides. The RN shall either use a pre-established certificate or the certificate enrolled in step Ec3. The UICC shall verify that this certificate belongs to the relay node the USIM-RN is bound to. The UICC shall be pre-provisioned with an operator root certificate to verify the RN certificate. The UICC certificate shall be pre-installed in the UICC by the operator. The RN shall be provisioned with a root certificate to verify the UICC certificate.

Ec6)

A certificate validation client on the UICC shall verify the signatures in the RN certificate chain up to the root certificate. The check of revocation status and expiry time shall be omitted. A certificate validation client on the RN shall check the verification of the signatures in the UICC certificate chain up to the root certificate as well as the expiry time. The revocation status of the UICC certificate should be checked by means of CRLs. Furthermore, the requirements in clause D.2.3 on 'USIM Binding Aspects' shall apply.

The private key corresponding to the RN certificate and the root certificate used to verify the UICC certificate shall be stored in the secure environment of the RN platform validated in the Preparation Phase, and the TLS connection as well as the secure channel with the UICC shall terminate there. From the completion of this step onwards, all communication between the USIM-RN and the RN shall be protected by the Secure Channel.

The USIM-RN shall not engage in any communication with any entity prior to the the completion of establishment of the Secure Channel according to steps Ec5 and Ec6 other than messages for establishing the Secure Channel according to ETSI TS 102 484 [29] clause 7 "Secured APDU".

NOTE 3:

ETSI TS 102 484 [29] states in clause 6.2.2: "The UICC may present a self-signed certificate. The terminal or terminal application should temporarily accept such a certificate during the TLS handshake protocol, if it is able to establish by other means (e.g. successful network authentication) that the handshake protocol is conducted with an authentic UICC." Similar considerations apply when the method in ETSI TS 102 484 [29] in clause 7 "Secured APDU" with TLS handshake is used as is the case in the present document. And in the present solution for relay node security, the RN indeed verifies the authenticity of the USIM-RN by means of a successful RN attach procedure. However, the use of a self-signed UICC certificate, or no UICC certificate at all, is not allowed here as this would weaken the protection against certain attacks, cf. clause D.2.6.

Phase I: Procedures prior to the RN attach procedure (pre-shared key based case)

For the psk-based case, there may be some cases when skipping of Phase I attachment is possible. Such cases are outside the scope of the present document.

Ep1)

Void.

Ep2)

The RN platform secure environment and the UICC shall establish a Secure Channel between RN and USIM-RN according to ETSI TS 102 484 [29] clause 7 "Secured APDU" using a pre-shared key. Furthermore, the requirements in clause D.2.3 on 'USIM Binding Aspects' shall apply.

The pre-shared key shall be stored in the secure environment of the RN platform validated in the Preparation Phase, and the secure channel with the UICC shall terminate there. From the completion of this step onwards, all communication between the USIM-RN and the RN shall be protected by the Secure Channel.

The USIM-RN shall not engage in any communication with any entity prior to the completion of the establishment of the Secure Channel according to step Ep2 other than messages for establishing the Secure Channel according to ETSI TS 102 484 [29] clause 7 "Secured APDU".

Ep3)

The RN may optionally establish a secure connection to an OAM server. Details can be found in clause D.2.5.

Ep4)

The RN shall detach from to the network if it attached for performing step Ep3.

Phase II: RN attach procedure (pre-shared key case and certificate-based case)

It is required that a secure channel between RN and USIM-RN exists throughout the execution of phase II.

The RN shall perform the RN attach procedure for EPS as defined in TS 36.300, using the USIM-RN. In addition, the following security-related steps shall be performed:

A1)

If the USIM-RN is not already active the RN shall activate it and shall establish a new secure channel according to Ec5, Ec6 in the certificate-based case and Ep2 in the pre-shared key based case respectively. The RN shall use the IMSI (or a related GUTI) pertaining to the USIM-RN in the RN attach procedure.

A2)

The S1 Initial UE message shall indicate that the attachment is for an RN. Upon receipt of this message the MME-RN shall run EPS AKA with the RN and the USIM-RN. The RN shall accept only authentication responses and keys in an RN attach procedure that were received from the USIM-RN over the Secure Channel.

A3)

The MME-RN shall check from the RN-specific subscription data received from the HSS that the USIM-RN is permitted for use in RN attach procedures. When this is not the case, but the S1 Initial UE message indicated that the attachment is for an RN, the MME-RN shall reject the Attach request and indicate to the DeNB that the set-up has failed.

A4)

The MME-RN and RN shall establish NAS security. Upon receipt of the S1 INITIAL CONTEXT SETUP message the DeNB and the RN shall set up AS security over Un as specified in the present document.

A5)

The RN may establish a secure connection to an OAM server in this phase to complete the configuration. Details can be found in clause D.2.5.

The RN start-up is now complete from a security point of view, and UEs can start attaching to the RN.

D.2.3 USIM Binding Aspects p. 130

There shall be a one-to-one association between the USIM-RN and the RN.

In the pre-shared key case, this one-to-one association is ensured by the fact that the key that is pre-shared between the USIM-RN and the RN shall not be available in any other entity.

In the certificate-based case, this one-to-one association is ensured by the following requirements:

The UICC shall verify the RN identity, represented by the RN identity in the certificate, through the TLS handshake as part of the secure channel set-up, and shall check whether it coincides with the locally stored identity of the RN authorized to set up a secure channel with the USIM-RN;
the identity in an RN certificate shall be unique;
a particular RN identity shall be available in only one UICC.

The procedures for managing the binding between USIM-RN and the RN are out of scope of the present document.

The UICC may know the identity of the RN authorized to set up a secure channel with the USIM-RN by configuration. The standard secure OTA mechanisms (TS 31.116) can be used to update the configuration of UICC and renew the stored identities if required.

D.2.4 Enrolment procedures for RNs p. 130

This clause applies only to the certificate-based case.

The RN may enroll a device certificate as with macro eNBs according to TS 33.310 prior to the RN attach procedure with the DeNB. This certificate may then be used for establishing the secure channel between RN and USIM-RN.

The certificate enrolment procedure does not rely on the security at the AS level, but is secured at the application layer. It can be therefore executed before security on the Un interface has been established. However, the RN requires IP connectivity for the enrolment procedure to be able to reach the Registration Authority RA.

The IP connectivity required for enrolment may be established in the following ways:

The RN may use offline means for enrolment purposes. No USIM is required.
The RN may attach to an eNB like a normal UE using a USIM, called USIM-INI, different from the one used in the RN attach procedure to the DeNB, called USIM-RN. No secure channel between RN and USIM-INI is required.

In both cases, the network shall ensure that the destinations the RN can reach are restricted to only the PDN(s) where the RA (Registration Authority for the certificate enrolment) and other servers to be contacted during phase I, e.g. the OAM server are located. In case (2) this shall be ensured by restricting IP traffic originating from the RN and sent only to certain destinations (APNs). The restrictions are assumed to be part of the profile relating to the subscription associated with the USIM-INI.

D.2.5 Secure management procedures for RNs p. 131

The requirements on communication between the OAM systems and the eNB from clause 5.3.2 shall apply for relay nodes in both phases I and II. The mechanisms used to fulfil these requirements shall include applying security association(s) that extend between the RN and an entity in the Evolved Packet Core (EPC) or in an OAM domain trusted by the operator.

If IKEv2/IPsec or TLS with authentication based on certificates is used for the security association(s), the protocol profiles for IPsec in TS 33.210 and for IKEv2 and TLS in TS 33.310 and the certificate profiles given in TS 33.310 should be followed.

The RN requires IP connectivity for the management procedure to be able to reach the OAM server.

For the pre-shared key case in Phase I, IP connectivity can be established after step Ep2 with the RN attaching to an eNB like a normal UE using the USIM-RN.

For the certificate-based case in Phase I, IP connectivity established for enrolment purposes according to clause D.2.4 may be re-used, or, if not available, it may be established in the same ways as described in clause D.2.4.

Restrictions on the destinations the RN can reach shall apply if the communication with the OAM server prior to the RN attach procedure is based on USIM-INI. They shall be realized in the same way as described in clause D.2.4.

D.2.6 Certificate and subscription handling p. 131

Whenever the operator intends to prevent the RN from attaching to the network the operator shall bar the subscription relating to the USIM-RN in the HSS.

In the certificate-based case the barring of the subscription relating to the USIM-RN shall be performed also whenever the RN certificate has to be revoked, or whenever the UICC certificate has to be revoked and the RN is not configured to always check the UICC certificate against a CRL, cf. below.

In the pre-shared key case, the barring of the subscription relating to the USIM-RN may be performed also whenever the operator sees a risk that the pre-shared key between the USIM-RN and RN has been compromised.

NOTE 0:

In the certificate-based case, checking the UICC certificate against a CRL and barring the subscription relating to the USIM-RN are not equivalent. The former could prevent the following attack while the latter could not: an attacker in possession of a compromised private key relating to the UICC certificate could get stolen RNs to work in his own network as then the attacker could use a fake UICC, with subscription data generated by himself, towards the RN to set up a secure channel. Subscription barring would not be effective in the attacker's network while the CRL check by the RN would ensure that the RN cannot attach as an RN to a network other than the one of the operator who provisioned the root certificate in the RN. If the operator deems the risk of such an attack low he may configure his RNs to not use CRL checks against UICC certificates.

The remainder of this clause applies only to the certificate-based case.

As described in clause D.2.2, step Ec6, the certificate validation client on the UICC verifies the signatures in the RN certificate chain up to the root certificate, but omits the check of revocation status and expiry time. To achieve the same effect as checking RN certificate's revocation status and expiry time, the associated USIM-RN subscription shall be barred in the HSS. This process is called 'invalidation' in this document and is explained further below.

A certificate validation client on the RN shall check the verification of the signatures in the UICC certificate chain up to the root certificate as well as the expiry time. The revocation status of the UICC certificate should be checked by means of the CRL obtained by the RN in clause D.2.2, step Ec3. The CRL check is optional to support by the RN.

Further considerations on RN certificate and USIM-RN subscription handling:

By using the one-to-one binding of RN and USIM-RN, a part of the usual certificate handling is replaced by subscription handling, as explained below:

Binding in network:

The one-to-one binding of RN and USIM-RN shall be expressed by a one-to-one mapping of the RN identity in any certificate issued to the RN and the IMSI in the USIM-RN. The operator shall maintain a table with this mapping (the "mapping table").

Binding in UICC:

cf. clause D.2.3.

Lifetime:

The subscription shall have a limit on its lifetime. When the lifetime of the subscription is exceeded the subscription shall be barred in the HSS. The lifetime shall not be greater than the lifetime of the RN certificate. The latter is not checked in the UICC, cf. clause D.2.2.

RN Certificate revocation and invalidation:

Whenever the operator decides that the RN certificate shall no longer be used for setting up a secure channel with the USIM-RN the operator does not use CRLs or OCSP, but shall retrieve the IMSI associated with the subject name in the RN certificate and bar the subscription corresponding to the IMSI in the HSS. The certificate shall also be revoked, but the operator does not need to use CRLs or OCSP in this context. This implies that no new certificate shall be issued for the same RN identity from that point onwards. In case the RN certificate is also used for other purposes, e.g. for protecting an OAM connection, then, additionally, the usual PKI revocation procedures apply.

RN compromise:

If the operator has reason to believe that an RN has been compromised the RN certificate shall be invalidated and revoked as described above.

RN Certificate renewal: This process may be used as normal as long as the RN identity in the RN certificate remains the same.

RN Certificate expiry:

D.3 Secure channel profiles p. 133

D.3.1 General p. 133

The clause D.3 profiles the algorithms to be used on the APDU secure channel, cf. ETSI TS 102 484 [29]. In addition it specifies the profiles for the different key agreement methods.

For the case when certificates are used for key agreement, the profiles are given for the TLS handshake used to provide key material for the Master SA of the secure channel between USIM-RN and RN, and for the certificates used in UICC and RN for mutual authentication during TLS handshake. For the psk case requirements on the key agreement with pre-shared keys are given.

D.3.2 APDU secure channel profile p. 133

For communication between the USIM-RN and the RN a secure channel according to the APDU secure channel as specified in ETSI TS 102 484 [29] shall be used. Further detailing of the secure channel is given in TS 31.102.

For encryption, AES-CBC as specified in ETSI TS 102 484 [29] shall be mandatory to support. Other encryption algorithms specified in ETSI TS 102 484 [29] may be supported. The algorithm "3DES - outer CBC using 2 keys" shall not be used.

For integrity protection, AES-CMAC as specified in ETSI TS 102 484 [29] shall be mandatory to support. Other integrity protection algorithms specified in ETSI TS 102 484 [29] shall not be used.

D.3.3 Key agreement based on certificate exchange p. 133

D.3.3.1 TLS profile p. 133

The key agreement for the certificate exchange case shall follow the mechanism "Certificate exchange" as specified in ETSI TS 102 484 [29].

During key agreement based on certificate exchange a TLS handshake is used to provide key material for the Master SA of the APDU secure channel between USIM-RN and RN.

The TLS profile shall follow the profile given in Annex E of TS 33.310 with the following restrictions and extensions:

the support of the ciphersuite mandatory for TLS 1.1 as described in TS 33.310 is not required;
the support of fallback to TLS 1.0 as described in TS 33.310 is not required;
neither UICC nor RN shall use TLS session resumption.

D.3.3.2 Common profile for RN and UICC certificate p. 133

The certificate profile for both RN and UICC certificates shall follow the TLS entity certificate profile given in clause 6.1.3a of TS 33.310 with the following restrictions and extensions:

the support of the SHA-1 algorithm for use before signing the certificate as described in TS 33.310 [6] is not required;
the support of public key length of 1024-bit is not required;
only the subject name format with "(C=<country>), O=<Organization Name>, CN=<Some distinguishing name>" is mandatory to support.

D.3.3.3 RN certificate profile p. 134

The RN certificate is used as client certificate in the TLS handshake between RN and UICC.

The certificate profile for the RN certificate shall follow clause D.3.3.2 of the present document with the following restrictions and extensions:

the subject name shall be unique within all subject names issued by CAs under the same root CA;
the subject name may additionally contain the attribute "serialNumber=<serial number>";
the support of the countryName (C) and serialNumber attributes in the subject name is mandatory;

NOTE 1:
The usage of the countryName (C) and serialNumber attributes can support the operator in generating a unique identity for an RN.
the CRL distribution point is not used if the RN certificate is only used in the setup of the secure channel with the UICC. Therefore the CRL distribution point is optional in this case.

NOTE 2:
It may be desired to deploy the same RN certificate also for RN platform authentication to other network elements of the operator, e.g. if TLS with mutual authentication is used for an OAM connection. The profile given above is intended to allow such usage. Regarding the implementation of certificate handling in the UICC it should be noted that for this additional usage of the RN certificate the existence of additional fields in the certificate is possible, e.g. of the subjectAltName and/or the CRL distribution point, which are not relevant for the secure channel between RN and UICC.

D.3.3.4 UICC certificate profile p. 134

The UICC certificate is used as server certificate in the TLS handshake between RN and UICC.

The certificate profile for the UICC certificate shall follow clause D.3.3.2 of the present document with the following additional provisions:

the CRL distribution point in the UICC certificate is optional.

D.3.4 Key agreement for pre-shared key (psk) case p. 134

The key agreement for the psk case shall follow the mechanism "Strong Pre-shared Keys - Proprietary Pre-agreed keys" as specified in ETSI TS 102 484 [29]. The pre-shared key shall be used directly to derive a Master secret for the Master SA.

D.3.5 Identities used in key agreement p. 135

The key agreement mechanisms specified in ETSI TS 102 484 [29] produce a value Ks_Local_Ref, which is a reference to Ks_local. It is transferred from the RN to the UICC during the Master SA setup and is used as input to the derivation of the 256 bit Master secret (MS) of the Master SA in the certificate exchange case.

Ks_Local_Ref is specified in ETSI TS 102 484 [29] as the concatenation of identities as follows:

Ks_Local_Ref = Terminal_ID || Terminal_appli_ID || UICC_ID || UICC_appli_ID.

The identities used in the scope of the present document for Ks_Local_Ref are specified as follows:

UICC_ID: This unique identifier for the UICC shall be the ICCID for the UICC as specified in ETSI TS 102 221 [32].

NOTE:
The UICC_ID may be read by the RN from the UICC before establishment of the secure channel.
UICC_appli_ID: This unique identifier for the UICC application that hosts the UICC endpoint shall be the USIM-RN AID as specified in TS 31.102.
Terminal_ID: This unique identifier for the RN shall be the subject name of the RN certificate as specified in clause D.3.3.3. In the psk case, where no certificate is used, the same definition as for the certificate exchange case shall apply.
Terminal_appli_ID: This unique identifier for the application that hosts the RN side endpoint shall be set to the UTF-8 encoded string "Relay_Node_appli".