4 GBA Bootstrapping Zh interface and Zh’ interface

29.1093GPPGeneric Authentication Architecture (GAA)Release 17Stage 3TSZh and Zn Interfaces based on the Diameter protocol

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

4.1 Generic bootstrapping network architecture

The network architecture of the Diameter based implementation for Bootstrapping procedure is presented in Figure 4.1-1. The interface Ub (bootstrapping) is defined in 3GPP TS 24.109 [7] and the interface Zh in this specification.

Figure 4.1-1: Network architecture of bootstrapping procedure

The generic boostrapping network architecture for Bootstrapping Push procedures is presented in Figure 4.1-2. The interface Zpn is also defined in this specification.

Figure 4.1-2: Network architecture of bootstrapping push procedure

The protocol stack of the Zh interface in Bootstrapping procedure is presented in Figure 4.2. The Diameter Base protocol is defined in IETF RFC 6733 [33] and the Diameter application in 3GPP TS 29.229 [3]. The requirements for Zh interface are defined in 3GPP TS 33.220 [5] and 3GPP TS 33.223 [23].

Figure 4.2: Protocol stack of Zh interface

The MAP based Bootstrapping Zh’ interface is defined in the section 4.3.

4.2 Protocol Zh between BSF and HSS

The requirements for Zh interface are defined in 3GPP TS 33.220 [5] and 3GPP TS 33.223 [23].

The Bootstrapping Zh interface performs the retrieval of an authentication vector and possibly GBA User Security Settings from the HSS.

The overall Bootstrapping procedure is depicted in Figure 4.3. The basic procedure is:

A) A UE starts the bootstrapping procedure by protocol Ub with a BSF giving the IMPI of the user (see 3GPP TS 24.109 [7]).

B) The BSF starts protocol Zh with user’s HSS

– The BSF requests user’s authentication vector and GBA User Security Settings (GUSS) corresponding to the IMPI. If the authentication scheme is to use SIP Digest credentials, the BSF shall indicate this in the request.

– The HSS supplies to the BSF the requested authentication vector and GUSS (if applicable, cf. 3GPP TS 33.220 [5]). The HSS supplies the requested authentication vector relating to SIP Digest only if explicitely indicated in the request.

NOTE 1: If there is more than one HSS deployed within the network, the BSF may have to contact the SLF using the Dz interface prior to sending the request for information to the HSS (see section 6.4).

C) The BSF continues the protocol Ub with the UE (see 3GPP TS 24.109 [7]).

Figure 4.3: The GBA bootstrapping procedure

The overall Bootstrapping Push procedure is depicted in Figure 4.4. The Push procedure shall not apply with an authentication scheme using SIP Digest credentials. The Push procedure is:

A) A NAF sends a bootstrapping push request to the BSF via Zpn interface including the IMPI or IMPU of the user (see section 5).

B) The BSF starts protocol Zh with user’s HSS

– The BSF requests user’s authentication vector and GBA User Security Settings (GUSS) corresponding to the IMPI or IMPU.

– The HSS supplies to the BSF the requested authentication vector and GUSS (if any).

NOTE 2: If there is more than one HSS deployed within the network, the BSF may have to contact the SLF using the Dz interface prior to sending the request for information to the HSS (see section 6.4).

C) The BSF continues the protocol Zpn with the NAF (see section 5).

D) The NAF starts protocol Upa with the UE, as specified in 3GPP TS 24.109 [7].

Figure 4.4: The GBA bootstrapping Push procedure

The steps of the bootstrapping procedure over Zh reference point in Figure 4.3 and Figure 4.4 are:

Step 1

The BSF shall send the following Bootstrapping-Request to the HSS in the format of Multimedia-Auth-Request (MAR) message. The content of the message is given below in the same format as in 3GPP TS 29.229 [3]. The curly brackets indicate mandatory AVPs. The square brackets indicate optional AVPs. The "address of" refers to the Fully Qualified Host Name (FQDN).

<Multimedia-Auth-Request> ::=<Diameter Header: 303, REQ, PXY, 16777221 >
< Session-Id >
{ Vendor-Specific-Application-Id }
{ Auth-Session-State } ; NO_STATE_MAINTAINED
{ Origin-Host } ; Address of BSF
{ Origin-Realm } ; Realm of BSF
{ Destination-Realm } ; Realm of HSS
[ Destination-Host ] ; Address of the HSS
[ User-Name ] ; IMPI from UE

[ Public-Identity ] ; IMPU from UE

[ SIP-Auth-Data-Item ] ; Authentication Scheme,

Synchronization Failure

[ GUSS-Timestamp ] ; Timestamp of GUSS in BSF
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]

The content of mandatory Vendor-Specific-Application-ID according IETF RFC 6733 [33] is:

<Vendor-Specific-Application-Id>::=<AVP header: 260>
1* [Vendor-Id] ; 3GPP is 10415
0*1 {Auth-Application-Id} ; 16777221
0*1 {Acct-Application-Id} ; Omitted

When determining the value of Destination-Host AVP the BSF can use redirector function (SLF) to resolve the address of the HSS if needed (see 3GPP TS 29.229 [3]). The BSF shall set the Auth-Session-State AVP to NO_STATE_MAINTAINED to inform that the HSS does not need to maintain any status information for this session according 3GPP TS 29.229 [3].

The User-name is the IMS Private User Identity (IMPI) as defined in 3GPP TS 29.228 [2]. In bootstrapping push procedures, either the Public-Identity AVP or the User-Name AVP shall be present in the request, depending on the user identity provided by the NAF. For all other bootstrapping procedures, only the User-Name AVP shall be present. If the identity received from the NAF is an MSISDN, the BSF shall include this MSISDN in the form of a tel URI in the Public-Identity AVP (see 3GPP TS 29.229 [2]).

If the BSF supports the GUSS timestamp mechanism and has local copy of the GUSS, which has a timestamp, the BSF may include the GUSS-Timestamp AVP. In this case the GUSS-Timestamp AVP shall contain the timestamp from subscriber’s GUSS. Otherwise the GUSS-Timestamp AVP shall not be present.

The SIP-Auth-Data-Item AVP, when present, shall indicate the authentication scheme chosen, i.e SIP Digest when applicable. By default, when the SIP-Auth-Data-Item AVP is not present, the authentication scheme is Digest-AKAv1-MD5. The SIP-Auth-Data-Item AVP should not be present to indicate the authentication scheme is Digest-AKAv1-MD5.

NOTE 3: A pre-Rel-11 HSS only received SIP-Auth-Data-Item AVP in Zh MAR in case of synchronization failure for IMS-AKA. Apart from that, when SIP-Auth-Data-Item AVP was not present, it implied that the authentication scheme was Digest-AKAv1-MD5. Therefore, if SIP-Auth-Data-Item AVP is not present, it means that the authentication scheme is Digest-AKAv1-MD5, like before Rel-11. Moreover, in order to avoid interoperability problems between a pre-Rel-11 HSS and a Rel-11 (or later) BSF, the BSF should not include the SIP-Auth-Data-Item AVP to indicate the authentication scheme is Digest-AKAv1-MD5.

If the Authentication Request is triggered by a synchronization failure (see 3GPP TS 24.109 [7]), the BSF shall include the SIP-Auth-Data-Item AVP within the MAR message according to 3GPP TS 29.228 [2].

Step 2

When the HSS receives the MAR message, the HSS shall derive the user Authentication Vector (AV) information according the IMPI and, if present, the authentication scheme and populates it into SIP-Auth-Data-Item AVP as defined for IMS-AKA or SIP Digest authentication schemes in 3GPP TS 29.229 [3]. Only one AV shall be provided.

If the Public User Identity is received, the HSS shall resolve to the corresponding IMPI/IMSI associated to such IMPU/ MSISDN before deriving the AV information. If Public to Private identity resolution is not possible i.e. due to the IMPU is shared with multiple IMPIs, the HSS shall set the Experimental-Result-Code to DIAMETER_ERROR_OPERATION_NOT_ALLOWED (see 3GPP TS 29.329 [32]).

If the request indicates that there is a synchronization failure, the HSS shall process AUTS as described in 3GPP TS 33.203 [31] and return the requested authentication information. The Result-Code shall be set to DIAMETER_SUCCESS.

If GUSS exists for the IMPI, the HSS shall do one of the following:

1) If the HSS supports the GUSS timestamp mechanism and received the GUSS-Timestamp AVP in MAR message then it shall compare the timestamp of the GUSS in the HSS with the received timestamp.

– If timestamps are equal, then it shall populate the GBA-UserSecSettings AVP with static string "GUSS TIMESTAMP EQUAL".

– If the GUSS-Timestamp AVP was not received, or timestamps are not equal, then it shall populate the GBA-UserSecSettings AVP with the GUSS.

2. If the HSS does not support GUSS timestamp mechanism, it shall populate the GBA-UserSecSettings AVP with the GUSS.

The MAR/MAA sequence in the Zh interface must not change possible status information of the possible simultaneously ongoing IMS MM application sessions in the HSS.

If the User-Name (IMPI) or Public-Identity (IMPU) from the BSF is totally unknown to the HSS, the error situation 5401 is raised.

Exceptions to the cases specified here shall be treated by HSS as error situations. The Result-Code shall be set to DIAMETER_UNABLE_TO_COMPLY and no authentication or GUSS information shall be returned.

Step 3

The HSS shall send the following Bootstrapping-Answer message in the format of Multimedia-Auth-Answer (MAA) message back to the BSF.

< Multimedia-Auth-Answer> ::= < Diameter Header: 303, PXY, 16777221 >
< Session-Id >
{ Vendor-Specific-Application-Id }
[ Result-Code ]
[ Experimental-Result]
{ Auth-Session-State } ; NO_STATE_MAINTAINED
{ Origin-Host } ; Address of HSS
{ Origin-Realm } ; Realm of HSS
[ User-Name ] ; IMPI

[ Public-Identity ] ; IMPU
[ SIP-Auth-Data-Item ]
[ GBA-UserSecSettings ] ; GUSS
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]

The HSS shall set the mandatory Auth-Session-State AVP to NO_STATE_MAINTAINED because the HSS does not maintain any state information about this session and the BSF does not need to send any session termination request 3GPP TS 29.229 [3].

If the Public-Identity was present in the request, both Public-Identity and User-Name AVPs shall be present in the response. Otherwise, the User-name AVP (IMPI) may be sent back for checking.

The required authentication vector data is sent in the SIP-Auth-Data-Items AVP as defined for IMS-AKA or SIP Digest authentication schemes according to 3GPP TS 29.228 [2]. The security settings of user’s all GAA applications are sent in GBA-UserSecSettings AVP.

If the 2G GBA option (see 3GPP TS 33.220, Annex I [5]) is applied for the user the SIP-Auth-Data-Item AVP shall be filled as follows: The SIP-Authentication-Scheme AVP is set to "Digest-AKAv1-MD5-2G-GBA" to indicate a 2G GBA vector for GBA. The SIP-Authenticate AVP contains only RAND. The SIP-Authorization AVP contains RES. The Confidentiality-Key AVP contains Kc. The Integrity-Key AVP shall not be present. If a 2G Authentication Vector is requested for the user but the 2G GBA option is not supported by the HSS, the HSS shall set the Experimental-Result-Code to DIAMETER_AUTHENTICATION_SCHEME_NOT_SUPPORTED (see 3GPP TS 29.228 [2]).

Step 4

When the BSF receives the MAA message, the BSF shall check the value of the SIP-Authentication-Scheme AVP. If the BSF does not support the authentication-scheme the BSF shall stop processing the message and should indicate an error via the O&M subsystem.

The BSF generates the needed key material (Ks) as described in 3GPP TS 33.220 [5] and stores temporarily the tuple <IMPI,Ks,GBA-UserSecSettings> for further use in GAA applications. The rest of the bootstrapping procedure in Ub interface will later add also the Bootstrapping Transaction Identifier (B-TID) to that tuple as key and the key lifetime (expiry time).

If the BSF sent the GUSS-Timestamp AVP in step 1, and if the GBA-UserSecSettings AVP contains a static string "GUSS TIMESTAMP EQUAL", then the local copy of the GUSS in the BSF shall be preserved. If the GBA-UserSecSettings AVP was not present in the MAA message, the local copy of the GUSS shall be deleted. If the GBA-UserSecSettings AVP contains a new GUSS, the local copy of the GUSS shall be deleted, and the new GUSS shall be stored in the BSF.

In GBA Bootstrapping Push procedures, the BSF generates the requested NAF-key(s) according to provided NAF_Id and the GBA Push Information (GPI). The BSF completes the rest of the bootstrapping push procedure sending its response to the NAF over Zpn interface, and deleting the Ks used as defined in section 5.

4.3 Protocol Zh’ between BSF and HLR

The requirements for Zh’ reference point are the same with the one for the Zh reference point defined in 3GPP TS 33.220 [5], except that the GBA User Security Settings (GUSS) are not supported.

The Bootstrapping Zh’ interface performs the retrieval of an authentication vector. The basic procedure is:

A) A UE starts the bootstrapping procedure by protocol Ub with a BSF giving the IMPI of the user (see 3GPP TS 24.109 [7]). In bootstrapping push procedures a NAF initiates a GBA Push Information Request by protocol Zpn with the BSF giving the user identity (see section 5). The BSF derives the IMSI from the IMPI. In bootstrapping push procedures when only the Public Identity of the user is made available to the BSF, the BSF shall perform public to private identity resolution as defined in section 4.3.1.

B) The BSF starts protocol Zh’ with user’s HLR

– The BSF requests user’s authentication vector corresponding to the IMSI.

– The HLR supplies to the BSF the requested authentication vector.

C) The BSF continues the protocol Ub with the UE (see 3GPP TS 24.109 [7]).

The BSF shall use the following Bootstrapping-Request to the HLR in the format of a MAP_SEND_AUTHENTICATION_INFO. The content of the request, result and error messages is given below in the same format as in 3GPP TS 29.002 [19]. The parameter usage is as follows:

IMSI

See 3GPP TS 29.002 [19] section 7.6.2 for the use of this parameter.

Number of requested vectors

The BSF shall only request one authentication vector at a time.

Requesting node type

BSF

Re-synchronisation Info

For definition and use of this parameter see 3GPP TS 33.102 [20].

Segmentation prohibited indicator

This parameter is not applicable and should not be sent by the BSF.

Immediate response preferred indicator

This parameter indicates that one of the requested authentication vectors is requested for immediate use in the BSF.

Requesting PLMN ID

The PLMN-ID of the requesting node. See 3GPP TS 23.003 [21].

AuthenticationSetList

One authentication vector is transferred from the HLR to the BSF, if the outcome of the service was successful.

User error

One of the following error causes defined in 3GPP TS 29.002 [19] shall be sent by the user in case of unsuccessful outcome of the service, depending on the respective failure reason:

– unknown subscriber;

– unexpected data value;

– system failure;

– data missing.

Provider error

See 3GPP TS 29.002 [19] for the use of this parameter.

When the BSF receives the response of the MAP_SEND_AUTHENTICATION_INFO service, then it shall generate the needed key material (Ks) from confidential key (CK) and integrity key (IK) as described in 3GPP TS 33.220 [5], respecively from Kc as decribed in 3GPP TS 33.220 [5] and stores temporarily the tuple <IMPI,Ks> for further use in GAA/GBA applications. The rest of the bootstrapping procedure in Ub interface will later add also the Bootstrapping Transaction Identifier (B-TID) to that tuple as key and the key lifetime (expiry time).

4.3.1 Public to Private Identity Resolution over Zh between BSF and HLR

When the UE identity used by the NAF in a GPI Request towards the BSF is an MSISDN, the BSF shall resolve the corresponding private user identity (IMSI) for the user.

When Zh interface between BSF and HLR is used, the BSF shall resolve the private user identity with the HLR in the format of a MAP_SEND_IMSI or a MAP_SEND_ROUTING_INFO_FOR_SM.

The content of the request, result and error messages is given below in the same format as in 3GPP TS 29.002 [19]. The parameter usage when the MAP_SEND_IMSI operation is used is as follows:

MSISDN

See 3GPP TS 29.002 [19] section 7.6.2 for the use of this parameter.

IMSI

See 3GPP TS 29.002 [19] section 7.6.2 for the use of this parameter. The presence of this parameter is mandatory in a successful case.

User error

Only one of the following values is applicable:

– Unknown subscriber;

– Unexpected data value;

– Data missing.

The parameter usage when the MAP_SEND_ROUTING_INFO_FOR_SM operation is used is as follows:

MSISDN

See 3GPP TS 29.002 [19] section 7.6.2 for the use of this parameter.

SM-RP-PRI

BSF shall set this parameter to indicate that delivery of the short message shall NOT be attempted when a service centre address is already contained in the Message Waiting Data file.

Service Centre Address

BSF shall include the BSF address within this parameter.

SM-RP-MTI

SM-RP-SMEA

GPRS Support Indicator

BSF shall not use these parameters in the public to private identity resolution request.

SM-Delivery Not Intended

BSF shall set this parameter to indicate that delivery of a short message is not intended and that only IMSI is requested.

IMSI

See 3GPP TS 29.002 [19] section 7.6.2 for the use of this parameter. The presence of this parameter is mandatory in a successful case.

Network Node Number

LMSI

GPRS Node Indicator

Additional Number

BSF ignores these parameters if present in the public to private identity resolution response.

User error

One of the following error causes defined in 3GPP TS 29.002 [19] shall be sent by the user in case of unsuccessful outcome of the service, depending on the respective failure reason:

– Unknown subscriber;

– Call Barred;

– Teleservice Not Provisioned;

– Absent Subscriber_SM;

– Facility Not Supported;

– System failure;

– Unexpected Data Value;

– Data missing.

Provider error

See 3GPP TS 29.002 [19] for the use of this parameter.

When the HLR is able to resolve the private identity of the user, the BSF continues with the boostrapping procedures over Zh and requests a user’s authentication vector corresponding to the IMSI as defined above. Otherwise the BSF provides the corresponding error to the NAF over Zpn as defined in section 5.