B.3 Signalling flows demonstrating a successful authentication 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 signalling flow in figure B.3-1 describes the generic message exchange between UE and NAF using HTTP Digest Authentication. In this example, the HTTPS client application resides in the ME, i.e., either Ks_NAF or Ks_ext_NAF is used as the key. The conversation can take place inside a server-authenticated TLS (as described in the RFC for TLS defined in annex E of 3GPP TS 33.310 [25]) tunnel in which case TLS session has been established before step 1.

Figure B.3-1: HTTP Digest Authentication with bootstrapped security association

1. GET request (UE to NAF) – see example in table B.3-1

The UE sends an HTTP request to a NAF to gain access to a service.

Table B.3-1: Initial GET request (UE to NAF)

GET / HTTP/1.1

Host: naf1.home1.net:1234

User-Agent: NAF1 Application Agent; Release-6 3gpp-gba

Date: Thu, 08 Jan 2004 10:50:35 GMT

Accept: */*

Referer: http://naf1.home1.net:1234/service

X-3GPP-Intended-Identity: "user@as1.home1.net"

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.

Host: Specifies the Internet host and port number of the NAF server, obtained from the original URI given by referring resource.

User-Agent: Contains information about the user agent originating the request and it includes the static string "3gpp-gba" to indicate to the application server (i.e. NAF) that the UE supports 3GPP-bootstrapping based authentication.

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

Accept: Media types which are acceptable for the response.

Referer: Allows the user agent to specify the address (URI) of the resource from which the URI for the NAF was obtained.

NOTE 1: This step can also be a POST request in which case the request would contain a client payload in the HTTP request and the corresponding Content-Type and Content-Length header values.

2. 401 Unauthorized response (NAF to UE) – see example in table B.3-2

Upon receiving an HTTP request that contains static string "3gpp-gba" in the User-Agent header, NAF can choose to authenticate the UE using bootstrapped security association. If NAF chooses to authenticate the UE using bootstrapped security association, it responds with HTTP response code 401 "Unauthorized" which contains a WWW-Authenticate header. The header instructs the UE to use HTTP Digest Authentication with a bootstrapped security association.

Table B.3-2: 401 Unauthorized response (NAF to UE)

HTTP/1.1 401 Unauthorized

Server: Apache/1.3.22 (Unix) mod_perl/1.27

Date: Thu, 08 Jan 2004 10:50:35 GMT

WWW-Authenticate: Digest realm="3GPP-bootstrapping@naf.home1.net", nonce="6629fae49393a05397450978507c4ef1", algorithm=SHA2-256, qop="auth,auth-int", opaque="5ccc069c403ebaf9f0171e9517f30e41"

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

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

WWW-Authenticate: The NAF challenges the user. The header instructs the UE to use HTTP Digest Authentication with a bootstrapped security association.

The options for the quality of protection (qop) attribute is by default "auth-int" meaning that the payload of the following HTTP requests and responses should integrity protected. If the conversation is taking place inside a server-authenticated TLS tunnel, the options for the qop attribute can also contain "auth" meaning that the payload of the following HTTP requests and responses are not protected by HTTP Digest. The integrity protection is handled on the TLS layer instead.

The realm attribute contains two parts delimited by "@" sign. The first part is a constant string "3GPP-bootstrapping" instructing the UE to use a bootstrapped security association. The second part is the FQDN of the NAF.

The value of the "algorithm" attribute is "SHA2-256", "SHA2-512/256" or "MD5".

NOTE 2: The MD5 algorithm is only supported for backward compatibility.

3. Generation of NAF specific keys at UE

UE verifies that the second part of the realm attribute does correspond to the server it is talking to. In particular, if the conversation is taking place inside a server-authenticated TLS tunnel, the UE shall verify that the server name in the server’s TLS certificate matches the server name in the realm attribute of the WWW-Authenticate header.

UE derives the NAF specific key material Ks_(ext)_NAF as specified in 3GPP TS 33.220 [1].

NOTE 3: If UE does not have a bootstrapped security association available, it obtains one by running bootstrapping procedure over Ub interface

4. GET request (UE to NAF) – see example in table B.3-3

UE generates the HTTP request by calculating the Authorization header values using the bootstrapping transaction identifier B–TID it received from the BSF as the username and the NAF specific key material Ks_(ext)_NAF (base64 encoded) as the password, and sends the request to NAF.

Table B.3-3: GET request (UE to NAF)

GET / HTTP/1.1

Host: naf1.home1.net:1234

User-Agent: NAF1 Application Agent; Release-6 3gpp-gba

Date: Thu, 08 Jan 2004 10:50:35 GMT

Accept: */*

Referer: http://naf1.home1.net:1234/service

X-3GPP-Intended-Identity: "user@as1.home1.net"

Authorization: Digest username="(B-TID)", realm="3GPP-bootstrapping@naf.home1.net", nonce="a6332ffd2d234==", uri="/", qop=auth-int, nc=00000001, cnonce="6629fae49393a05397450978507c4ef1", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f30e41", algorithm=SHA2-256

Authorization: This carries the response to the authentication challenge received in step 2 along with the username, the realm, the nonce, the URI, the qop, the nc, the cnonce, the response, the opaque, and the algorithm.

The qop attribute is set to "auth-int" by default. If the conversation is taking place inside a server-authenticated TLS tunnel, the qop attribute can be set to "auth" as well.

The value of the "algorithm" attribute is set to "SHA2-256", "SHA2-512/256" or "MD5".

NOTE 4: The MD5 algorithm is only supported for backward compatibility.

NOTE 5: If step 1 was a POST request then this request would also be POST request and contain the same client payload in the HTTP request as was carried in step 1.

5. Zn: NAF specific key procedure

NAF retrieves the NAF specific key material (Ks_NAF or Ks_ext_NAF) from the BSF.

In the case that the HTTPS client resides in the UICC, then the NAF needs to retrieve Ks_int_NAF.

If the NAF retrieved an application-specific USS and it contained a keyChoice indication, the NAF must enforce this indication. Hence, if the UICC-based key was indicated the NAF must terminate the communication with the UE in this phase.

NOTE 6: If the local configuration in the NAF restricts the access to the service to UICC-based applications using only Ks_int_NAF, then the NAF will terminate the communication with the UE in this phase.

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

Table B.3-4: Bootstrapping authentication information procedure (NAF to BSF)

Message source and destination	Zn Information element name	Information Source in GET	Description
NAF to BSF	B-TID	Authorization	The bootstrapping transaction identifier (B-TID) is encoded in the username field according to the Authorization protocol.

6. Authentication at NAF

NAF verifies the Authorization header by using the bootstrapping transaction identifier B-TID and the key material Ks_(ext)_NAF obtained from BSF. NAF calculates the corresponding digest values using Ks_(ext)_NAF, and compares the calculated values with the received values in the Authorization header.

The NAF also verifies that the DNS name in the realm attribute matches its own. If the conversation is taking place inside a server-authenticated TLS tunnel, the NAF shall also verify that this DNS name is the same as that of the TLS server certificate.

If the verification succeeds, the incoming client-payload request is taken in for further processing.

7. 200 OK response (NAF to UE) – see example in table B.3-5

The NAF sends 200 OK response to the UE to indicate the success of the authentication. NAF generates a HTTP response containing the server-payload it wants to send back to the UE. The NAF can use key material Ks_(ext)_NAF to integrity protect and authenticate the response.

Table B.3-5: 200 OK response (NAF to UE)

HTTP/1.1 200 OK

Server: Apache/1.3.22 (Unix) mod_perl/1.27Content-Type: text/html

Content-Length: 1234

Authentication-Info: qop=auth-int, rspauth="6629fae49394a05397450978507c4ef1", cnonce="6629fae49393a05397450978507c4ef1", nc=00000001

Date: Thu, 08 Jan 2004 10:50:35 GMT

Expires: Fri, 09 Jan 2004 10:50:36 GMT

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 protection

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

8. Authentication at UE

UE receives the response and verifies the Authentication-Info header. If the verification succeeds, the UE can accept the server-payload for further processing.

NOTE 7: Additional messages can be exchanged using steps 4 through 8 as many times as is necessary. The following HTTP requests and responses are constructed according to RFC 7616 [36].

Annex C (normative):
XML Schema Definition