The bootstrapping of key material occurs between UE - BSF - HSS within the overall GBA architecture as shown by figure 3.2. The sequence chart 3.3 shows
Ub Ua Zh Zn HSS AS UE BSF NAF
Figure 3.2: The Bootstrapping Procedure
the message exchange.
UE BSF HSS
1. GET (IMPI)
4. 401, Nonce
6. GET (IMPI, RES)
2. MAR 3. MAA
8. 200 OK
7. Authentication and generation of key material 5. Generation of response
and session keys
9. Generation of key material
Figure 3.3: The Bootstrapping Message Flow [TS24.109], modified
1. GET (IMPI) This initial request starts the bootstrapping procedure. The UE sends the HTTP GET request to the BSF. This request must contain the
user’s private user identity, the IMPI. An example request is given in the listing below:
GET / HTTP/1.1
Host: bsf .open−ims.org:8080
User−Agent: Bootstrapping Client Agent; Release−6 Date: Mon, 01 Jan 2007 00:00:01 GMT
Accept: ∗/∗
Referer: http: //naf.open−ims.org
Authorization: Digest username=” veryCrypticIdentifier@bsf .open−ims.org”, realm =”bsf.open−ims.org”, nonce=””, uri=”/”, response=””
The most important part of this request is the Authorization header which carries the private user identity ([email protected]). This is a cryptic identifier which is usually not known to the user. It is stored in the UICC/ISIM. The realm parameter carries the name of the network where the IMPI is authenticated and the uri parameter carries the same value as the request URI.
It is assumed here 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.” [TS24.109]
2. MAR Step two and three are executed over interface Zh between BSF and HSS. This is Diameter communication. The BSF requests Authentication Vectors (AV) and GBA User Security Settings (GUSS) from the HSS, corresponding to the IMPI obtained from step one by sending a Multimedia-Auth-Request (MAR). For a detailed listing of the MAR and MAA commands please refer to appendix B. As specified in [RFC3588], Diameter makes use of Attribute Value Pairs (AVP). The User-Name AVP carries the IMPI and allows the HSS to fetch the correct AV and GUSS for the user requesting the bootstrapping procedure.
3. MAA The Multimedia-Auth-Anwser (MAA) is returned from the HSS provid- ing the BSF with: The AVs (carried inside the SIP-Auth-Data-Item AVP) and the GUSS (carried inside the GBA-UserSecSettings AVP) for the IMPI obtained from step one. The AV has the following format:
AV = RAN DkAU T N kXRESkCKkIK
part of the AUTN.
AUTN: this value is called Authentication token and is a 128 bit value generated by the HSS.
XRES: this is the expected result from the UE. The BSF compares the digest value of RES (send by the UE in step six) with the digest value of XRES. If they are identical, the UE is expected to know the corre- sponding secret.
CK: this value is called Cipher Key and is part of the key material which the UE will create in step nine. BSF and UE will then dispose of the same key material.
IK: this is the Integrity Key, which is also part of the key material.
4. 401, Nonce The BSF stores the AV and GUSS for the corresponding IMPI. In case that the HSS sends more than one AV, the BSF needs to select an AV for further proceedings.
The BSF challenges the UE with a HTTP 401 Unauthorized response car- rying RAND and AUTN within the nonce field (according to [RFC3310]). This is send to the UE in order to demand authentication. The nonce will be something like:
CjPk9mRqNuT25eRkajM09uTl9nM09uTl9nMz5OX25PZz==.
HTTP/1.1 401 Unauthorized Server: bsf .open−ims.org
Date: Mon, 01 Jan 2007 00:00:02 GMT
WWW−Authenticate: Digest realm=”bsf.open−ims.org”, nonce= base64(RAND + AUTN + server specific data), algorithm=AKAv1−MD5, qop=”auth−int”
The important header here is the WWW-Authenticate header. The nonce includes a base64-encoded value of the concatenation of: RAND, AUTN and server specific data. The algorithm field instructs the ME which algorithm to employ. The field qop stand for quality of protection and is set by default to auth-int. This means that the payload of this message and the response should be integrity protected.
5. Generation of response and session keys Upon the reception of the HTTP 401 Unauthorized message from the BSF, the UE extracts the RAND and
AUTN values from the nonce value for further processing. The implemen- tation uses the HTTP Digest AKA [RFC3310] utility classes for the 3GPP Milenage alghoritm [TS35.205] which have been implemented by Sebastian Linkiewicz for the use of the FOKUS research community. The UE employs Digest AKA and 3GPP Milenage for calculation of the authentication chal- lenge response RES (using different parameters as defined in [RFC3310]). The UE furthermore computes the keys IK and CK.
6. GET (IMPI, RES) After successful generation, a digest of the authentication challenge response RES is send to the BSF together with the IMPI (this has obviously to be the same value as in step one) in a HTTP GET.
GET / HTTP/1.1
Host: bsf .open−ims.org:8080
User−Agent: Bootstrapping Client Agent; Release−6 Date: Mon, 01 Jan 2007 00:00:03 GMT
Accept: ∗/∗
Referer: http: //naf.open−ims.org
Authorization: Digest username=” veryCrypticIdentifier@bsf .open−ims.org”, realm =”bsf.open−ims.org”, nonce=base64(RAND + AUTN + server specific data), uri=”/”, qop=auth−int, nc=00000001, cnonce=”7865
kjh96853h98645234975642g8jd2”, response=”7865 kjh96853h98645234975642g8jd2”, opaque=”7
fff765d453hkkt6d3419j9854g47d34”, algorithm=AKAv1−MD5
The Authorization header carries the response to the authentication chal- lenge received from step 4 in the response field. The other values are:
username: The users IMPI.
realm: Name of the network where the IMPI is authenticated. nonce: The nonce value that was received from the BSF. uri: The same value as the request URI.
qop: Quality of protection, by default auth-int if no other security mech- anisms like TLS are employed.
nc: Needs to be set only if qop has been set. Stands for nounce-count and is the enumeration of requests (including the current request) with a
nonce.
cnonce: Needs to be set only, if qop has been set. Is a quoted-string, which is offered by the client in order to enable mutual authentication. It is furthermore used by both client and server to avoid chosen plaintext attacks and to provide some message integrity protection. Please refer to [RFC2617] for a more detailed description.
response: Is send to prove knowledge of the shared secret between UE and HSS. Is compared to the XRES digest at the BSF. Both need to be identical for successful authentication.
opaque: Data string specified by the server which should be returned un- changed by the client.
algorithm: The algorithm employed.
7. Authentication and generation of key material The BSF compares the di- gest values of the authentication response RES with the expected response, XRES. The user has successfully been authenticated if the two values match. The private user identity (IMPI) is registered in the BSF and a Bootstrap- ping transaction Identifier (B-TID) is generated for this IMPI. The BSF furthermore stores B-TID, IMPI, CK, and IK. Later, the NAF specific key material is generated from the stored tupel.
8. 200 OK If the RES and XRES digest match, the BSF sends a HTTP 200 OK response to the UE. In case of failure the HTTP 401 Unauthorized message from step four is re-send.
HTTP/1.1 200 OK
Server: bsf .open−ims.org
Authentication−Info: qop=auth−int, rspauth=”7865 kjh96853h98645234975642g8jd2”, cnonce=”7865 kjh96853h98645234975642g8jd2”, nc=00000001 Date: Mon, 01 Jan 2007 00:00:04 GMT
Expires: Mon, 01 Jan 2007 01:00:04 GMT Content−Type: application/vnd.3gpp.bsf+xml Content−Length: (...)
<?xml version=”1.0” encoding=”UTF−8”?> <BootstrappingInfo xmlns=”uri:3gpp−gba”
.org</btid>
<lifetime>3600</lifetime> </BootstrappingInfo>
The Authentication-Info header carries the server authentication infor- mation. Note that this header can include the rspauth parameter, which is the response digest. The server thereby proves to the ME that it also knows the user’s secret (response authentication). For more details, please refer to [RFC2617]. The Expires field carries the date and time after which the response is expired. The body of this message carries some bootstrapping information including the users B-TID. This can be used for anonymity at different NAFs if used as a pseudonym identifier. The NAF can retrieve GUSS for the user with this B-TID at the user’s home-BSF. More on this in the following sections.
9. Generation of key material The UE generates the key material Ks by con- catenating CK and IK. Depending on whether GBA ME or GBA U is em- ployed, either the ME stores the B-TID and Ks or the UICC stores this tuple. The NAF specific key material Ks NAF is generated on the Ua in- terface which will be discussed in detail in the next section.