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 matches any one of the credentials supplied in an update.
Three authentication methods are currently available:
This method takes an argument consisting of a bcrypt-hashed password.
When requesting a mntner object, the user must include an "auth: " attribute with a value corresponding to a Unix style encrypted password and the BCRYPT-PW keyword: auth: BCRYPT-PW
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:"
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 hashed, matches the one stored in the mntner object, the update will be allowed. Otherwise, it will be refused.
We recommend you use the Whois Crypt tool to generate a BCRYPT-PW password. bcrypt is not vulnerable to rainbow tables or brute-force attacks and it is unbroken to date. However, it is crucial that you choose a good password that is not easy to guess. Note that there are two types of attacks:
- Password cracking. An attacker might guess the password either by checking it against dictionaries or by trying 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. To avoid that, you might want to use PGP orX509 (see below).
Please note that CRYPT-PW and MD5-PW are now deprecated. As such they may not be used in new DB objects or any future updates. For the time being, existing CRYPT-PW or MD5-PW secured maintainer objects can still be used for authentication. Future releases of the WHOIS DB may remove support completely. If you have a CRYPT or MD5 protected password in your maintainer object, please update it to a BCRYPT-PW as soon as possible.
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: AFRINIC 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.
Read more about PGP Authentication in AFRINIC Database
This method too 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.
Note1: AFRINIC 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.
Note2: At this point, AFRINIC does not provide a tool for Certificate Generation. If you don't already have one, you will have to generate a self-signed certificate for yourself.
Read more about how to set up a X.509 authentication
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.
For a complete description of how to interact with the AFRINIC Database, including data protection, please see the following documents:
- AFRINIC Database Reference Manual
- All AFRINIC Database documentation
An empty template can be obtained using a whois client pointed to whois.AFRINIC.net