Protecting your data in the RIPE Database
This document provides recommendations on how to use the various methods
available to RIPE Database users to enable protection of data against
unauthorised deletion or modification (and in some cases also against
unauthorised creation).
Obtaining your maintainer object
To protect data in the RIPE Database, users will need a mntner
object. These are created, like other objects, by sending an e-mail
to auto-dbm@ripe.net or by
using the Webupdate form at:
https://www.ripe.net/fcgi-bin/webupdates.pl
Available authentication methods
When using a maintainer to protect your data, you will have to
choose one or more of the available authentication methods. These
are defined in the "auth:" attributes of the mntner
object. You can have any combination of the different methods and
as many instances of each as you wish in a mntner
object. However, be aware that authentication is a logical 'OR'
of all the supplied instances of the "auth:" attributes
values. Authorisation is passed when any one of the "auth:"
attributes values match any one of the credentials supplied in an
update.
Three authentication methods are currently available:
- MD5-PW:
This method takes an argument consisting of an MD5 encrypted password.
When requesting a mntner object, the user must include
an "auth:" attribute with a value corresponding to an MD5
encrypted password and the MD5-PW keyword:
auth: MD5-PW <MD5 crypted password>.
When submitting an update by e-mail to create, modify or delete an object protected by a maintainer using this method, the message sent to the database server must include a line containing:
password: <cleartext password>
This pseudo attribute must be in the body of the e-mail message. If it is a multipart mime message it must also be in the same mime part as the object. Other than these restrictions, it may appear anywhere in the message in relation to the objects. It only needs to appear once in the message even if the update contains several objects protected by the same maintainer.
If this password, when encrypted, matches the one stored in the mntner object the update will proceed. Otherwise it will be refused.
There is a cgi script here
to generate an MD5 password for you.
Note: This method may be subject to two types of attacks:
- Password cracking. This is the same kind of attack to which normal computer passwords can be subject. There are programs available that can be used to attempt to decode the password, either by checking it against dictionaries or by attempting all possible combinations.
- Mail snooping. As the update message contains the password in clear text, there is a chance that the password will be seen if the message is intercepted in transit between the user's system and the database server machine.
- PGPKEY:
This is one of the strongest protection methods available. The user
specifies a PGP key-id pointing to a key-cert object
in the database that stores a PGP public key.
When sending updates to the database, the user must sign the message
using his/her PGP private key. The database software will check the
signature using the public key stored in the key-cert
object referenced in the "auth:" attribute of the relevant
mntner object. If the cryptographic signature is
correct, the update will proceed, otherwise it will be refused.
Note: This type of usage of PGP is considered as commercial use by
PGP Inc. A commercial software license must be obtained if PGP software
is used. Alternatively users may utilise the GnuPG software to generate
and manage keys that are compatible with PGP software.
Note: The RIPE NCC makes no claims about the identity of the owner
of the PGP key used. It just checks that the signature in the e-mail
message was made using the private key corresponding to the public
key stored in the database.
See also our PGP
documentation.
- X.509:
This is one of the strongest protection methods available. The user
specifies an X.509 certificate pointing to a key-cert
object in the database that stores an X.509 certificate public key.
When sending updates to the database, the user must sign the message
using his/her X.509 certificate private key. The database software
will check the signature using the public key stored in the key-cert
object referenced in the "auth:" attribute of the relevant
mntner object. If the cryptographic signature is
correct the update will proceed, otherwise it will be refused.
Note: The RIPE NCC makes no claims about the trust path of the certificate
or of the revocation status of the certificate. It just checks that
the signature in the e-mail message was made using the private key
corresponding to the public key stored in the database.
See also our How to
setup and use X.509 authentication in the RIPE Database.
Simultaneous Use of Several Authentication Schemes
It is enough to match only one of the "auth:" attributes
in the mntner object in order to update an object.
We recommend using only one type of authentication method in one
mntner object. It should be the strongest type
practical for the user.
The best possible protection method is to have either PGPKEY or X.509
authentication. If, for whatever reason, a user does not feel comfortable
with only PGPKEY or X.509 and prefers to leave a "backdoor",
please use MD5-PW as an addition, choosing a good password.
For daily operations, always apply a signature to the updates.
More information
For a complete description of how to interact with the RIPE Database,
including data protection, please see the following documents:
(1) An empty template can be obtained using a whois
client pointed to whois.ripe.net as follows:
whois -h whois.ripe.net -t mntner
or
whois -h whois.ripe.net -v mntner
which provides more detailed information.
|
you are here: home -> RIPE Database
