Hi, We will be presenting the proposal below at the LIR-WG at RIPE 35. Comments are most welcome. Cheers, Olaf and Maldwyn -- The use of PGP for the encryption and authentication of e-mails to and from the RIPE NCC hostmaster mailbox. Olaf M. Kolkman Maldwyn G.T. Morris February 2000. -------------------- A. Introduction The RIPE NCC has received requests to enable customer Local Internet Registries ( LIRs ) to use PGP for authentication and encryption of e-mails to hostmaster@ripe.net. We have tried to identify the possible uses for PGP in communication between the LIRs and the RIPE NCC hostmaster mailbox and tried to determine what risks and operational difficulties there are in using PGP for both the LIRs and the RIPE NCC. In this document we will present our ideas and a possible implementation. We assume that the reader is familiar with PGP and the related protocols and terminology. Note that: - we are not security protocol experts; we welcome all comments and will, in a later stage of the design, involve security experts. - the use of the proposed technology would be optional for our customer LIRs. -------------------- B. Uses of PGP. For e-mail exchange between the RIPE NCC and the LIRs we identify four possible uses. 1. Encryption of e-mails to the RIPE NCC. Means LIRs can send company confidential information to the RIPE NCC without the risk of it being read when traversing the Internet. 2. Authentication of e-mails from the RIPE NCC. Means LIRs can be sure the mail came from the RIPE NCC. Non-repudiation of signed mails is also a benefit for the LIR in case of conflicts. 3. Encryption of e-mails to the LIR. Means LIRs can send company confidential information to the RIPE NCC without the risk it being read when traversing the Internet when included in RIPE NCC replies. 4. Authentication of e-mails from the LIR. Means it is much harder for a 3rd party to impersonate a LIR. Items 1 and 2 are relatively easy to implement. The RIPE NCC needs to publish the public RIPE NCC key and needs to design an internal infrastructure that prevents unauthorised persons from using the private RIPE NCC key. LIRs will be able to make use of these methods without contacting the RIPE NCC to arrange it in advance. More on the design of the RIPE NCC internal infrastructure in section C.1. and C.2. below. Items 3 and 4 are more difficult to implement. Here the RIPE NCC has to be sure that a certain key did indeed originate from the LIR the mail purports to be from. To use these methods, LIRs will have to give RIPE NCC their public keys in advance and in section D below we describe a protocol for key exchange that makes it difficult to impersonate a LIR. The RIPE NCC will not sign any of the public keys of the LIRs i.e. it will not become a Certification Authority. -------------------- C Protocols and implementation for items 1 and 2: Encryption of e-mails to the RIPE NCC and authentication of e-mails from the RIPE NCC. C.1. The LIR's side. not need to have it own key-pair it only needs to obtain suitable software and RIPE NCC's public key to encrypt messages to RIPE NCC or authenticate messages from RIPE NCC. C.2. The RIPE NCC side. The RIPE NCC will publish its public key on its ( secure ) webserver. We will allow further authentication of our public key by reading its fingerprint at the RIPE meeting, printing the fingerprint on the invoices we send or by other broadcast methods. The RIPE NCC does not want to share its private key among multiple employees, but on the other hand the RIPE NCC does not want to revoke individual keys whenever employees take on other functions. We have chosen to use one RIPE NCC key for company-wide authentication and decryption. The RIPE NCC will keep its private key on a dedicated internal signing server. Using strong authentication methods ( probably SSH ), RIPE NCC employees will be able to open an authenticated connection to the box that will perform a decryption or a signing operation. The request will be logged to leave an audit trail. The signing server will need to be highly secured. To prevent possible long-term damage if the machine ever gets compromised, the RIPE NCC key will expire every n-years. A key revoking procedure, which will include a public message, will be in place. Using this setup we can ensure individual RIPE NCC employees ( except for the limited set of people having system level access to the server ) will not be able to read the private RIPE NCC key. We also have the flexibility to control who can sign and decrypt RIPE NCC mail. -------------------- D. Protocols and implementation for items 3 and 4: Encryption of e-mails from the RIPE NCC and authentication of e-mails to the RIPE NCC. Before describing the protocol and implementation details in section D.1. and D.2. some general remarks and requirements. Currently, authentication is based on mail addresses and the reg id contained in the e-mails, and on the common sense of the RIPE NCC hostmasters. After RIPE NCC implements this part of the project, LIRs will have to be able to choose to use PGP to authenticate themselves to the RIPE NCC. Once they have made that choice the RIPE NCC will not accept non-PGP authenticated communication from that particular LIR. The most important application is to prevent impersonation. Therefore we need a procedure to assure ourselves that a public key belongs to the LIR which is claiming to have sent the e-mail. If a malicious third party ( Mallet ) tries to submit a public key in the name of a LIR ( zz.alice ) then a number of things can go wrong: - Once we start using Mallet's key, zz.alice's non-authenticated messages will not be accepted by the RIPE NCC. - RIPE NCC might start sending zz.alice information encrypted with Mallet's key which zz.alice will not be able to read and Mallet might also intercept this traffic and extract confidential information. To prevent the LIR having to use "group" keys we have set the requirement that a LIR should be able to add and revoke keys for their employees. D.1. LIR keys and key exchange protocol. We are studying two methods for key exchange and we will have a security expert look at this before implementation. In both methods of key exchange the LIR will need to begin by creating a public/private key pair, we refer to these as the LIR's Master keys. The key exchange method ( see below ) defines how these Master keys are authenticated. Once the Master key has been authenticated, the LIR can create keys for their employees. The employees' public keys must be signed by the LIR's Master key and sent to the RIPE NCC before they can be used for mails to RIEP NCC. The LIR's Master key can be used: - for authentication of mails to hostmaster@ripe.net - as a decryption key for mails from the RIPE NCC. - for adding and revoking employee's keys with the RIPE NCC - to tell the RIPE NCC that the LIR no longer wishes to use PGP authentication. The LIR's employees' keys can only be used: - for authentication of mails to hostmaster@ripe.net - as a decryption key for mails from the RIPE NCC. In this way the LIR has control over who is permitted to communicate with the RIPE NCC. First proposed key exchange method. We use a secret ('billing-secret'), sent with the paper invoice that the LIR receives by surface mail. The LIR will send us an e-mail signed using its private Master key and containing the 'billing-secret' and its public Master key. Once we receive the key we will send a confirmation to the LIR contact address and from then on we will only allow PGP authenticated communication with that LIR. Using this method we put trust in the billing address to be correct and the surface-mail not being intercepted. Second proposed key exchange method. The LIR will sign the public Master key with the private Master key and send this signed public Master key to the RIPE NCC. The RIPE NCC will use the LIR's public Master key to check the signature and then send a secret string to a LIR contact. The LIR contact will reply to the RIPE NCC with a mail containing the secret signed with the Master key. From the moment the RIPE NCC receives the secret back we will only allow PGP authenticated communication with that LIR. Using this method we put our trust in the fact that the contact information is correct and that the e-mail to the LIR cannot be blocked and intercepted In both methods it could happen that just before doing the key exchange our malicious friend Mallet changed the the contact details using the current weak authentication method. This could result in Mallet impersonating LIR zz.alice. We think the chance of this happening is small. Being aware of this vulnerability in the protocol we can, if in doubt, use other methods to convince ourselves that the LIR's Master key actually comes from zz.alice. We think the extra costs involved in using these methods preclude their use in every case. There is a risk that the LIR's Master key gets lost and if that happens we will have to use an off-band mechanism to revoke the LIR's key. This may involve for example, a fax with the LIR's letterhead and a phone call to the LIR contact. D.2. RIPE NCC's implementation. RIPE NCC will implement this using dedicated key rings or a keyserver. So as not to risk RIPE NCC being seen as a Certification Authority the key ring or keys server will be for internal use only. The interface to it will be a mail robot. This is to prevent people uploading unneeded keys. The hostmaster mail robot will test if PGP encryption or authentication is used and will bounce non-PGP authenticated mails from those LIRs who use PGP authentication. Once mails are processed by the robots they are believed to be authenticated as coming from the LIR whose reg id is contained in the e-mail. The robot will also decrypt encrypted incoming messages on arrival. We will think further about whether encryption of outgoing e-mails should be the default or only an option ( for LIRs who have sent us their public keys ). The local copies of all communication will be kept in plaintext, with appropriate access permissions. -------------------- E. Final remarks. We are thinking of using OpenPGP for the basis of this project. The RIPE NCC will not support LIRs in setting up and or maintaining (Open)PGP but we will produce a general guide that should clearly explain what they need to do. PGP might, because of local law, not be available to all LIRs.