E.5 Signalling flows demonstrating a successful CA certificate delivery

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 E.5-1 describes the message exchange between UE and PKI portal when UE requests a CA certificate delivery. The messaging 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 E.5-1: Successful CA certificate delivery.

1. Initial get request (UE to PKI portal) – see example in table E.5-1

The UE sends an HTTP request to the PKI portal requesting the delivery of CA certificate.

Table E.5-1: Initial get request (UE to PKI portal)

GET /getcertificate?in=aabbccdd== HTTP/1.1

Host: pkiportal.home1.net:1234

User-Agent: SCEnrolmentAgent; Release-6

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

Accept: */*

Referer: http://pkiportal.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. The Request-URI contains the parameter "in" (i.e. issuer name) which is set to the Base64 encoding of the DER encoded Issuer field of the X.509 certificate.

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

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.

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

NOTE 1: This step is used to trigger the GBA-based authentication between the UE and the PKI portal.

2. 401 Unauthorized response (PKI portal to UE) – see example in table E.5-2

The PKI portal 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 E.5-2: 401 Unauthorized response (PKI portal 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@pkiportal.home1.net", nonce="6629fae49393a05397450978507c4ef1", algorithm=MD5, qop="auth,auth-int", opaque="5ccc069c403ebaf9f0171e9517f30e41"

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

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

WWW-Authenticate: The PKI portal 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 messaging 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 host of the server (i.e. the FQDN of the PKI portal).

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 messaging is taking place inside a server-authenticated TLS tunnel, the UE verifies that the server name (i.e. FQDN of the PKI portal) in the server’s TLS certificate matches the hostname of the server in the realm attribute of the WWW-Authenticate header.

UE derives the NAF specific key material Ks_NAF as specified in 3GPP TS 33.220 [1].

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

4. Authenticated get request (UE to PKI portal) – see example in table E.5-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_NAF (base64 encoded) as the password, and sends the request to PKI portal.

Table E.5-3: Authenticated get request (UE to PKI portal)

GET /getcertificate?in=aabbccdd== HTTP/1.1

Host: pkiportal.home1.net:1234

User-Agent: SCEnrolmentAgent; Release-6

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

Accept: */*

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

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

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 messaging is taking place inside a server-authenticated TLS tunnel, the qop attribute can be set to "auth" as well.

NOTE 3: If step 1 was a GET request then this request would also be GET request and contain the same Request-URI in the HTTP request as was carried in step 1.

5. Zn: NAF specific key procedure

PKI portal retrieves the NAF specific key material (Ks_NAF) from the BSF.

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

Table E.5-4: Bootstrapping authentication information procedure (PKI portal 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 PKI portal

PKI portal verifies the Authorization header by using the bootstrapping transaction identifier B-TID and the key material Ks_NAF obtained from BSF. PKI portal calculates the corresponding digest values using Ks_NAF, and compares the calculated values with the received values in the Authorization header.

The PKI portal also verifies that the hostname (i.e. its FQDN) in the realm attribute matches its own. If the HTTP messaging is taking place inside a server-authenticated TLS tunnel, the PKI portal also verifies that this hostname is the same as that of the TLS server.

If the verification succeeds, the incoming client-payload request is taken in for further processing, i.e. the PKI portal sends the requested CA certificate to the UE.

7. Delivery of CA certificate (PKI portal to UE) – see example in table E.5-5

The PKI portal sends 200 OK response to the UE to indicate the success of the authentication. The PKI portal generates a HTTP response containing the requested CA certificate. The PKI portal use the key material Ks_NAF to integrity protect and authenticate the response.

Table E.5-5: Delivery of CA certificate (PKI portal to UE)

HTTP/1.1 200 OK

Server: Apache/1.3.22 (Unix) mod_perl/1.27

Content-Type: text/html

Content-Type: application/x-x509-ca-cert

Content-Length: (…)

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

—– BEGIN CERTIFICATE —–

—– END CERTIFICATE —–

Content-Type: Contains the media type "application/x-x509-ca-cert", i.e. X.509 CA certificate.

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 and response verification at UE

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