A.22 GAA XCAP authentication
34.229-53GPPInternet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Part 5: Protocol conformance specification using 5G System (5GS)Release 16TSUser Equipment (UE) conformance specification
The generic test procedure for GBA authentication between UE and BSF.
The generic test procedure for GAA XCAP authentication is referred to the bootstrapping procedure in TS 33.220 [44], clause 4.5.2 and TS 24.109 [43] clause 4.2.
Test procedure:
0a) Pre-configurations:
The UE may resolve the IP address for the BSF server via DNS.
0b) At the SS an HTTP server is established at port 80 to simulate the BSF server.
1) UE sends initial GET to the BSF server.
2) BSF server responds with “401 Unauthorized”.
3) UE sends GET with Authorization header to the BSF server.
4) BSF server responds with "200 OK" when the UE has provided a valid Authorization header.
Expected sequence:
Step |
Direction |
Message |
Comment |
|
UE |
SS |
|||
1 |
🡪 |
HTTP Request |
||
2 |
🡨 |
HTTP Response: “401 Unauthorized” |
||
3 |
🡪 |
HTTP Request with valid authorization credentials |
||
4 |
🡨 |
HTTP Response: “200 OK” |
Specific Message Contents
HTTP Request (step 1)
Header/param |
Cond |
Value/remark |
Rel |
Reference |
---|---|---|---|---|
Request-Line |
RFC 2616 [46] |
|||
Method |
GET |
|||
Request-URI |
Request-URI |
|||
Version |
HTTP/ DIGIT.DIGIT |
|||
Host |
RFC 2616 [46] |
|||
host |
bsf.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org (when no ISIM available on the UICC), optionally followed by port 80 or bsf.domain name (when using ISIM) , optionally followed by port 80 |
|||
User-Agent |
RFC 2616 [46] |
|||
Product token |
3gpp-gba-tmpi |
TS 24.109 [43] |
||
Authorization |
Digest |
RFC 2616 [46] RFC 2617 [23] RFC 3310 [47] |
||
username |
private user identity as stored in EFIMPI (when using ISIM) or private user identity derived from IMSI (when no ISIM available on the UICC) or the value of the TMPI if one has been associated with the private user identity as described in 3GPP TS 33.220 [44] |
|||
realm |
bsf.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org (when no ISIM available on the UICC) or bsf.domain name (when using ISIM) |
|||
nonce |
empty value |
|||
digest-uri |
absoluteURL http://<BSF address>/ or abs_path "/" |
|||
response |
empty value |
NOTE 1: All choices for applicable conditions are described for each header.
HTTP Response (step 2)
Header/param |
Cond |
Value/remark |
Rel |
Reference |
---|---|---|---|---|
Status-Line |
RFC 2616 [46] |
|||
Version |
HTTP/1.1 |
|||
Code |
401 |
|||
Reason |
Unauthorized |
|||
Server |
RFC 2616 [46] |
|||
product |
BSF-Server |
|||
Date |
RFC 2616 [46] |
|||
HTTP-date |
valid date according to RFC 2616 [46] section 3.3.1 |
|||
WWW-Authenticate |
RFC 2616 [46] RFC 2617 [23] |
|||
challenge |
Digest |
|||
realm |
same value as received in step 1 |
|||
algorithm |
AKAv1-MD5 |
|||
qop-value |
auth-int |
|||
nonce |
Base 64 encoding of RAND and AUTN |
|||
opaque |
5ccc069c403ebaf9f0171e9517f30e41 |
HTTP Request (step 3)
Header/param |
Cond |
Value/remark |
Rel |
Reference |
---|---|---|---|---|
Request-Line |
RFC 2616 [46] |
|||
Method |
GET |
|||
Request-URI |
Request-URI |
|||
Version |
HTTP/ DIGIT.DIGIT |
|||
Host |
RFC 2616 [46] |
|||
host |
bsf.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org (when no ISIM available on the UICC), optionally followed by port 80 or bsf.domain name (when using ISIM), optionally followed by port 80 |
|||
Authorization |
Digest |
RFC 2616 [46] RFC 2617 [23] RFC 3310 [47] |
||
username |
private user identity as stored in EFIMPI (when using ISIM) or private user identity derived from IMSI (when no ISIM available on the UICC) or the value of the TMPI if one has been associated with the private user identity as described in 3GPP TS 33.220 [44] |
|||
realm |
same value as received in the realm directive in the WWW Authenticate header sent by SS |
|||
opaque |
5ccc069c403ebaf9f0171e9517f30e41 |
|||
digest-uri |
absoluteURL http://<BSF address>/ or abs_path "/" |
|||
cnonce-value |
value assigned by UE affecting the response calculation |
|||
nonce-count |
00000001 |
|||
response |
response calculated by UE |
|||
algorithm |
AKAv1-MD5 |
NOTE 1: All choices for applicable conditions are described for each header.
HTTP Response (step 4)
Header/param |
Cond |
Value/remark |
Rel |
Reference |
---|---|---|---|---|
Status-Line |
RFC 2616 [46] |
|||
Version |
HTTP/1.1 |
|||
Code |
200 |
|||
Reason |
OK |
|||
Server |
RFC 2616 [46] |
|||
Product token |
3gpp-gba-tmpi |
|||
Date |
RFC 2616 [46] |
|||
HTTP-date |
valid date according to RFC 2616 [46] section 3.3.1 |
|||
Authentication-Info |
RFC 2616 [46] RFC 2617 [23] |
|||
message-qop |
qop=auth-int |
|||
rspauth |
see Note 1 |
|||
cnonce |
same value as received in step 3 |
|||
nc |
1 |
|||
Content-Type |
RFC 2616 [46] |
|||
media-type |
application/vnd.3gpp.bsf+xml |
|||
Content-Length |
RFC 2616 [46] |
|||
value |
length of the message body |
|||
Message-body |
<?xml version="1.0" encoding="UTF-8"?> <BootstrappingInfo xmlns="uri:3gpp-gba"> <btid>B-TID</btid> <lifetime>key lifetime</lifetime> </BootstrappingInfo> with B-TID – key lifetime |
RFC 2616 [46] TS 24.109 Annex C [43] |
NOTE 1: Rspauth is computed according to RFC 3310 and RFC 2617.