[db-wg] Deprecation of CRYPT-PW authorisation from the RIPE Database

Dear colleagues,

I would like to inform you that the project to deprecate CRYPT-PW 
authorisation in mntner objects in the RIPE Database is scheduled to 
start this week.

Regards,
Agoston Horvath
Software Engineering Department
RIPE NCC



-------- Original Message --------
Subject:     [db-wg] Proposal to deprecate CRYPT-PW authorisation in the RIPE Database
Date:     Wed, 4 Oct 2006 15:48:12 +0200
From:     Katie Petrusha <katie at ripe.net>
To:     db-wg at ripe.net



Dear colleagues,

Here follows the proposal to deprecate CRYPT-PW authorisation in mntner 
objects in the RIPE Database. Comments would be appreciated.

Background and motivation
-------------------------

In the RIPE Database there are several authorisation types currently 
supported:
CRYPT-PW, MD5-PW, PGPKEY and X509. These authorisation types define what 
kind of
authorisation tokens can be used in "mntner" objects.

CRYPT-PW authorisation type is based on UNIX crypt() functionality and is
vulnerable to both dictionary and brute force attacks given the fixed 
password
length and lack of cryptographic strength given today's computing power.
While maintaining and protecting objects in the RIPE Database is the 
responsibility of the respective maintainer, the RIPE DB WG agreed that 
it's the responsibility of the community to ensure that only appropriate 
tools and algortihms are used and maintained. 
Since CRYPT-PW does no longer fulfill this requirements with the reasons 
given above, the WG also agreed to phase out CRYPT-PW. PGPKEY and X.509 
have been the recommended authentication schemes for some
time (http://www.ripe.net/db/support/security/security.html)

MD5-PW shares two weaknesses with CRYPT-PW: passwords are sent in
clear together with update requests and MD5 is vulnerable to dictionary 
attacks,as well. Still, MD5-PW will not be phased out together with 
CRYPT-PW, since
at least the dictionary attack can be prevented by chosing passwords or
pass phrases of appropriate length and entropy. MD5 offers a short path
of migration away from CRYPT-PW without major change in processes. LIRs
should, however, seriously consider a migration towards a public key based
authentication scheme (PGPKEY or X.509). The MD5-PW method will be 
addressed
separately.

We propose to deprecate the CRYPT-PW authorisation step-by-step.

Affected objects
----------------

There are currently ~3500 mntner objects in the RIPE Database that have
only CRYPT-PW authorisation. There are about 300 mntner objects that have
mixed authorisation of CRYPT-PW and some other authorisation types.

Plan
----

1. Gather mntner objects:
  group A: only CRYPT-PW authorisation
  group B: CRYPT-PW and (PGP or X509 or MD5) authorisation
    1a. E-mail the contacts of those mntner objects       (notify, 
admin-c, tech-c, mnt-nfy)
     to notify them about the coming change.

  1b. notify the DB-WG mailing list

1 month later:

2.  Modify the RIPE Database software:
   1) reject any change to mntner object that adds new CRYPT-PW.
   2) show a warning if CRYPT-PW was used during authorisation.
   3) show a warning if object being updated still contains (existing)
   CRYPT-PW.

2a. E-mail the contacts of the mntner objects      (notify, admin-c, 
tech-c, mnt-nfy)
    notifying them about the change and the next steps.

2b. notify the DB-WG mailing list

1 month later:

3. Modify the RIPE Database software:
    1) disable CRYPT-PW in the syntax
    2) disable CRYPT-PW in authorisation
      3a. Modify mntner objects.        group A: auth: is changed to 
MD5-PW, new password generated.
      group B: auth: CRYPT-PW is changed into "remarks"
         line "remarks: "your object was modified due to CRYPT-PW 
deprecation"
       is added
          3b. Notify the contacts of the mntner objects:
       group A: explanation about the changes done, and URL with 
details on
    how to 'recover' the locked mntner object (similar to NONE deprecation
    process)
            group B: explanation about the changes done
       3c. notify the DB-WG mailing list
   
4. Finished.