D.3 Signalling flow 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 D.3-1 describes the generic message exchange between a UE, a AP, and an AS using HTTP. In this example, the HTTP client application resides in the ME, i.e., either Ks_NAF or Ks_ext_NAF is used as the key. The conversation between the UE and the AP 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 D.3-1: Successful authentiation with AP and AS

1. GET request (UE to AP) – see example in table D.3-1

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

Table D.3-1: Initial GET request (UE toAP)

GET / HTTP/1.1

Host: as1.home1.net:1234

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

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

Accept: */*

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

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 AS, 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 AS was obtained.

NOTE 1: The UE assumes it is communicating directly with the AS, but is in fact communicating with the AP which functioning as a reverse proxy.

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

Upon receiving an HTTP request that contains static string "3gpp-gba" in the User-Agent header, the AP might choose to authenticate the UE using bootstrapped security association. If AP 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 D.3-2: 401 Unauthorized response (AP 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@as1.home1.net", nonce="6629fae49393a05397450978507c4ef1", algorithm=SHA2-256, qop="auth,auth-int", opaque="5ccc069c403ebaf9f0171e9517f30e41"

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

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

WWW-Authenticate: The AP 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 for HTTP Digest integrity protection 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 might 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. In this case, the FQDN of the NAF must be the server hostname that the UE used in the corresponding HTTP request, i.e., the hostname of the AS.

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

The 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 verifies that the server name in the server’s TLS certificate matches the server name in the realm attribute of the WWW-Authenticate header.

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

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

4. GET request (UE to AP) – see example in table D.3-3

The 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 the AP.

Table D.3-3: GET request (UE to AP)

GET / HTTP/1.1

Host: as1.home1.net:1234

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

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

Accept: */*

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

Authorization: Digest username="(B-TID)", realm="3GPP-bootstrapping@as1.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" when HTTP Digest integrity protection is used. 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.

5. Validate authentication and authorize request

If the AP does not have the NAF specific key material (Ks_NAF or Ks_ext_NAF), then the AP retrieves that and one or more user security setting (USS) from the BSF. For detailed signalling flows see 3GPP TS 29.109 [3].

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

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

The AP verifies the Authorization header by using the bootstrapping transaction identifier B-TID and the key material Ks_(ext)_NAF obtained from BSF. The AP calculates the corresponding digest values using Ks_(ext)_NAF, and compares the calculated values with the received values in the Authorization header. The AP will also verify that the DNS name in the realm attribute matches the AS hostname. If the conversation is taking place inside a server-authenticated TLS tunnel, the AP will also verify that this DNS name is the same as that of the TLS server.

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

Depending on the AP configuration, the AP will inspect the incoming HTTP request accordingly, see 3GPP TS 33.222 [5]. In this example it is assumed that the AP has been configured to add subscriber’s identifiers (UIDs) to the forwarded HTTP request (see step 6).

NOTE 6: If UE has included "X-3GPP-Intended-Identity" with subscriber’s identity to the HTTP response, then the AP will validate the given identity before forwarding the request to the AS.

6. GET request (AP to AS) – see example in table D.3-4

The AP forwards the HTTP request to the correct AS. The correct AS is determined by checking the "Host" header of the request and AP’s internal configuration.

The AP removes the "Authorization" header from the forwarded HTTP request. Depending on the AP configuration, the AP might add subscriber’s UIDs to the HTTP request by using "X-3GPP-Asserted-Identity" header.

In this example, subscriber’s UIDs are added to the request.

Table D.3-4: GET request (AP to AS)

GET / HTTP/1.1

Host: as1.home1.net:1234

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

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

Accept: */*

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

X-3GPP-Asserted-Identity: "user@as1.home1.net", "user2@as1.home.net"

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.

X-3GPP-Asserted-Identity: This header is added by the AP and carries the list of subscriber’s identities to the AS.

7. AS specific logic at AS

The AS processes the incoming HTTP request and extracts the UIDs from the "X-3GPP-Asserted-Identity" header.

8. 200 OK response (AS to AP) – see example in table D.3-5

The AS returns a HTTP response to the AP with service specific payload.

Table D.3-5: 200 OK response (AS to AP)

HTTP/1.1 200 OK

Server: Apache/1.3.22 (Unix) mod_perl/1.27

Content-Type: text/html

Content-Length: (…)

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.

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

9. Add Authentication-Info header at AP

The AP calculates and adds the "Authentication-Info" header to the HTTP response that forwarded to the UE.

10. 200 OK response (AP to UE) – see example in table D.3-6

The AP forwards the HTTP response to the UE.

Table D.3-6: 200 OK response (AP to UE)

HTTP/1.1 200 OK

Server: Apache/1.3.22 (Unix) mod_perl/1.27

Content-Type: text/html

Content-Length: 1234

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

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

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

Authentication-Info: This header is inserted by the AP to the request. The values in the header are calculated by the AP.

11. Process response at UE

The 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 11 as many times as is necessary. The HTTP Digest releated headers in the following HTTP requests and responses must be constructed according to RFC 7616 [36].

Annex E (informative):
Signalling flows for PKI portal