Content for TS 33.221 Word version: 17.0.0
4 Support for Subscriber Certificates
4.1 Introduction
4.2 Reference model
4.3 Network elements
4.4 Requirements and principles for issuing subscriber certificates
4.5 Certificate issuing architecture
4.6 Certificate issuing procedure
4.7 Functionality in presence of pre-certified key pair or pre-shared keys
4 Support for Subscriber Certificates p. 8
4.1 Introduction p. 8
Digital signatures can be used, for instance, to secure mobile commerce, service authorization and accounting. But digital signature by itself is not enough; there is need of a global support for authorization and charging. This TS specifies a global and secure authorization and charging infrastructure of mobile networks to support a local architecture for digital signatures.
Subscriber certificates, issued using the mechanisms described in this TS, provide a migration path towards global Public Key Infrastructure (PKI). A local architecture for digital signatures can be deployed incrementally; one operator can choose to deploy independently of the others. On the other hand, the existence of subscribers and service providers that use digital signatures makes it easier to build a global PKI.
3GPP systems shall issue subscriber certificates in order to authorize and account for service usage both in home and in visited networks. This requires specification of:
- procedures to issue temporary or long-term certificates to subscribers;
- standard format of certificates and digital signatures, e.g. re-using OMA wireless PKI specifications.
4.2 Reference model p. 8
Figure 1 shows a simple network model of the entities involved in the certificate issuing, and the reference points used between the network entities.
4.3 Network elements p. 9
4.3.1 PKI Portal p. 9
A PKI Portal shall issue a certificate for UE and deliver an operator CA certificate. In both cases, requests and responses are protected by shared key material that has been previously established between UE and a BSF.
In PKI terms, the PKI portal is a Registration Authority (RA) who authenticates the certification request based on cellular subscription. PKI Portal may also function as a Certification Authority (CA) who issues certificates. However, this task may also be done in an existing PKI infrastructure towards which the PKI Portal would function as a RA only, and the CA would be in the PKI infrastructure.
4.3.2 Bootstrapping Server Function p. 9
The bootstrapping server function (BSF) shall support the PKI portal by providing the authentication and the PKI portal specific user security settings (i.e. whether subscriber is able to enrol a certain types of subscriber certificate).
4.3.3 User Equipment p. 9
The required new functionality from UE is the support of the reference point Ua (i.e. certification enrolment protocol) that is protected using the shared keys established during bootstrapping function.
In addition UE may have the capability to generate public and private key pairs, store the private key part to a non-volatile memory (e.g. in UICC), and protect the usage of the private key part (e.g. with a PIN).
4.4 Requirements and principles for issuing subscriber certificates p. 9
The following prerequisites for issuing of subscriber certificates exist:
- the UE and the mobile operator's PKI portal share key material to support the certificate request and operator CA certificate retrieval;
- the issuing of the requested certificate is allowed according to subscriber's PKI portal specific user security setting. The PKI portal is responsible for performing this check before issuing the subscriber certificate;
- in the case that the private key is stored on a WIM [8], which is capable of providing a proof of key origin (assurance info that the key is securely stored in a tamper-resistant device), it shall be possible to send this information with the certificate request.
4.4.1 Usage of Bootstrapping p. 9
Issuing procedures of the subscriber certificate and operator CA certificate shall be secured by using shared keys obtained from the 3GPP generic bootstrapping architecture as specified in TS 33.220.
4.4.2 Access independence p. 9
Subscriber certificate and operator CA certificate issuing procedures are access independent. Certificate issuing procedures require IP connectivity from the UE.
4.4.3 Roaming and service network support p. 9
The roaming subscriber shall be able to request subscriber certificates and operator CA certificates from the home network.
The roaming subscriber shall be able to request subscriber certificates and operator CA certificates from the visited network. The home network shall be able to control whether the visited network is allowed to issue subscriber certificates to its roaming subscribers (see clause 4.4.4).
4.4.4 Home operator control p. 10
Home operator shall be able to control the issuing of subscriber certificates. The control includes to whom the certificates are allowed to issue and the types of issued certificates.
Operator control is supported by information in the GBA user security settings. For each type of subscriber certificate, i.e. for different key usage in WAP Certificate and CRL Profile [7], subscriber's PKI portal specific user security setting shall contain a flag that allows or disallows the issuing of that type of certificate to subscriber. According to WAP Certificate and CRL Profile [7], there are two types of certificates for users (i.e. subscribers): user certificates for authentication and user certificates for digital signatures (i.e. non-repudiation).
Delivery of operator CA certificates is always allowed.
4.4.5 Charging principles p. 10
The operator shall be capable to charge issuing of subscriber certificates or delivery of operator CA certificates.
4.4.6 Subscriber Certificate Profile p. 10
Subscriber certificate profile shall be based on WAP Certificate and CRL Profile [7], which in turn is based on profiles defined in RFC 3280 and ITU T X.509 [10] with the exception that the requirements on signature algorithms and key sizes in clause 6.1 of TS 33.310 shall be followed.
A certificate profile defines the format and semantics of certificates in a specific context. WAP Certificate and CRL profiles specification defines four certificate profiles: two user certificate profiles - one for authentication and the other for non-repudiation purposes, server certificate profile for authentication, and authorization certificate profile (i.e., CA certificate). Since subscriber certificates are issued to users, and since services need CA certificate to validate subscriber certificates, the relevant WAP certificate profiles to be used with subscriber certificate profiles are the user certificate profiles, and CA certificate profile.
Qualified certificate profiles by IETF [17] and ETSI [18] may also be used as the subscriber certificate profile if the certification practices followed by the certificate issuing operator fulfil all of the requirements stated in [16] ,[17], [18].
The following certificate extensions may be filled with the information given by the UE in the certification request:
- Intended certificate usage (i.e. using keyUsage and/or extKeyUsage extensions [7]).
- Subscriber identities (i.e., subject name field, and possible additional identities defined in the subjectAltName extension [7]). Operator CA shall authorize each suggested subscriber identity.
- Proof of key origin (i.e., keyGenAssertion). Operator CA shall verify the proof of key origin if it is presented.
4.4.7 Service Discovery p. 10
To enable the certificate enrollment procedure, the addresses of bootstrapping server and PKI portal should be configured to the UE. The BSF discovery method is specified in TS 33.220.
A procedure needs to be described on how to discover the location of PKI portal. It shall be possible to enable the UE to be configured either manually or automatically via one of the following approaches:
- The address information shall be published via reliable channel. Subscribers shall store all the parameters as part of the establishment of IP connectivity. The address information needs to be input only once.
- The address information shall be pushed automatically to the UE over the air when the subscription to bootstrapping service is accepted. All the parameters shall be saved into the UE and used in the same manner as above. The procedure is specified in OMA's "Provisioning Content Version 1.1" [19].
4.4.8 Requirements on reference point Ua p. 11
The requirements for reference point Ua are:
- UE shall be able to request for subscriber's certification from the PKI portal that plays the role of the NAF over a network connection;
- NAF shall be able to authenticate UE's certificate request;
- UE shall be able to acquire an operator's CA certificate over the network connection;
- UE shall be able to authenticate the NAF response (i.e., operator CA certificate delivery);
- the procedure shall be independent of the access network used;
- the NAF shall have access to the subscriber's PKI portal specific user security setting to check the certification policies. This means that the reference point Zn TS 33.220 shall support for retrieving a subset of the GBA user security settings;
- the response and delivery of certificate to UE shall be within a few seconds after the initial certification request;
- certification request format shall be PKCS#10;
- certification response format shall be one of the following: a certificate, a pointer to the certificate, or a full certificate chain.
4.5 Certificate issuing architecture p. 11
4.5.1 Reference point Ua p. 11
4.5.1.1 General description p. 11
In the certificate issuing, reference point Ua is used to for:
- The operator CA certifying subscriber's public keys in format of certificates; and
- The delivery of the Operator CA certificate to the UE.
4.5.1.2 Functionality and protocols p. 12
4.5.1.2.1 PKCS#10 with HTTP Digest Authentication p. 12
A PKCS#10 [1] based certification request is sent to the PKI portal using a HTTP request, which shall be authenticated and integrity protected by HTTP Digest Authentication as specified in clause 5.2 of TS 24.109.
Certificate is delivered using the HTTP response, which may be authenticated and integrity protected by HTTP Digest Authentication. The content-type of the HTTP response depends on the response format. If a certificate is returned then it is "application/x-x509-user-cert". If a pointer to the certificate is returned then it is "application/vnd.wap.cert-response" as specified in WPKI [9]. If a certificate chain is returned, then it is "application/pkix-pkipath" as specified in RFC 3546.
The UE requests a CA certificate delivery by sending a plain HTTP GET request with specific parameters in the request URI. The request may be authenticated and integrity protected by HTTP Digest Authentication.
CA certificate is delivered using the HTTP response, which shall be authenticated and integrity protected by HTTP Digest Authentication. The content-type of the HTTP response would be "application/x-x509-ca-cert". Note that the user should always be notified when a new CA certificate is taken into use.
4.5.1.2.2 Key Generation p. 12
If the private key is stored in a UICC (e.g. in a WIM [8]) and the UICC demands a special authorization (e.g. from the Operator) to generate the key, the ME may need to perform an HTTP request, which may be authenticated and integrity protected by HTTP Digest Authentication, to the NAF in order to deliver a nonce that is generated by the UICC. This will allow the NAF to authenticate directly to the UICC application and provide authorization for the key generation. The exact key generation procedure is specified in OMA's "Crypto Object for the ECMAScript Mobile Profile" [14].
4.6 Certificate issuing procedure p. 13
4.6.1 Certificate issuing p. 13
Figure 2: Certificate request using PKCS#10 with HTTP Digest Authentication
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
The sequence diagram above describes the certificate request when using PKCS#10 with HTTP Digest authentication. The actions involving WIM application in steps 3 6 shall be omitted if there is no WIM application in the UE. The procedure is secured as specified in clause 5.2 of TS 24.109. The detailed definition of the messages is left to stage 3 specifications.
Step 1.
The sequence starts with the UE sending an empty HTTP request to the PKI portal.
Step 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.
Step 3.
The UE will generate the HTTP request by calculating the Authorization header values using the bootstrapping transaction identifier (B TID) it received from the BSF as username and the NAF specific session key Ks_NAF. If the certificate request needs extra assurance by a WIM application for key proof-of-origin, the UE generates a WIM challenge request containing parameters needed for key proof-of-origin generation [14].
Step 4.
The UE sends HTTP request to the PKI portal and includes the WIM challenge request in this request.
Step 5.
When the PKI portal, acting as an NAF, receives the request, it will verify the Authorization header by fetching the NAF specific session key Ks_NAF from the BSF using the B TID, then calculating the corresponding digest values using Ks_NAF, and finally comparing the calculated values with the received values in the Authorization header. If the verification succeeds and the extra assurance for WIM application is needed, the PKI portal may use the PKI portal specific user security setting to compute the WIM challenge response [14].
Step 6.
The PKI portals send back a WIM challenge response containing additional parameters that are needed for the following PKCS#10 request generation. The PKI portal may use session key Ks_NAF to integrity protect and authenticate this response.
Step 7.
The UE will then generate the PKCS#10 request and send it to the PKI portal by using an HTTP Digest request. In the case that the private key is stored in a WIM application the ME should request the AssuranceInfo from the WIM application and include it in the PKCS#10 request, if provided. The enrolment request will follow the PKCS #10 certificate enrollment format as defined in [1]. Adding AssuranceInfo in this request is defined in the OMA ECMA Script specification [14]. The AssuranceInfo provides a proof of origin for the key processing.(e.g. identifies the WIM application and provides a proof that the key is stored in it). UE may indicate the desired format of the certification response: a certificate, a pointer to the certificate (e.g., URL), or a full certificate chain (i.e., from the issued certificate to the corresponding root certificate).
Step 8.
The enrolment request shall be as follows:
Step 9.
POST <base URL>?response=<indication>[other URL parameters] HTTP/1.1 Content-Type: application/x-pkcs10 <base64 encoded PKCS#10 blob>where:
<base URL>
identifies a server/program.
<indication>
used to indicate to the PKI portal what is desired response type for the UE. The possible values are: "single" for subscriber certificate only, "pointer" for pointer to the subscriber certificate, or "chain" for full certificate chain.
[other URL parameters]
are additional, optional, URL parameters.
The incoming PKCS#10 request is taken in for further processing. If the PKI portal is actually a registration authority (RA), the PKCS#10 request is forwarded to CA using any protocol available (e.g., CMC as specified in RFC 2797 or CMP as specified in RFC 2510 and RFC 2511). After the PKCS#10 request has been processed and a certificate has been created, the new certificate is returned to the PKI portal. It will generate a HTTP response containing the certificate, or the pointer to the certificate as defined clause 7.4 of WPKI [9], or a full certificate chain from issued certificate to the root certificate.
Step 10.
If the HTTP response contains the subscriber certificate itself, it shall be base64 encoded, and it may be demarcated as follows:
Step 11.
HTTP/1.1 200 OK Content-Type: application/x-x509-user-cert -----BEGIN CERTIFICATE----- <base64 encoded X.509 certificate blob> -----END CERTIFICATE-----If the HTTP response contains the pointer to the certificate, the CertResponse structure defined in subclause 7.3.5 of the OMA WPKI [9] shall be used, and it may be demarcated as follows:
HTTP/1.1 200 OK Content-Type: application/vnd.wap.cert-response -----BEGIN CERTIFICATE RESPONSE----- <base64 encoded CertResponse structure blob> -----END CERTIFICATE RESPONSE-----If the HTTP response contains a full certificate chain in PkiPath structure as defined in [15] and it shall be base64 encoded:
HTTP/1.1 200 OK Content-Type: application/pkix-pkipath <base64 encoded PkiPath blob>The content-type header value for the certificate chain is "application/pkix-pkipath" as specified in [15]. The PKI portal may use session key Ks_NAF to integrity protect and authenticate the response, if a certificate or a pointer to the certificate is sent to the UE. The PKI portal shall use integrity protection and authenticate the response if full certificate chain is sent to the UE.
When UE receives the subscriber certificate or the URL to subscriber certificate, it is stored to local certificate management system.
4.6.2 CA Certificate delivery p. 15
The sequence diagram above describes the CA certificate delivery when using HTTP Digest authentication. The procedure is secured as specified in clause 5.2 of TS 24.109. The detailed definition of the messages is left to stage 3 specifications.
Step 1.
The sequence starts with an empty HTTP request to the PKI portal.
Step 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 for authentication.
Step 3.
The UE generates another HTTP request for requesting the CA certificate. UE shall indicate the CA issuer name in the request URL as specified in subclause 7.4.1 of WPKI [9]. The serial number field shall be omitted. The Authorization header values are calculated using the identifier and the session key Ks_NAF. The authentication of this HTTP request is not necessary, but it is done in order to follow HTTP Digest authentication specification. Also, the identifier needs to be transported to the PKI portal.
Step 4.
The CA certificate delivery request shall be as follows:
Step 5.
GET <base URL>?in=<issuer name>[other URL parameters] HTTP/1.1Where:
<base URL>
identifies a server/program.
<issuer name>
identifies the certificate issuer. It is a base64 encoding of the DER encoded Issuer field in the X.509 certificate.
[other URL parameters]
are additional, optional, URL parameters.
When the PKI portal receives the request, it may verify the Authorization header by fetching the session key Ks_NAF from the bootstrapping server using the identifier. The PKI portal will generate a HTTP response containing the CA certificate and use the session key Ks_NAF to authenticate and integrity protect the HTTP response using the Authentication-info header. Essentially, the response could also be other delivery protocol in HTTP format, e.g. PKCS#7 cryptographic message with content type signedData.
Step 6.
HTTP response contains the CA certificate. The CA certificate shall be base64 encoded, and it may be demarcated as follows:
Step 7.
HTTP/1.1 200 OK Content-Type: application/x-x509-ca-cert -----BEGIN CERTIFICATE----- <base64 encoded X.509 certificate blob> -----END CERTIFICATE-----
When UE receives the new CA certificate, it must validate the Authentication-info header. If validation succeeds, the user is notified that a new CA certificate is taken into use. If user accepts the new CA certificate, it is stored to the local certificate management system and marked as "trusted" CA certificate.
4.7 Functionality in presence of pre-certified key pair or pre-shared keys p. 16
4.7.1 Presence of pre-certified key pair p. 16
An alternative to securing certificate enrolment based on AKA and bootstrapping function is to secure certificate enrolment based on signatures made with pre-certified key in the UE. This alternative has been specified by Open Mobile Alliance (see section 7.3.4 of WPKI [9]) and is thus out of scope of this specification. The functionality in presence of pre-certified key pair in the UE is explained below only briefly.
In this alternative solution, the UE equipped with a UICC, is previously issued with a pre-loaded, long lasting, public/private key pair from the home network. This phase would occur out of band, and would result in the UE possessing a long lasting key pair stored in the UICC for the purposes of certificate request authentication. Open Mobile Alliance (OMA) group offers standardized solutions by means of WPKI specification [9] and WIM specification [8] for the storage and the use of long-lasting key pair. USIM and WIM are examples of applications on the UICC that can deal with the long-lasting keys.
The UE can issue a request for a certificate to the CA, including a proof of origin (e.g. private key is stored in WIM) by using an administrative long lasting private key. The certificate request itself could contain a newly generated public key that is to be certified by the CA. This assumes that the new key pair is generated in the UICC. Access control security for the pre-loaded long-lasting private key should be at least as good as for access control for USIM.
The certificate for the administrative long lasting private key, that provides the proof of generated key origin, is always long lasting certificate. On the other hand the generated user keys in the WIM may have short or long-lived certificate depending on CA policies (see OMA's WIM [8], WPKI [9] and ECMA script [14] specifications).
4.7.2 Presence of symmetric pre-shared key p. 17
Same as above but the administrate key that provides the proof of generated key origin is a shared symmetric key, in which case it does not have a certificate (see OMA's WIM [8], WPKI [9] and ECMA script [14] specifications).
