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(a)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(a)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(a)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.
