A.3 Signalling flows demonstrating a successful bootstrapping procedure
24.1093GPPBootstrapping interface (Ub) and network application function interface (Ua)Protocol detailsRelease 17TS
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 = RANDn||AUTNn||XRESn||CKn||IKn 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"?>
<BootstrappingInfo xmlns="uri:3gpp-gba">
<btid>user@bsf.operator.com</btid>
<lifetime>2004-05-28T13:20:00Z</lifetime>
<Extension>
<currenttime>2004-05-27T13:20:00Z</currenttime>
</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].