A.3 Signalling flows demonstrating a successful bootstrapping procedure

24.1093GPPBootstrapping interface (Ub) and network application function interface (Ua)Protocol detailsRelease 17TS

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

The overall bootstrapping procedure in successful case is presented in figure A.3-1. The bootstrapping Zh interface performs the retrieval of an authentication vector by BSF from the HSS. The procedure corresponds to the step 2 in figure A.3-1.

This clause specifies in detail the format of the bootstrapping procedure that is further utilized by various applications. It contains the AKA authentication procedure with BSF, and later the bootstrapping key material generation procedure.

Figure A.3-1: Bootstrapping signalling

1. Initial GET request (UE to BSF) – see example in table A.3-1

The purpose of this message is to initiate bootstrapping procedure between the UE and BSF. The UE sends an HTTP request containing the private user identity towards its home BSF.

Table A.3-1: Initial GET request (UE to BSF)

GET / HTTP/1.1

Host: bsf.home1.net:80

User-Agent: Bootstrapping Client Agent; Release-6; 3gpp-gba-tmpi

Date: Thu, 08 Jan 2004 10:13:17 GMT

Accept: */*

Authorization: Digest

username="user1_private@home1.net",

realm="bsf.home1.net",

nonce="",

uri="/",

response=""

Request-URI: The Request-URI (the URI that follows the method name, "GET", in the first line) indicates the resource indication of this GET request. For bootstrapping server, this is by default "/".

Host: Specifies the Internet host and port number of the BSF server, derived from the private user identity or IMSI according to 3GPP TS 23.003 [7], or obtained from the original URI given by referring resource. The port number to be used with Ub reference point is the default port of HTTP, i.e. 80.

User-Agent: Contains information about the user agent originating the request.

Date: Represents the date and time at which the message was originated.

Accept: Media types which are acceptable for the response.

Authorization: It carries authentication information. The private user identity (user1_private@home1.net) is carried in the username field of the Digest AKA protocol. The "uri" parameter (directive) contains the same value as the Request-URI. The ”realm” parameter (directive) contains the network name where the username is authenticated. The Host and the "realm" parameter (directive) value are obtained from the same field in the USIM and therefore, are identical. In this example, it is assumed that a new UICC card was just inserted into the terminal, and there is no other cached information to send. Therefore, "nonce" and "response" parameters (directives) are empty.

2. Zh: Authentication procedure

BSF retrieves the corresponding AVs from the HSS.

For detailed signalling flows see 3GPP TS 29.109 [3].

Table A.3-2: BSF authentication information procedure (BSF to HSS)

Message source and destination	Zh Information element name	Information Source in GET	Description
BSF to HSS	Private User Identity	Authorization:	The Private User Identity is encoded in the username field according to the Authorization protocol.

3. Authentication vector selection

The BSF selects an authentication vector for use in the authentication challenge. For detailed description of the authentication vector, see 3GPP TS 33.220 [1].

NOTE 1: The authentication vector can be of the form as in 3GPP TS 33.203 [21] (if IMS AKA is the selected authentication scheme):

– AV = RAND_n||AUTN_n||XRES_n||CK_n||IK_n where:

• RAND: random number used to generate the XRES, CK, IK, and part of the AUTN. It is also used to generate the RES at the UE.

• AUTN: Authentication token (including MAC and SQN); 128 bit value generated by the HSS.

• XRES: Expected (correct) result from the UE.

• CK: Cipher key (optional).

• IK: Integrity key.

4. 401 Unauthorized response (BSF to UE) – see example in table A.3-3

BSF forwards the challenge to the UE in HTTP 401 Unauthorized response (without the CK, IK and XRES). This is to demand the UE to authenticate itself. The challenge contains RAND and AUTN that are populated in nonce field according to RFC 3310 [6].

Table A.3-3: 401 Unauthorized response (BSF to UE)

HTTP/1.1 401 Unauthorized

Server: Bootstrapping Server; Release-6

Date: Thu, 08 Jan 2004 10:13:17 GMT

WWW-Authenticate: Digest

realm="bsf.home1.net",

nonce= base64(RAND + AUTN + server specific data),

algorithm=AKAv1-MD5,

qop="auth-int",

opaque="5ccc069c403ebaf9f0171e9517f30e41"

Server: Contains information about the software used by the origin server (BSF).

Date: Represents the date and time at which the message was originated.

WWW-Authenticate: The BSF challenges the user. The nonce includes the quoted string, base64 encoded value of the concatenation of the AKA RAND, AKA AUTN and server specific data.

NOTE 2: The actual nonce value in the WWW-Authenticate header field is encoded in base64, and it can look like: nonce="A34Cm+Fva37UYWpGNB34JP".

5. Generation of response and session keys at UE

Upon receiving the Unauthorized response, the UE extracts the MAC and the SQN from the AUTN. The UE calculates the XMAC and checks that XMAC matches the received MAC and that the SQN is in the correct range. If both these checks are successful the UE calculates the authentication challenge response (using RES and other parameters as defined in RFC 3310 [6]), and also computes the session keys IK and CK. The authentication challenge response is put into the Authorization header and sent back to the BSF in the GET request.

6. GET request (UE to BSF) – see example in table A.3-4

The UE sends an HTTP GET request again, with the RES, which is used for response calculation, to the BSF.

Table A.3-4: GET request (UE to BSF)

GET / HTTP/1.1

Host: bsf.home1.net:80

User-Agent: Bootstrapping Client Agent; Release-6; 3gpp-gba-tmpi

Date: Thu, 08 Jan 2004 10:13:18 GMT

Accept: */*

Authorization: Digest

username="user1_private@home1.net",

realm="bsf.home1.net",

nonce="base64(RAND + AUTN + server specific data)",

uri="/", qop=auth-int,

nc=00000001,

cnonce="6629fae49393a05397450978507c4ef1",

response="6629fae49393a05397450978507c4ef1",

opaque="5ccc069c403ebaf9f0171e9517f30e41",

algorithm=AKAv1-MD5

Authorization: This carries the response to the authentication challenge received in step 4 and contains the private user identity, the realm, the nonce, the URI, the qop, the nc, the cnonce, the response, the opaque, and the algorithm.

7. Authentication and generation of key material at BSF

Upon receiving an integrity protected GET request carrying the authentication challenge response, the BSF checks that the expected response (calculated by the BSF using XRES and other parameter as defined in RFC 3310 [6]) matches the received challenge response. If the check is successful then the user has been authenticated and the private user identity is registered in the BSF.

The BSF generates the bootstrapping transaction identifier (B-TID) for the IMPI and stores the tuple <B‑TID,IMPI,CK,IK>.

For detailed bootstrapping key material generation procedure see 3GPP TS 33.220 [1].

8. 200 OK response (BSF to UE) – see example in table A.3-5

The BSF sends 200 OK response to the UE to indicate the success of the authentication.

Table A.3-5: 200 OK response (BSF to UE)

HTTP/1.1 200 OK

Server: Bootstrapping Server; Release-6; 3gpp-gba-tmpi

Authentication-Info: qop=auth-int,

rspauth="6629fae49394a05397450978507c4ef1",

cnonce="6629fae49393a05397450978507c4ef1",

nc=00000001,

nextnonce="base64(RAND + AUTN + server specific data)"

Date:

Expires: Thu, 08 Jan 2004 10:23:17 GMT

Content-Type: application/vnd.3gpp.bsf+xml

Content-Length: (…)

<?xml version="1.0" encoding="UTF-8"?>

<btid>user@bsf.operator.com</btid>

</Extension>

</BootstrappingInfo>

Content-Type: Contains the media type of the entity body.

Content-Length: Indicates the size of the entity-body, in decimal number of OCTETs, sent to the recipient.

Authentication-Info: This carries the server authentication information. The header includes the "rspauth" parameter, which is calculated as specified in RFC 7616 [36] using RES for response calculation as specified in RFC 3310 [6].

Expires: Gives the date/time after which the response is considered stale.

9. Generation of key material at UE

The key material Ks is generated in UE by concatenating CK and IK. In the case of GBA_ME, the ME stores the tuple <B-TID,Ks>, and in the case of GBA_U, the UICC stores the tuple <B-TID,Ks>.

NOTE 3: The NAF specific key material (Ks_NAF in the case of GBA_ME, or Ks_ext_NAF and Ks_int_NAF in the case of GBA_U) is derived from Ks during the Ua interface procedures, and is used for securing the Ua interface. In the case of GBA_ME, the ME stores the tuple <B-TID,Ks_NAF> and in the case of GBA_U, the ME stores the tuple <B‑TID,Ks_ext_NAF>, and the UICC stores the tuple <B-TID,Ks_int_NAF>.

For detailed bootstrapping key material generation procedure for NAF specific key (Ks_NAF, Ks_ext_NAF or Ks_int_NAF) see 3GPP TS 33.220 [1].