E.3 Signalling flows demonstrating a successful subscriber certificate enrolment

24.1093GPPBootstrapping interface (Ub) and network application function interface (Ua)Protocol detailsRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

E.3.1 Simple subscriber certificate enrolment

The signalling flow in figure E.3.1-1 describes the message exchange between UE and PKI portal when UE wants to enrol a subscriber certificate. 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.3.1-1: Successful subscriber certificate enrolment.

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

The UE sends an HTTP request to the PKI portal containing a PKCS#10 certification request.

Table E.3.1-1: Initial enrolment request (UE to PKI portal)

POST /enrol?response=single HTTP/1.1

Host: pkiportal.home1.net:1234

Content-Type: application/x-pkcs10

Content-Length: (…)

User-Agent: SCEnrolmentAgent; Release-6 3gpp-gba

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

Accept: */*

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

—– BEGIN CERTIFICATE REQUEST —–

<PKCS#10 BLOB>

—– END CERTIFICATE REQUEST —–

Request-URI: The Request-URI (the URI that follows the method name, "POST", in the first line) indicates the resource of this POST request. The Request-URI contains the parameter "response" which is set to "single" to indicate to the PKI portal the desired response type, i.e. just the subscriber certificate is requested to be delivered.

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

Content-Type: Contains the media type "application/x-pkcs10", i.e. the PKCS#10.

Content-Length: Indicates the size of the entity-body, in decimal number of OCTETs, sent to the recipient.

User-Agent: Contains information about the user agent originating the request and it will include 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 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.3.1-2

Upon receiving an HTTP request that contains static string "3gpp-gba" in the User-Agent header 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.3.1-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 hostname of the server (i.e. 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 enrolment request (UE to PKI portal) – see example in table E.3.1-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.3.1-3: Authenticated enrolment request (UE to PKI portal)

POST /enrol?response=single HTTP/1.1

Host: pkiportal.home1.net:1234

Content-Type: application/pkcs10

Content-Length: (…)

User-Agent: SCEnrolmentAgent; Release-6 3gpp-gba

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="/enrol?response=single", qop=auth-int, nc=00000001, cnonce="6629fae49393a05397450978507c4ef1", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f30e41", algorithm=MD5

—– BEGIN CERTIFICATE REQUEST —–

<PKCS#10 BLOB>

—– END CERTIFICATE REQUEST —–

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 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

PKI portal retrieves the NAF specific key material (Ks_NAF) and subscriber’s user security setting from the BSF.

NOTE 4: Subscriber’s user security setting for PKI portal consists of flags that indicate whether certain type certificate is authorized to be issued to the subscriber. There are two certificate types: authentication certificate and non-repudiation certificate.

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

Table E.3.1-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 and certificate generation 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 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. The PKI portal continues processing of the PKCS#10 request according to its internal policies. The PKI portal verifies that the subscriber is allowed to receive the particular type of certificate indicate in the PKCS#10 request by checking subscriber’s user security setting received from the BSF in step 5.

NOTE 5: The procedures for generating the subscriber certificate are outside the scope.

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

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

Table E.3.1-5: Delivery of subscriber 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-user-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-user-cert", i.e. X.509 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 at UE

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

E.3.2 Subscriber certificate enrolment with WIM authentication codes

The signalling flow in figure E.3.2-1 describes the message exchange between UE and PKI portal when UE wants to enrol a subscriber certificate, and the UE uses a WIM that requires authentication codes both for onboard key pair generation and proof-of-origin generation. 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.3.2-1: Successful subscriber certificate enrolment

1. WIM authentication code for onboard key pair generation required at UE

The UE has initiated enrolment procedure and the WIM in the UE requires an WIM authentication code for the onboard key pair generation.

NOTE 1: It is not mandatory to generate a key pair for each enrolment procedure, and the WIM can not require WIM authentication code for generating the key pair. In these cases, the WIM authentication code is not needed.

2. Initial WIM authentication code request (UE to PKI portal) – see example in table E.3.2-1

The UE sends an HTTP request to the PKI portal containing a WIM authentication code request.

Table E.3.2-1: Initial WIM authentication code request (UE to PKI portal)

GET /enrol/wim-auth-code?request=error:AuthReq:123456789ABCDEF:AABBCCDDEE 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 of this GET request. The Request-URI contains the parameter "request" which contains the WIM authentication request parameter received from the WIM, i.e. a static string "error:AuthReq:" appended by the WIM serial number in hexadecimal format, colon ":", and the challenge data in hexadecimal format.

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 2: This step is used to trigger the GBA-based authentication between the UE and the PKI portal.

3. 401 Unauthorized response (PKI portal to UE) – see example in table E.3.2-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.3.2-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.

4. Generation of NAF specific keys at UE

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

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

5. Authenticated WIM authentication code request (UE to PKI portal) – see example in table E.3.2-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 as the password, and sends the request to PKI portal.

Table E.3.2-3: Authenticated WIM authentication code request (UE to PKI portal)

GET /enrol/wim-auth-code?request=error:AuthReq:123456789ABCDEF:AABBCCDDEE 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="/enrol/wim-auth-code?request=error:AuthReq:123456789ABCDEF:AABBCCDDEE ", qop=auth-int, nc=00000001, cnonce="6629fae49393a05397450978507c4ef1", response="6629fae49393a05397450978507c4ef1, opaque="5ccc069c403ebaf9f0171e9517f30e41", algorithm=MD5

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.

6. 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.3.2-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.

7. Authentication and WIM authentication code generation at NAF

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

If the verification succeeds, the WIM authentication code is taken in for further processing. The PKI portal continues processing of the WIM authentication code request according to its internal policies.

NOTE 4: The procedures for generating the WIM authentication code are outside the scope.

8. Delivery of WIM authentication code (PKI portal to UE) – see example in table E.3.2-5

The PKI portal sends 200 OK response to the UE to indicate the success of the authentication and the WIM authentication code generation. The PKI portal generates a HTTP response containing the WIM authentication code. The PKI portal can use key material Ks_NAF to integrity protect and authenticate the response.

Table E.3.2-5: Delivery of WIM authentication code (PKI portal to UE)

HTTP/1.1 200 OK

Server: Apache/1.3.22 (Unix) mod_perl/1.27

Content-Type: text/plain

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

13579BDF2468ACE

Content-Type: Contains the media type "text/plain".

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.

9. Authentication, key pair generation, and WIM authentication code request for proof-of-origin generation at UE

The UE receives the response and verifies the Authentication-Info header. If the verification succeeds, the UE can use the WIM authentication code in the onboard key pair generation with the WIM.

The WIM in the UE also requires a WIM authentication code for the proof-of-origin generation.

NOTE 5: It is not mandatory to include the proof-of-origin to certificate request of the enrolment procedure, and the WIM can not require WIM authentication code for generating the proof-of-origin. In these cases, the WIM authentication code is not needed.

10. Authenticated WIM authentication code request (UE to PKI portal) – see example in table E.3.2-6

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_NAF as the password, and sends the request to PKI portal.

Table E.3.2-6: Authenticated WIM authentication code request (UE to PKI portal)

GET /enrol/wim-auth-code?request=error:AuthReq:1122334455667788:1122334455 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

11. Authentication and WIM authentication code generation at NAF

NOTE 6: The procedures for generating the WIM authentication code are outside the scope.

12. Delivery of WIM authentication code (PKI portal to UE) – see example in table E.3.2-7

Table E.3.2-7: Delivery of WIM authentication code (PKI portal to UE)

HTTP/1.1 200 OK

Server: Apache/1.3.22 (Unix) mod_perl/1.27

Content-Type: text/plain

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

FFEEDDCCBBAA998877665544

Content-Type: Contains the media type "text/plain".

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.

13. Authentication, proof-key-origin key pair generation, and PKCS#10 generation at UE

The UE receives the response and verifies the Authentication-Info header. If the verification succeeds, the UE can use the WIM authentication code in the proof-of-origin generation with the WIM.

The WIM in the UE also requires a WIM authentication code for the proof-of-origin generation.

NOTE 7: It is not mandatory to include the proof-of-origin to certificate request of the enrolment procedure, and the WIM can not require WIM authentication code for generating the proof-of-origin. In these cases, the WIM authentication code is not needed.

14. Authenticated enrolment request (UE to PKI portal) – see example in table E.3.2-8

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 as the password, and sends the request to PKI portal.

Table E.3.2-8: Authenticated enrolment request (UE to PKI portal)

POST /enrol?response=single HTTP/1.1

Host: pkiportal.home1.net:1234

Content-Type: application/pkcs10

Content-Length: (…)

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="/enrol?response=single", qop=auth-int, nc=00000002, cnonce="6629fae49393a05397450978507c4ef1", response="6629fae49393a05397450978507c4ef1, opaque="5ccc069c403ebaf9f0171e9517f30e41", algorithm=MD5

—– BEGIN CERTIFICATE REQUEST —–

<PKCS#10 BLOB>

—– END CERTIFICATE REQUEST —–

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.

15. Authentication and certificate generation at PKI portal

If the verification succeeds, the incoming client-payload request is taken in for further processing. The PKI portal continues processing of the PKCS#10 request according to its internal policies.

NOTE 8: The procedures for generating the subscriber certificate are outside the scope.

16. Delivery of subscriber certificate (PKI portal to UE) – see example in table E.3.2-9

Table E.3.2-9: Delivery of subscriber 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-user-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-user-cert", i.e. X.509 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.

17. Authentication at UE

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