Estructura de costos

As specified by [TS33.221] the NAF can function as a PKI portal issuing sub- scriber certificates. This has been adopted for the interface Ua* implementation. Supported browsers are Mozilla-based browsers as well as the Microsoft Internet Explorer. Figure4.9gives an overview of the network model for issuing subscriber certificates via the interface Ua*.

A Public Key Infrastructure (PKI) can be described as a set of hard- and soft-

Ub* Ua* Zh Zn HSS EJBCA UE HTTP2IMS GW (BSF) PKI Portal (NAF)

Figure 4.9: The Modified GBA Infrastructure for PKI Support and Certificate Issuing

ware components including policies, unified processes and servers to administer, verify, and certify user identities. This is done using digital certificates and public key cryptography (public-private key pairs). PKIs are generally able of issuing, maintaining, and revoking public key certificates and are used to establish a se- cure chain of trust for Internet-based communication. PKIs usually include a Certificate Authority (CA), a Registration Authority (RA), a key directory and management/provisioning tools.

A CA issues certificates to, and vouches for the authenticity of entities. The level of trust you can assign to a CA is individual, per CA, and depends on the

CAs policy and practices statement. A RootCA has a self-signed certificate and is also called Trusted Root. Verification of other certificates in the PKI ends with the RootCAs self-signed certificate. Since the RootCAs certificate is self-signed it must somehow be configured as a trusted root with all clients in the PKI. [wwwEJBCA] The value of a PKI depends on how trusted the RootCA is. As pointed out before, modern web browsers dispose of a number of pre-installed root certificates from various companies that maintain a RootCA. Theese CAs can mostly be trusted as their business depends on being trustworthy.

An RA is an administrative function that registers entities in the PKI. The RA is trusted to identify and authenticate entities according to the CAs policy. There can be one or more RAs connected to each CA in the PKI. [wwwEJBCA]

The NAF provides PKI functionality in terms of issuing subscriber certificates based on the authenticated identity of a subscriber. In order to provide the PKI functionality, an OSI Certified15 _{Open Source Software called Enterprise Java}

Beans Certificate Authority (EJBCA) has been used. The EJBCA sources are hosted on Sourceforge.net16 _{and all downloads include the complete source code.}

The Enterprise Java Beans Certificate Authority is an advanced open source CA- implementation that is a fully functional Certificate Authority. EJBCA imple- ments the CA part of a PKI according to standards such as X.509 and IETF- PKIX. As such it follows the general PKI concepts closely. The administration of the PKI has some EJBCA-specific concepts in order to implement unique flexibil- ity. [wwwEJBCA]

The setup and installation process of the EJBCA is very well documented in the documentation that can be obtained from the downloaded source files or online at

http://docs.primekey.se/documentation/en/installation.html. EJBCA re- lies on:

• JDK 1.4.x or 1.5.x 17

• Unlimited Strength Jurisdiction Policy Files for your JDK 18

• JBOSS >3.2.6 or 4.0.x (latest tested verison is JBoss 4.0.2) 19

• Ant 1.6.x to build 20

15_{OSI Certified is a certification mark of the Open Source Initiative} 16_{http://sourceforge.net/index.php} 17_{http://java.sun.com/javase/downloads/index.jsp} 18_{http://java.sun.com/j2se/1.5.0/download.jsp} 19_{http://labs.jboss.com/portal/} 20 http://jakarta.apache.org/ant/

The above prerequisites need to be installed and configured appropriately before EJBCA can be connected to the NAF. The installation of the EJBCA itself in- cludes:

• Compiling, jar, war, ear the sources and deploying everything to JBoss

• Generate all certificates, keys, etc needed to run with an initial CA. Ad- ministrative privileges (e.g. root) are needed for the CA-certificate to be installed in Javas trust-keystore.

• Import the super administrators certificate in your web browser which is used to access the admin GUI.

For a detailed description of how to setup EJBCA, please refer to the online doc- umentation 21_.

The interface between PKI Portal (NAF) and the EJBCA is a HTTP interface. The EJBCA has been equipped with a servlet that accepts any incoming post, creates a user with a unique username, and instantly sends back the corresponding certificate. This servlet is used by the PKI Portal (NAF) to obtain the desired subscriber certificates. Authentication is not needed at the EJBCA servlet, as the NAF carries out authentication of the user and only requests certificates for authenticated users. The PKI portal functionality of the NAF can be accessed via the HTTP2IMS GW where a link has been placed that points to the NAF using a special URL parameter that is recognized by the NAF. The NAF starts the PKI service upon receiving the URL parameter. Figure 4.7 depicts the NAF PKI service (Certificate Enrollment Service) as one of the services that can be chosen from the list of available services.

Subscriber certificates can be used where desired for certificate-based mutual au- thentication between a UE and an AS. If UE and AS are both in possession of a subscriber certificate, the UE may establish a TLS tunnel with the AS as specified in [RFC2246]. Note that for this thesis it was assumed, that a client cannot di- rectly access an AS. This is true for ASs residing within the FOKUS Playground network. For external ASs however, certificate-based mutual authentication has been identified to be a useful feature for the future. This is why this has been implemented as part of this thesis.

21

4.3.4 Zn Interface

The Zn interface has already been discussed in section 4.2.5 from the BSF point of view, where the BSF listens for a NAF initiated Diameter message exchange. The NAF implementation contains the class de.fhg.fokus.gba.naf.DiameterServer which has a public method runZn that handles the Zn communication with the BSF. It generates a Diameter BIR and sends it to the BSF. The class de.fhg.fokus.dia meter.zn.ZnCommandListener has been implemented to listen for a Zn response from the BSF. The listener notes if a Diameter message with code 310 has been received. The NAF runs some checks on the received response, if this is a valid BIA and, in the successful case, tries to read the delivered values from the relevant AVPs.

The message format of BIR and BIA can be found in Appendix B. The most important values received form the BSF via the Zn interface are the key material inside the ME-Key-Material-AVP or UICC-Key-Material-AVP and the GUSS in- side the GBA-UserSecSettings-AVP. For further information on the Zn interface, please refer to Appendix B or [TS29.109].