search:

7   AAI and Mobility

The activity AAI and Mobility operates in three areas:

• development of a roaming infrastructure,
• promotion of authentication and authorisation federations,
• development of a public key infrastructure.

Our work in all three areas is closely coordinated with related European and world-wide activities. The international cooperation stimulates the progress at the national level and helps with defining priorities of individual tasks.

7.1   Inter-Institutional Roaming of Users

2005 was an important year for the development of inter-institutional roaming of academic users. Within the pilot of the eduroam.cz project [Sov04], five new institutions and sites were connected to the national roaming infrastructure. Table 7.1 lists institutions participating in the pilot by the end of the year. Thousands of users can now access the Internet using wireless networks of the participating organisations.

The ever-growing popularity of the project can be documented by the number of institutions that plan to connect during 2006 after they equip their sites with appropriate hardware.

Most users and administrators of connected networks consider the service provided by the eduroam.cz project to be close to production quality. Hundreds of active users are offered the expected service - Internet connectivity - not only in the Czech Republic but also in networks of partner organisations in Europe and other regions. However, before starting the real production service, we have to resolve several issues.

Operating the infrastructure for an ever-increasing number of participating institutions and sites requires a robust, high-quality monitoring system. We implemented an automatic system for supervising IPsec connections between individual RADIUS servers. The system verifies the accessibility of RADIUS servers and sends daily statistics to their administrators. With the help of this system we were able to achieve a nearly 100% availability of the infrastructure in spite of partial problems in stability and robustness of some IPsec implementations.

The authentication functionality itself is being monitored by the central CESNET supervising system Nagios. This system tests the RADIUS servers every five minutes by sending them authentication requests. Network monitoring staff and system administrators can access the results at the central monitoring server saint.cesnet.cz. So far, we have used the standard Nagios plugin for RADIUS. Due to its limitations, we cannot verify the authentication mechanisms commonly used by users connecting to the network (EAP/TTLS, EAP/TLS, PEAP/MSCHAPv2, ...). To overcome these limitations, we implemented new plugins capable of using any of the authentication mechanisms currently used by 802.1x supplicants. We plan to deploy the new plugins in the beginning of 2006.

We share our experience on RADIUS server monitoring with our colleagues within the TF-Mobility group of TERENA where we prepare a global monitoring system for the eduroam project.

After evaluating the results of the eduroam.cz pilot [Fur05], we decided to launch a second phase that will focus on completing the monitoring system and its integration into the emerging international structures.

7.2   Authentication and Authorisation Federations

The basic idea of an authentication and authorisation federation is simple: The federation consists of a set of institutions that agree on joint utilisation of resources and mutually accept their local authentication and authorisation mechanisms and procedures. A user belonging to one of participating institutions can thus use services provided by any other member of the federation without being required to register and authenticate himself or herself as a local user of the service provider. The authentication and the data needed to conclude an authorisation decision are provided by the user's home institution.

A federation is defined on several levels, from communication protocols and data formats through semantics of exchanged data to operational and organisational rules and policies. Considering the existing broad international cooperation, the setup of a national federation should reflect the situation in the European and global contexts. The task of setting up authentication and authorisation federations (and federations of federations) is being addressed within TERENA (by the TF-EMC2 group) as well as within the EU project GN2 (by its JRA5 group). Some of the Grid projects constitute specific federations. We closely cooperate with these communities to ensure compatibility of the future national federation with the international activities.

A federation requires the existence of local authentication and authorisation systems as its basic prerequisite. The choice of such a system is up to individual institutions. The evaluation of WebAuth, one of the potential candidates, is described in [Gro05]. The WebAuth system is used by the University of West Bohemia.

The process of building an authentication and authorisation federation is demanding at all levels. However, the existing federation infrastructure of the eduroam.cz project can be successfully used for certain specific tasks. For instance, the SIP Telephony project successfully uses the authentication provided by eduroam when registering its users.

7.3   Public Key Infrastructure

The original root certificate of the certificate authority CESNET CA expires on June 27, 2006. Since the validity of certificates for end entities was set to 12 months, the transition to the new root certificate had to happen before June 27, 2005. In the beginning of 2005, EUGridPMA (an international body by which the CESNET CA is accredited) announced several important changes of their minimal requirements on CAs. We decided to take the advantage of this favourable time coincidence and replaced the current CA infrastructure with a new one that would better suit the new requirements.

The old CA was implemented as an off-line system on a disconnected workstation - high security of the system was thus achieved at the price of high demands on operational personnel. All certificate signing requests as well as revocation requests had to be manually transferred to the CA workstation on removable media; issued certificates and revocation lists had to be transferred back and copied to publishing servers. This operational mode did not allow for continuous 24/7 operation of the certificate authority and often resulted in delays of up to several-days (especially during weekends) before the certificates and revocation lists could be issued.

Based on this experience, we decided to implement the new CESNET CA system as an on-line certificate authority. EUGridPMA requires utilisation of a hardware security module (HSM) certified to at least Level 3 of the FIPS 140-2 standard for storing private keys of on-line CAs. To provide our users with a secure, robust, and comfortable environment we chose the Entrust products: Entrust Authority Security Manager for the CA system and Entrust Authority Enrollment Server for Web as the end user interface. Luna CA3 HSM from SafeNet was chosen for private key storage - the HSM has the appropriate certification and is supported by the Security Manager.

Entrust products are usually characterised as a fully integrated PKI environment for commercial or government institutions. We realised that the requirements of CESNET CA as a more or less open service may in some cases be different. To meet those requirements and to support the workflow corresponding to our needs, we prepared a service system named LAI that enables users to submit certification data via WWW interface.

Properties of the OpenSSL software toolkit, which is used by a majority of Grid applications, demanded a change of the namespace for the new CA. Subjects of new certificates are created within the dc=cesnet-ca,dc=cz data information tree.

The whole system was started on June 17, 2005. The new CESNET CA architecture is depicted in Figure 7.1.

A certificate is issued in the following steps:

1. The subscriber provides data to be included in the certificate via the WWW interface of LAI.
2. The system assigns a Distinguished Name (DN) to the end entity. The end entity entry is inserted into the LDAP database.
3. The subscriber visits a Registration Authority officer and provides requested documents. (Requests for server certificate issuance may be sent in a signed email.)
4. Registration Authority officer crosschecks the contents of the end entity LDAP entry.
5. Provided that all checks have been successful, the officer imports the request into the internal database of the Security Manager, generates access codes for certificate issuance and hands them over to the subscriber. (Access codes for a server may be sent in an encrypted email.)
6. The subscriber submits the access codes and the certificate signing request via a web form to the Enrollment Server for Web. (The request may be automatically generated by the subscriber's browser.)
7. The Enrollment Server for Web passes the data to the Security Manager. The Security Manager issues the certificate and
8. publishes it as a new record in LDAP.

Technical details of the LAI system are described in [Tom05].

During the system implementation we found out that communication between Entrust components (the Registration Authority, the Certification Authority) and the LDAP server is not encrypted. As an interim measure against this deficiency, we added external encryption by means of stunnel software. Entrust plans to implement encrypted communication in the next version of their products.

One of the main reasons for deploying the new CESNET CA system was to make the process of obtaining certificates easier for end users. However, some of the existing users found certain parts of the new interface non-intuitive and surprising. Based on their feedback, we will improve the WWW interface to satisfy their needs.

One of the pitfalls of any PKI deployment is the secure management of users' private keys. One solution to this problem may be to provide the users with hardware encryption tokens. Such a token holds the private key securely protected by a password (the key never leaves the token) and performs cryptographic operations on behalf of the user. We evaluated several types of those types of devices from the perspective of both users and Registration Authority officers. The evaluation results are described in [Jin05]. We plan to equip RA officers and selected users with the tokens in the beginning of 2006 after consulting the issue with EUGridPMA.

previous

contents

next