Internet DRAFT - draft-zsako-ripe-dbsec-pgp-authent
draft-zsako-ripe-dbsec-pgp-authent
RIPE DBSEC Task Force J. Zsako
INTERNET-DRAFT BankNet
<draft-zsako-ripe-dbsec-pgp-authent-00.txt> July 1998
PGP authentication for RIPE database updates
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Abstract
This document presents the proposal for a stronger authentication
method of the updates of the RIPE database based on digital
signatures. The proposal tries to be as general as possible as far as
digital signing methods are concerned, however, it concentrates
mainly on PGP, as the first method to be implemented. The proposal
is the result of the discussions within the RIPE DBSEC Task Force.
1. Rationale
An increasing need has been identified for a stronger authentication
of the database maintainer upon database updates (addition,
modification and deletion of objects). The existing authentication
methods have serious security problems: the MAIL-FROM has the
drawback that a mail header is very easy to forge whereas CRYPT-PW is
exposed to message interception, since the password is sent
unencrypted in the update mail message.
Zsako [Page 1]
Draft PGP authentication for RIPE database updates July 1998
The goal was to implement a digital signature mechanism based on a
widely available and deployed technology. The first choice was PGP,
other methods may follow at a later date. PGP is presently quite
widely used within the Internet community and is available both in
and outside the US.
The current aim is for an improved authentication method and nothing
more (in particular, this paper does not try to cover authorization
issues other than those related to authentication).
2. Changes to the RIPE database
In order to make the database as much self consistent as possible,
the key certificates are stored in the RIPE database. For efficiency
reasons a local keyring of public keys will also be maintained,
however, the local keyring will only contain a copy of the key
certificates present in the database. The synchronization of the
database with the local keyring will be made as often as possible.
The database objects will be created only via the current e-mail
mechanism (auto-dbm@ripe.net), in particular no public key
certificate will be retrieved from a key server by the database
software.
The presence of the key certificates in the database will allow the
users of the database to check the "identity" of the maintainer, in
the sense that they can query the database for the certificate of the
key the database software uses for authenticating the maintainer.
This key certificate can then be checked for existing signatures and
can possibly be compared with the key certificate obtained by other
means for the same user (e.g. from the owner himself of from a public
key server). Although the key certificates can be stored in the RIPE
database with any number of signatures, since the RIPE database is
not communicating directly with the public key servers, it is a good
practice to add the key certificate with the minimum number of
signatures possible (preferably with just one signature: the one of
itself). See also section 4. for more details.
Zsako [Page 2]
Draft PGP authentication for RIPE database updates July 1998
2.1. The key-cert object
A new object type is defined below for the purpose of storing the key
certificates of the maintainers:
key-cert: [mandatory] [single] [primary/look-up key]
method: [generated] [single]
owner: [generated] [multiple] [ ]
fingerpr: [generated] [single] [ ]
certif: [mandatory] [single] [ ]
remarks: [optional] [multiple] [ ]
notify: [optional] [multiple] [inverse key]
mnt-by: [mandatory] [multiple] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]
The syntax and the semantics of the different attributes are
described below.
key-cert:
syntax: PGPKEY-hhhhhhhh, where hhhhhhhh stands for the hex
representation of the four bytes ID of the PGP key.
semantics: The key certificate detailed in the certif attribute
belongs to the PGP key with the id hhhhhhhh. The
reason for having PGPKEY- as a prefix is to allow for
other types of key certificates at a later date, and
at the same time to be able to clearly differentiate
at query time between a person query and a key
certificate query.
remarks: at the time of the creation/modification of the key-
cert object, the database software checks whether the
key certificate in the certif attribute indeed
belongs to the PGP id specified here. The
creation/modification is authorized only upon the
match of these two ids.
Zsako [Page 3]
Draft PGP authentication for RIPE database updates July 1998
method:
syntax: line containing the name of the signing method.
semantics: this is the name of the digital signature method.
The present certificate belongs to a key for
digitally signing messages using the specified
method.
remarks: the method attribute is generated automatically by
the database software upon creation of the key-cert
object. Any method attribute present in the object
at the time of the submission for creation is
ignored. The method has to be consistent with both
the prefix of the id in the key-cert attribute and
with the certificate contained in the certif
attributes. If these latter two (i.e. prefix and
certificate) are not consistent, the key-cert object
creation is refused. For the PGP method this will be
the string "PGP" (without the quotes).
owner:
syntax: line containing a description of the owner of the
key.
semantics: for a PGP key, the owners are the user ids
associated with the key.
remarks: for each user id present in the key certificate,
an owner attribute is generated automatically by
the database software upon creation of the key-
cert object. Any owner attribute present in the
object at the time of the submission for creation
is ignored.
Zsako [Page 4]
Draft PGP authentication for RIPE database updates July 1998
fingerpr:
syntax: a given number of hex encoded bytes, separated for
better readability by spaces.
semantics: it represents the fingerprint of the key
associated with the present certificate.
remarks: this is also a field generated upon creation of
the object instance. Any fingerpr attribute
submitted to the robot is ignored. The reason for
having this attribute (and the owner attribute) is
to allow for an easy check of the key certificate
upon a query of the database. The querier gets
the owner and fingerprint information without
having to add the certificate to his/her own
public keyring. Also, since these two attributes
are _generated_ by the database software from the
certificate, one can trust them (as much as one
can trust the database itself).
certif:
syntax: line containing a line of the ASCII armoured key
certificate.
semantics: the certif attribute lines contain the key
certificate.
remarks: In the case of PGP, they also contain the
delimiting lines (BEGIN/END PGP PUBLIC KEY BLOCK).
Obviously the order of the lines is essential,
therefore the certif attribute lines are presented
at query time in the same order as they have been
submitted at creation. A database client
application could contain a script that strips the
certif attribute lines (returned as a result of a
query) from the leading "certif:" string and the
following white spaces and import the remainder in
the local keyring.
Zsako [Page 5]
Draft PGP authentication for RIPE database updates July 1998
mnt-by:
syntax: the usual syntax
semantics: the usual semantics
remarks: this attribute is _mandatory_ for this object.
Therefore, the existence of a mntner object is a
prerequisite for the creation of a key-cert
object. The mntner referenced in the mnt-by
attribute may not have the auth attribute set to
NONE.
remarks:,
notify:,
changed:,
source:
syntax: the usual syntax
semantics: the usual semantics.
In the case of PGP, when a key-cert object is created, the associated
key is also added to a local keyring of public keys. When a key-cert
object is deleted, the corresponding public key is deleted from the
local keyring as well. Whenever a key-cert object is modified, the
key is deleted from the local keyring and the key associated with the
new certificate is added to the keyring (obviously this is performed
only when the database update is authorized, in particular if the new
key certificate does belong to the id specified in the attribute
key-cert, see section 2.1).
2.2. Changes to the mntner object
The only change is that there is a new possible value for the auth
attribute. This value is of the form PGPKEY-<id>, where <id> is the
hex representation of the four bytes id of the PGP public key used
for authentication.
The semantics of this new value is that the PGP key associated with
the key certificate stored in the key-cert object identified by
PGPKEY-id is used to check the signature of any
creation/modification/deletion message sent to auto-dbm@ripe.net
affecting an object maintained by this mntner.
Just as with other values, the auth attribute can be multiple. It
Zsako [Page 6]
Draft PGP authentication for RIPE database updates July 1998
does not make much sense to have two auth attributes with different
methods (e.g. PGPKEY-<id> and NONE :)) ), just as it didn't earlier
either.
If there are several auth methods with a PGPKEY-<id> value, the
semantics is the already known one, namely that _either_ signature is
accepted.
3. The PGP signed creation/modification/deletion
The whole message has to be signed. This means, that the database
software first checks whether the message is a PGP signed message. If
it is, it checks for a valid signature and associates this signature
with the objects submitted in the message. A message may contain only
one PGP signature.
If an object present in a message has a mnt-by attribute, and the
respective mntner has auth attribute(s) with PGPKEY-<id> value, the
database software checks whether the object has a signature
associated with it (i.e. whether the message being processed had been
signed) and whether the type of the signature (PGP in this
implementation phase) and the id of the key used for signing the
message is the same as the one in (one of) the auth attribute(s). The
creation/modification/deletion of the object is performed only if
this authentication succeeds.
This approach allows for a simplification of the message parsing
process. A different approach would be necessary if one would sign
the _objects_, rather then the update messages. In case the objects
would be signed, the parser would have to identify which objects were
signed, check the signature(s) on each object individually and
permit/refuse the update at an object level, depending on (amongst
others) whether the signature is valid and whether it belongs to (one
of) the maintainer(s). This approach would allow for mixing in the
same e-mail message objects signed by different maintainers (which
would probably not be typical), and it would also allow for storing
the signature in the database (in order to allow for the verification
of the signature at query time). This latter (i.e. storing the
signatures in the database) is beyond the scope of the first phase of
the implementation. It may become a goal at a later date.
It is recommended to check that the mailer program does not make any
transformations on the text of the e-mail message (and possibly
configure it not to do any). Such common transformations are line-
wrapping after a given number of characters, transforming of tabs in
spaces, etc. Also check that you only use ASCII characters in the
message.
Zsako [Page 7]
Draft PGP authentication for RIPE database updates July 1998
4. Requirements the PGP key certificates must meet
There is no limitation imposed with respect to the version of the PGP
software that is/was used for the creation of the key. Key of both
version 2.x and 5.0 are supported, although the keys generated with
version 5.0 are recommended.
The key certificates submitted for creating a key-cert object must
contain a signature of the key itself. Although the certificate may
contain other signatures as well, it is recommended to create the
key-cert object with as few signatures as possible in the
certificate. Anyone concerned about the trustfulness of the key
should retrieve a copy of the key certificate from a public key
server (or by any other appropriate means and check the signatures
present in _that_ certificate. If such a check is performed one
should take care to check both the key fingerprint and the key type
and length in order to make sure the two certificates (the one
retrieved from the RIPE database and the one retrieved from the
public key server or collected by other means) belong to the same
key.
Although it is highly unlikely, it may happen that a key-cert with
the id identical to the id of the key of a maintainer already exists
in the RIPE database. In case this latter key had been used for a
while and it had been registered at public key servers for some time,
the given person should contact the RIPE NCC and report this to
ripe-dbm@ripe.net. Anyway, he/she may have to create a new key and
register _its_ certificate into the RIPE database. Such a procedure,
although highly unlikely to happen, should not create serious
problems to the respective maintainer.
5. Short overview of the tasks to be performed in order to use PGP
authentication
a. You must have a mntner object in the RIPE database with auth: other
than NONE. The mntner object has to be created in the traditional
way.
b. You must get a certificate of your own key and prepare a key-cert
object from it. The object has to reference in mnt-by the mntner
mentioned above (a.).
c. Create the key-cert object in the RIPE database, by sending the
object prepared above (b.) to auto-dbm@ripe.net. Obviously you must
Zsako [Page 8]
Draft PGP authentication for RIPE database updates July 1998
pass the authentication checks required by the mntner object (i.e.
mail from a predefined address or send the correct password).
d. Change the mntner object to have the auth: attribute value of
PGPKEY-<id>, where <id> is the hex id of your PGP key.
e. Check all objects maintained by the given mntner (preferably with the
command This is the only way to benefit from the stronger
authentication method in order to assign more trustfulness to the
database. Remember that you are the only person who can check for and
correct possible inconsistencies.
f. From now on always sign the (the whole) update messages that refer to
objects maintained by you, with the key you submitted to the RIPE
database.
6. Example of objects using the new feature
mntner: AS3244-MNT
descr: BankNet, Budapest HU
descr: Eastern European Internet Provider via own VSAT network
admin-c: JZ38
tech-c: JZ38
tech-c: IR2-RIPE
upd-to: ncc@banknet.net
mnt-nfy: ncc@banknet.net
auth: PGPKEY-23F5CE35
remarks: This is the maintainer of all BankNet related objects
notify: ncc@banknet.net
mnt-by: AS3244-MNT
changed: zsako@banknet.net 19980525
source: RIPE
Zsako [Page 9]
Draft PGP authentication for RIPE database updates July 1998
key-cert: PGPKEY-23F5CE35
method: PGP
owner: Janos Zsako <zsako@banknet.net>
fingerpr: B5 D0 96 D0 D0 D3 2B B2 B8 C2 5D 22 D4 F5 78 92
certif: -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2i
mQCNAzCqKdIAAAEEAPMSQtBNFFuTS0duoUiqnPHm05dxrI76rrOGwx+OU5tzGavx
cm2iCInNtikeKjlIMD7FiCH1J8PWdZivpwhzuGeeMimT8ZmNn4z3bb6ELRyiZOvs
4nfxVlh+kKKD9JjBfy8DnuMs5sT0jw4FEt/PYogJinFdndzywXHzGHEj9c41AAUR
tB9KYW5vcyBac2FrbyA8enNha29AYmFua25ldC5uZXQ+iQCVAwUQMjkx2XHzGHEj
9c41AQEuagP/dCIBJP+R16Y70yH75kraRzXY5rnsHmT0Jknrc/ihEEviRYdMV7X1
osP4pmDU8tNGf0OfGrok7KDTCmygIh7/me+PKrDIj0YkAVUhBX3gBtpSkhEmkLqf
xbhYwDn4DV3zF7f5AMsbD0UCBDyf+vpkMzgd1Pbr439iXdgwgwta50qJAHUDBRAy
OSsrO413La462EEBAdIuAv4+Cao1wqBG7+gIm1czIb1M2cAM7Ussx6y+oL1d+HqN
PRhx4upLVg8Eqm1w4BYpOxdZKkxumIrIvrSxUYv4NBnbwQaa0/NmBou44jqeN+y2
xwxAEVd9BCUtT+YJ9iMzZlE=
=w8xL
-----END PGP PUBLIC KEY BLOCK-----
remarks: This is an example of PGP key certificate
mnt-by: AS3244-MNT
changed: zsako@banknet.net 19980525
source: RIPE
Acknowledgements
The present proposal is the result of the discussions within the RIPE
DBSEC Task Force, which was set up at RIPE 27 in Dublin at the
initiative of Joachim Schmitz and Wilfried Woeber. The list of
participants who have contributed to the discussions at different
ocasions (TF meetings and via e-mail) is (in alphabetical order):
Cengiz Allaettinoglu, Joao Luis Silva Damas, Havard Eidnes, Chris
Fletcher, Daniel Karrenberg, David Kessens, Jake Khuon, Craig
Labovitz, Carl Malamud, Dave Meyer, Maldwyn Morris, Sandy Murphy,
Mike Norris, Carol Orange, Joachim Schmitz, Tom Spindler, Don
Stikvoort, Curtis Villamizar, Gerald Winters, Wilfried Woeber, Janos
Zsako.
Zsako [Page 10]
Draft PGP authentication for RIPE database updates July 1998
Author's Address
Janos Zsako
BankNet
1121 Budapest
Konkoly-Thege ut 29-33.
Hungary
Phone: +36 1 395 90 28
Fax: +36 1 395 90 32
EMail: zsako@banknet.net
Zsako [Page 11]
