B.6 NAF specific key derivation in GBA_Digest

33.2203GPPGeneric Authentication Architecture (GAA)Generic Bootstrapping Architecture (GBA)TS

In GBA_Digest, the input parameters for the key derivation function to derive Ks_NAF shall be the following:

– FC = 0x01;

– P0 = "gba-digest" (i.e. 0x67 0x62 0x61 0x2d 0x64 0x69 0x67 0x65 0x73 0x74);

– L0 = length of P0 is 10 octets (i.e., 0x00 0x0a);

– P1 = nonce;

– L1 = length of nonce is variable (not greater than 65535);

– P2 = IMPI encoded to an octet string using UTF-8 encoding (see clause B.2.1 of the present document);

– L2 = length of IMPI is variable (not greater than 65535);

– P3 = NAF_ID with the FQDN part of the NAF_ID encoded to an octet string using UTF-8 encoding (see clause B.2.1 of the present document;

– L3 = length of NAF_ID is variable (not greater that 65535).

The Key to be used in key derivation shall be:

– Ks as specified in clause B.5 of the present document.

NOTE: In clause M.6.3 this function is denoted as:
Ks_NAF = KDF (Ks, "gba-digest", nonce, IMPI, NAF_Id).

Annex C (informative):
(Void)

Annex D (informative):
Dialog example for user selection of UICC application used in GBA

For certain cases, clause 4.4.8 specifies user involvement in the selection of the UICC application used for GBA procedures. A dialog window example for such an involvement is described below:

– The title of the dialog: "Authentication request".

– Explanation: "A service requires you to authenticate, please select your identity:"

– List of identities: A selectable list of applications on the UICC. The text visible for each application is extracted from the "Label" field of the application list on the UICC.

– Buttons: "Select" and "Cancel".

Annex E (normative):
TLS profile for securing Zn/Zn’ reference points

This Annex applies for the Zn’ reference point when using DIAMETER or HTTP, and applies for the Zn reference point if using HTTP.

The TLS profile is specified in TS 33.310 [19], Annex E and shall apply. The TLS endpoints shall mutually authenticate using certificates as part of TLS session establishment.

NOTE: Void.

The TLS certificates shall follow the requirements in clause 6.1 of TS 33.310 [19] for TLS certificates, with the exceptions as given in the following.

The Zn-Proxy certificate, i.e. the client certificate used in TLS handshake, shall contain the subjectAltName extension with one or more dNSName names. The dNSName name may contain the wildcard character ‘*’ and the matching is performed as specified in RFC 2818 [18] section 3.1.

The Zn-Proxy certificate shall contain all the DNS names of NAFs that may send a request for NAF specific shared secret through the Zn-Proxy to the subscriber’s home BSF. If a new NAF is added, the new DNS name is either covered in the certificate by using the wildcard character approach (e.g. "*.operator.com"), or a new dNSName name needs to be added to the certificate. In the latter case, new certificate is needed for the Zn-Proxy.

Annex F (informative):
Handling of TLS certificates

An authentication framework for TLS is available [19].

Annex G (normative):
GBA_U UICC-ME interface

This annex describes the UICC-ME interface to be used when a GBA_U aware UICC application is active and the ME is involved in a GBA bootstrapping procedure. When the UICC application is not GBA_U aware, the ME uses AUTHENTICATE command in non-GBA_U security context (i.e. UMTS security context in case of USIM application and IMS security context in case of the ISIM) as defined in TS 31.102 [1] and TS 31.103 [10].