Proposal to deprecate CRYPT-PW authorisation in the RIPE Database
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. -- Katie Petrusha RIPE NCC
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@FIDO)
Max Tulyev wrote:
Hi Katie!
Why not just to hide encrypted password from public view (as it done with e-mails)?
Even that is a bad hack which I resent, but eventually I gave in. We had done a similar thing in the past, with a different attribute, and we had to roll back. And we would have to invent just another flag to undo the hiding. This cannot be kept secret for long, so what? (Not doing that would actually require "everyone" to keep a *local* copy of the hash on backup for inclusion in the next update. That's asking for chaos :-( )
Note that MD5-PW is not much better: I bruteforce it approximately in one-two weeks (of course, not any password).
Just have a closer look below, please: "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..." While drafting the proposal we *consciously* included that before sending out the proposal, for exactly the reason you are pointing at.
Other proposal is to set up TLS/SSL at RIPE mail servers to encrypt traffic and to make interception of clear text passwords harder.
While I don't have any objection against implementing TLS/SSL/whatever *if it adds value*, this is not going to make too big a difference: We are dealing here with a public database, and in case you need 2 parties to provide credentials (and both NOT using asy-crypto) then at least 1 party still has to disclose the password/passphrase to the other. Transport security won't help, really. The only thing that helps in the long run is moving to asy-crypto. Let us spend our effort on a real solution. Wilfried.
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.
Wilfried Woeber, UniVie/ACOnet wrote:
Max Tulyev wrote:
Hi Katie!
Why not just to hide encrypted password from public view (as it done with e-mails)?
Even that is a bad hack which I resent, but eventually I gave in. We had done a similar thing in the past, with a different attribute, and we had to roll back.
And we would have to invent just another flag to undo the hiding. This cannot be kept secret for long, so what? (Not doing that would actually require "everyone" to keep a *local* copy of the hash on backup for inclusion in the next update. That's asking for chaos :-( )
Why does it matter if people don't have a local copy of the hash? If you want to modify the mntner object (maybe add a new admin-c) and you can't remember the hash value, you can just encrypt your plain text password again and enter a new hash value to the update. It may be a little bit inconvenient, but not a major problem. I don't think even the password owner 'needs' to see the hash. regards Denis Walker RIPE NCC
Note that MD5-PW is not much better: I bruteforce it approximately in one-two weeks (of course, not any password).
Just have a closer look below, please: "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..."
While drafting the proposal we *consciously* included that before sending out the proposal, for exactly the reason you are pointing at.
Other proposal is to set up TLS/SSL at RIPE mail servers to encrypt traffic and to make interception of clear text passwords harder.
While I don't have any objection against implementing TLS/SSL/whatever *if it adds value*, this is not going to make too big a difference: We are dealing here with a public database, and in case you need 2 parties to provide credentials (and both NOT using asy-crypto) then at least 1 party still has to disclose the password/passphrase to the other.
Transport security won't help, really.
The only thing that helps in the long run is moving to asy-crypto. Let us spend our effort on a real solution.
Wilfried.
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.
Hi Denis, Denis Walker wrote: [...]
Why does it matter if people don't have a local copy of the hash? If you want to modify the mntner object (maybe add a new admin-c) and you can't remember the hash value, you can just encrypt your plain text password again and enter a new hash value to the update.
Technically, you are right.
It may be a little bit inconvenient,
... for any definition of *little* :-)
but not a major problem. I don't think even the password owner 'needs' to see the hash.
I think we should think this through to the very end :-) Starting with modifying all the documentation, the training material, the LIR portal, how to manage removal of e.g. 1 out of 2 or 3 hashes. Not talking about the fact that this is a pretty fundamental change to the DB architecture and behaviour. Not from a software development point of view - your view. But there are people out there who do not use commandline tools, but scripts, or applications...
regards Denis Walker RIPE NCC
But if we change stuff, why don't we simply do away with it, instead of plastering around the cracks? Wilfried.
On Wed, Oct 04, 2006 at 06:05:10PM +0200, Denis Walker wrote:
want to modify the mntner object (maybe add a new admin-c) and you can't remember the hash value, you can just encrypt your plain text password again and enter a new hash value to the update. It may be a little bit inconvenient, but not a major problem. I don't think even the password owner 'needs' to see the hash.
I guess this is the n-th iteration of this text and Max is correct in pointing out that the results of the previous discussion should be made available on the "FAQ page" that is going to support this migration effort. IIRC, the reason for not hiding the password was that fetch-submit should be idempotent, or, to elaborate a bit more, no information should be lost in a fetch-edit-submit cycle. This is especially important in those cases where there's another auth scheme in use besides MD5-PW, so not submitting the respective attribute with the object would actually change the mntner to only use the remaining auth scheme. Any 'workarounds' to me appear a bit like rearranging those deckchairs once again. If MD5 is weak and there's enough concern in the community to get rid of it, let's just do it. But at the same time, let's take the first step first and get the CRYPT-PW deprecation and phase-out plan out of the door. -Peter PS: One additional migration caveat is that LIRs that substitute MD5 for CRYPT-PW should be _urged_ not to just change the 'encryption' scheme, but also need to generate a new and better password.
Peter Koch wrote:
IIRC, the reason for not hiding the password was that fetch-submit should be idempotent, or, to elaborate a bit more, no information should be lost in a fetch-edit-submit cycle. This is especially important in those cases where there's another auth scheme in use besides MD5-PW, so not submitting the respective attribute with the object would actually change the mntner to only use the remaining auth scheme. Any 'workarounds' to me appear a bit like rearranging those deckchairs once again. If MD5 is weak and there's enough concern in the community to get rid of it, let's just do it. But at the same time, let's take the first step first and get the CRYPT-PW deprecation and phase-out plan out of the door.
Not MD5 (CRYPT/SHA/...) is weak, but some sort a people using stupid passwords ;) Also, moving out encrypted password to another separated hidden object (as PGP key is now) don't break the fetch-edit-submit schema. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Wilfried Woeber, UniVie/ACOnet wrote:
And we would have to invent just another flag to undo the hiding. This cannot be kept secret for long, so what? (Not doing that would actually require "everyone" to keep a *local* copy of the hash on backup for inclusion in the next update. That's asking for chaos :-( )
No flags. Just hide at all. Or move it to another object and hide whole object (as I proposed a time ago).
While I don't have any objection against implementing TLS/SSL/whatever *if it adds value*, this is not going to make too big a difference: We are dealing here with a public database, and in case you need 2 parties to provide credentials (and both NOT using asy-crypto) then at least 1 party still has to disclose the password/passphrase to the other.
Transport security won't help, really.
Transport security helps to fight with cool people with sniffers. It is a big deal, I think. And it helps just right now, without any changes in DB. Implementing it improves security and doesn't touch current working schema. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Hi, On Wed, Oct 04, 2006 at 11:36:28PM +0400, Max Tulyev wrote:
Transport security helps to fight with cool people with sniffers.
Indeed. I wonder if it would be a worthwile excercise to enable TLS on the RIPE mail servers? (This would be something for the ncc-services WG) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 98999 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
Wilfried Woeber, UniVie/ACOnet wrote:
Max Tulyev wrote:
Hi Katie!
Why not just to hide encrypted password from public view (as it done with e-mails)?
Even that is a bad hack which I resent, but eventually I gave in. We had done a similar thing in the past, with a different attribute, and we had to roll back.
And we would have to invent just another flag to undo the hiding. This cannot be kept secret for long, so what? (Not doing that would actually require "everyone" to keep a *local* copy of the hash on backup for inclusion in the next update. That's asking for chaos :-( )
The IRRd software returns the special token "HIDDENCRYPTPW" for the CRYPT-PW value. Note this is 13 characters long and thus a legal CRYPT-PW value. If an update is submitted with this value, the existing CRYPT-PW is left in place. There is a very small chance of a collision with an actual password, but the probability is deemed to be too low to be of concern for this application. Things can get a bit tricky if one has multiple CRYPT-PW passwords. I can go over the algorithm used by IRRd in such cases if anyone cares. -Larry Blunk Merit Network
participants (7)
-
Denis Walker -
Gert Doering -
Katie Petrusha -
Larry Blunk -
Max Tulyev -
Peter Koch -
Wilfried Woeber, UniVie/ACOnet