[db-wg] Proposal to deprecate CRYPT-PW authorisation in the RIPE Database

Hi Katie!

Why not just to hide encrypted password from public view (as it done
with e-mails)?
Note that MD5-PW is not much better: I bruteforce it approximately in
one-two weeks (of course, not any password).

Other proposal is to set up TLS/SSL at RIPE mail servers to encrypt
traffic and to make interception of clear text passwords harder.

Katie Petrusha wrote:
> 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.
>
>   


-- 
WBR,
Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO)