Shane Kerr
Andrei Robachevsky
Tiago Antao
There is a need for secure communication between the RIPE NCC and its members. This document presents an overview of the current communication system, and a new approach based on X.509 PKI (Public Key Infrastructure) technology and standards that will make interaction with the services provided by the RIPE NCC to its members more convenient and secure. Finally, the phases necessary to implement the system are described.
1.0 Current Communication System
1.1 Main Components of the Communication System
1.2 Drawbacks of the Current Setup
2.0 Goals of the Project
3.0 Improved System
3.1 Main Features
3.2 PKI Model for the New System
3.3 Integration with the RIPE NCC Services
3.3.1 LIR Portal
3.3.2 RIPE Database
3.3.3 Secure Communication with RS
3.3.4 Reverse Delegation
3.3.5 Billing
3.3.6 DNSSec
3.3.7 Integration Among Services
3.3.7.1 Database Integration
3.3.7.2 Reverse Delegation and Database Integration
4. Project Phases
4.1 LIR Portal
4.2 Database X.509 Support
4.3 Database / LIR Portal Interaction
4.4 Hostmaster Robot(s)
4.5 Reverse Delegation Robot
4.6 Future Services (Billing, DNSSec)
Many services that the RIPE NCC provides for its members have requirements of authentication, non-repudiation, data integrity, data confidentiality, and access control. Over time these security requirements become increasingly important. As stated in the RIPE NCC Activity Plan for 2003 "particular attention will be dedicated to the security aspects of such interactions [with the RIPE NCC's systems] to ensure privacy and authentication wherever needed".
This document describes an approach based on X.509 PKI technology and standards to make interaction with the services provided by the RIPE NCC to its members more convenient and secure.
While improving the security of the communication system it is also important to make interaction with RIPE NCC services or systems more flexible and convenient for users.
To achieve these goals the communication system should be based on stable and well deployed industry standards and best practices.
It is important to note here that X.509 PKI is used as technology to facilitate the interaction of RIPE NCC members with the services provided by the RIPE NCC. It is outside the scope of this project to setup a fully functional third-party Certification Authority (CA) and provide X.509 PKI services that are not necessary to the specific goals of this project.
There are several subsystems in the RIPE NCC service portfolio provided for members that require authentication, non-repudiation, and data confidentiality.
Registration Services (Hostmaster)
Most of the interactions between a contact member of a Local Internet Registry (LIR) and a RIPE NCC Hostmaster take place via e-mail. Requests are authenticated based on the e-mail address of the originator, which is a very weak form of authentication. Non-repudiation and data integrity requirements are only supported from the RIPE NCC: all e-mails sent to a member are signed with the RIPE NCC PGP key. At the moment it is not possible to authenticate a member using a digital signature, or to send information back to a member in encrypted form.
RIPE Database
Historically the RIPE Database has supported multiple methods of authentication, starting with the weakest (such as NONE) and moving up to the strongest, the PGP signature. Over the last year, one of the weakest forms of authentication - MAIL-FROM - was phased out leaving NONE, CRYPT-PW, MD5-PW and PGPKEY as supported authentication methods. Unfortunately PGPKEY cannot be used with webupdates, a graphical user update interface that makes interactions with the RIPE Database more user friendly.
LIR Portal
This service provides users with increased and simplified access to RIPE NCC services and LIR data via a customised web interface. Authentication and access control for the LIR Portal are password based. Data is exchanged via a secure channel using SSL technology (server-side certificate).
Reverse delegation Robot
Authorisation of reverse delegation requests is based on the LIR designation specified in the e-mail.
As can be see from the overview in section 1.1, there are different security levels for accessing different components. This means that a user has to maintain different types of authentication tokens and sometimes must downgrade to a weaker one for simplicity. There is no possibility at the moment to provide a single sign-on mechanism to access the RIPE NCC service portfolio.
Due to the diversity of the types of credentials used, it is very difficult to provide support for credentials management. This may mean that members cannot control access to RIPE NCC services at their end.
Another serious drawback is that some of the access methods are not strong enough from a security point of view. In some cases, moving to a more secure access method would only be possible with a redesign of the system.
The goal of the project is to make improvements to the current communication system focusing on the following areas:
Access to the services and data
The goal in this area is to make communication faster and easier by introducing stronger and more uniform security mechanisms. This will make it easier for the user to maintain and use their security tokens and will allow the seamless use of some of the advanced interfaces (such as web-based interfaces) with strong security support.
Privilege management
The system will provide unified privilege management support for the users. X.509 PKI certificates used in the system as security tokens have intrinsic revocation and expiry mechanisms that, together with support for their maintenance, make the system less vulnerable.
Minimal deployment and maintenance efforts for the users
Based on an industry standard and being well deployed in commercial and open source software, the communication system will require no additional client-side software.
It is also important to note that transition to the new system will be implemented gradually and backwards compatibility will be preserved. Users will be able to use their current setup to access services they have at the moment.
Technologically the improved system is based on a X.509 Public Key Infrastructure.
The highlights of the new system are:
The new system will be based on an X.509 Public Key Infrastructure.
For each LIR a certificate with administrative powers will be issued. With that certificate an LIR can issue certificates to its own users with varying permissions per user.
One of the most fundamental problems with X.509 PKI is trusting that a third party requesting to be certified as a LIR is what they claim to be. To solve this problem a Registration Authority (RA) has to be put in place.
Another problem is the actual issuing of a certificate. This issuing must be done in a secure and reliable way by a Certification Authority.
The administrative user of the LIR will be able to grant and revoke privileges to the LIR's certified users. This information will be generally available to the various subsystems, as such a component that will make permission information available to the whole IT infrastructure of the RIPE NCC. This component, a Privilege Management System (PMS), is not a standard of typical PKIs.
It will be possible for LIRs to specify the level of security that they desire in their communications with the RIPE NCC. As an example, an LIR might want to use signed and encrypted mail when communicating with the Billing Department but might consider it sufficient to use plain text (unsecured) mail when communicating with Registration Services. A final component, the Communication Preference Management System (CPMS), will make available (internally to the RIPE NCC) the LIRs' preferences in regards to the level of security desired.
As such the following new components will be part of the secure communication system infrastructure:
The CS, CPMS, PMS and CR are components where the fundamental issues are technical, whereas the RA has policy points.
When a party contacts the RIPE NCC requiring a certificate with administrative purposes for an LIR, a procedure has to be followed to ensure that that person has the right to hold an administrative certificate for the LIR. The secure communication system will use the procedure in place for the LIR Portal, as a user that is verified as an LIR Portal administrator can request a certificate after authenticating (using username and password) on the LIR Portal (see https://lirportal.ripe.net/lirportal/activation/activation_request.html).
For certificates to be used by users, the RA is the administrative user for the LIR (which holds a certificate that has administrative permissions on the PMS). The LIR administrative user will be responsible for authorising the issuing and revocating certificates to users. The certificate users will have to be LIR Portal users.
This secure communication system will have an impact on many existing RIPE NCC services, and that impact is assessed here. In each case, the specific proposals will be presented to the community for discussion.
The integration of the LIR Portal with the secure communication system will have two dimensions:
Regarding the first point, it will be possible to login to the LIR Portal using client-side certificates and not only by using a LIR/username identifier and password. In this case users with a client-side certificate installed on their browser will not have to supply any credentials manually as the login procedure will be automated.
Some of the functions available:
The RIPE Database will have a new authentication mechanism available that will be based on a X.509 PKI.
In the first phase only certificates issued by the LIR Portal will be accepted by the RIPE Database. This means that non-LIR users will not be able to use this new authentication mechanism.
The support of this new authentication method can be done by adding a new option to the "auth:" attribute pointing to an X.509 PKI Distinguished Name.
There will be no need for a new type of key-cert object, as a copy of the issued certificates will not be needed (checking the embedded signature of a presented certificate is enough).
LIR users will be able to use this new type of authentication both with mail and webupdates. This means that a mechanism for updating the RIPE Database, more secure than using passwords, will be available via the web. The PGP mechanism currently available cannot be easily used on the web as it is not supported by standard web technologies.
It will be possible to communicate securely with Registration Services. The level of security can be chosen by the LIR. The following dimensions can be chosen:
(*) If this option is not chosen, the communication will be PGP signed.
The LIR can choose from a variety of configurations: from the current no authentication, no confidentiality scheme to a two-way authenticated, signed and encrypted communication.
For each specific communication the LIR user can upgrade the security level if necessary: for example, an LIR that requires only X.509 PKI authentication can require confidentiality in a communication that involves the transfer of sensitive data.
An LIR will be able to declare that any changes to its reverse delegation information will have to be authenticated via X.509 PKI. This will mean that all requests from that LIR will have to be signed to be accepted.
Further, reverse delegation information modifications will be supported through the LIR Portal. The same authentication and encryption that applies to the LIR Portal will apply to reverse delegation.
Billing invoices could be sent, at the LIR's request, signed and/or encrypted. All communication could proceed as in the Registration Services example given above in 3.3.3.
DNSSec will use PKI as its authentication mechanism. The user will be authenticated and if the user belongs to the LIR to which the IP space of the request is allocated, the user will be authorised to make changes.
The deployment of a X.509 PKI infrastructure will allow not only the usage of a single authentication mechanism between LIRs and all RIPE NCC's services but also a better integration between those services, with single-sign on and authentication passing mechanisms. This integration will be done mostly via the LIR portal. A few examples of integration among services are:
An LIR Portal user whose certificate is also an authentication mechanism for one (or more) maintainer objects will be able to transparently use webupdates without proving any other authentication token. This is an example of a single sign-on integration.
Using the LIR Portal it will be possible to change reverse delegations that are related to the LIR. This will be possible if the authentication is the same for both the LIR Portal and the objects maintained in the RIPE Database. The process will be transparent to the user and will be made possible by using authentication passing between systems that now have an integrated authentication mechanism.
Rough outlines for the various phases of implementing the Improved Secure Communication System (X.509 PKI) for RIPE NCC are given below. The exact delivery and scope may change based on member feedback.
The LIR Portal integration must be implemented first. This is necessary since the LIR Portal is where certificates are issued. This will be completed before RIPE 45.
This is where the RIPE Database is modified to allow the use of X.509 PKI certificates. The exact mechanism will be designed in conjunction with feedback from the RIPE Database Working Group. It is expected that implementing this will take only a few weeks, and should occur shortly after RIPE 45.
Users should be able to update the database through the LIR Portal. This means the database will have to be modified to allow "proxy authentication". Users who have authenticated themselves to the LIR Portal, should not have to re-authenticate themselves when they change database objects. The database will need a mechanism to ensure the portal has authenticated properly. This will be done as part of the ongoing LIR Portal development, expected during the second quarter of 2003.
Automatic mail processing must be able to determine whether a certificate for an e-mail is a valid identifier for the given LIR, and handle encrypted e-mail. It is expected that these changes will be made in the third quarter of 2003.
The robot needs to be able to determine whether a certificate for an e-mail is a valid identifier for the given LIR. These changes are expected to be made in the third quarter of 2003.
These changes can be expected to occur in the fourth quarter of 2003, and will be shaped by the feedback received from LIRs, as well as the state of DNSSec.