Re: [db-wg] MD5 and Password Security in the RIPE DB, Fwd: Wonder if you can help - re: PDP
Emilio, Wilfried, Nigel, Emilio wrote:
My apologies for sending the previous email to the full working group. It was intended for the Database Working Group Chairs.
But now that you accidentaly mailed us, I would like to take the opportunity to mention that I believe that we don't need the PDP process invoked for these kind of changes. I hope that we as a community have not petrified that far that we cannot request the RIPE NCC to make a change to the RIPE database and be done with it. To say it in a different way, the issue at hand is much closer (but not quite the same) to a bug fix/operational issue than a public policy change. David Kessens PS And regarding the topic of shadow passwords in the RIPE database, you might be interested in the following presentation by me from 1995, page 11: ftp://ftp.ripe.net/ripe/presentations/ripe-m22-david-DB-REPORT.ps.gz --- On Mon, Dec 12, 2011 at 10:55:23AM +0100, Emilio Madaio wrote:
Hi Nigel and Wilfried,
as promised last week to Nigel, I'd like to make a short recap and have your attention on the following.
I have been contacted by David Freedman in regards of a couple of policy proposals he sent you for review and possible submission to the PDP. Below you can find, for more details, my summaries of the proposals and what analysis we did in the NCC.
As you will see, both cases can be tackled by the NCC with ideas that can be discussed by the DB WG and, if approved, easily implemented. Among the possible decisions you can take, there are also:
-starting discussion in the mailing list now; or -present and discuss at RIPE 64.
Obviously we can consider, as David asked, to start the PDP if you deem it necessary.
In any case, David did not have a chance to hear from you, so I kindly ask you to let him know, either your decision or that you acknowledged his intentions.
And please do not hesitate to let me know how I can help.
I included the email he sent so far and the aforementioned proposal texts.
Best Regards Emilio Madaio Policy Development Officer RIPE NCC
-----oooooooo-------- SUMMARIES:
1) The first proposal's scope regards the display of the MD5 password hashes in the "auth:" attribute. Since then the DB department published an article recommending the technical solutions of, in short:
-filtering out "auth:" attributes from all query results on MNTNER objects -adjusting Webupdates to require maintainer password authorisation over HTTPS before presenting the object to the user for updating.
This solution can be easy and quick to implement. They only need some discussion in the DB WG.
2) The second proposal's scope regards the restriction to secure channels for all the possible mntner authentications. In this instance as well, the NCC can provide some quick technical alternatives for the DB WG to discuss.
-------- Original Message -------- [..]
Date: Tue, 15 Nov 2011 09:44:31 +0000 From: David Freedman <david.freedman@eu.clara.net> To: db-wg-chairs@ripe.net Subject: My proposals
Hi there,
On 08/11 I sent you two policy proposals for review, concerning the publication and use of MD5 authentication attributes in the database.
Since then, Denis Walker has published an article on RIPE labs describing a potential solution to one of these issues
https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database
Could you please tell me what happens next in the scope of both my proposals and security community support for Denis' idea?
Regards,
David Freedman
Date: Tue, 8 Nov 2011 16:10:35 +0000 From: David Freedman <david.freedman@eu.clara.net> To: db-wg-chairs@ripe.net Subject: Re: Policy Proposal "Removal of auth: MD5-PW from WHOIS information"
s/scheme/schemes, apologies
On 08/11/2011 16:03, "David Freedman" <david.freedman@eu.clara.net> wrote:
Please see below:
---------------------------
Number: (assigned by the RIPE NCC)
Policy Proposal Name: Removal of auth: MD5-PW from WHOIS information
Author: a. David Freedman
b. david.freedman@uk.clara.net
c. Claranet
Proposal Version: (assigned by the RIPE NCC)
Submission Date: 8/11/2011
Suggested RIPE WG for discussion and publication: Database Working Group
Proposal Type: a. new
Policy Term: b. Indefinite
Summary of proposal: Policy text: b. New policy text
This is a proposal to remove the display the "auth:" attribute for auth type "MD5-PW" in WHOIS information, in order to increase the security of a number of user's mntner objects.
Rationale: a. Arguments supporting the proposal
Numerous sources have demonstrated the vulnerability of the MD5-PW to compromise when presented with modern compute power, a number of alternate "auth" scheme exist which provide far more security to the mntner. By allowing these attributes to be exposed in WHOIS information, malicious entities could direct their efforts to computing a plaintext input of the hash and thus compromise mntner objects (and hence protected resources) of their choice.
b. Arguments opposing the proposal
The database group state: "Since any change in the current process means significantly changing the behaviour of the RIPE Database* and will break existing use cases of the system, it is not something the RIPE NCC can make a decision on.", this could involve significant work for the Database Group.
*- As an example, current Update process requires the full object -including the hashes for maintainer objects- to be used in the update message.
---------------------------
Date: Tue, 8 Nov 2011 16:10:14 +0000 From: David Freedman <david.freedman@eu.clara.net> To: db-wg-chairs@ripe.net Subject: New proposal : Prevention of use of MD5-PW over insecure channels
See below
-----------
Number: (assigned by the RIPE NCC)
Policy Proposal Name: Prevention of use of MD5-PW over insecure channels
Author: a. David Freedman
b. david.freedman@uk.clara.net
c. Claranet
Proposal Version: (assigned by the RIPE NCC)
Submission Date: 8/11/2011
Suggested RIPE WG for discussion and publication: Database Working Group
Proposal Type: a. new
Policy Term: b. Indefinite
Summary of proposal: Policy text: b. New policy text
This is a proposal to ensure that all mntner authentication which makes use of MD5-PW for an object transaction, do so over a secure channel, in order to increase the security of such transactions.
Rationale: a. Arguments supporting the proposal
Numerous sources have demonstrated the vulnerability of the MD5-PW to compromise when presented with modern compute power, a number of alternate "auth" schemes exist which provide far more security to the mntner. By allowing the plaintext password to be passed over insecure channels, information could be intercepted and the plaintext password obtained, potentially compromising mntner objects (and hence protected resources).
b. Arguments opposing the proposal
A number of object maintainers may currently make use of such insecure channels (for example, unencrypted SMTP), these functions may be related to legacy systems which are costly to update.
-----------
Date: Tue, 8 Nov 2011 16:03:30 +0000 From: David Freedman <david.freedman@eu.clara.net> To: db-wg-chairs@ripe.net Subject: Policy Proposal "Removal of auth: MD5-PW from WHOIS information"
Please see below:
---------------------------
Number: (assigned by the RIPE NCC)
Policy Proposal Name: Removal of auth: MD5-PW from WHOIS information
Author: a. David Freedman
b. david.freedman@uk.clara.net
c. Claranet
Proposal Version: (assigned by the RIPE NCC)
Submission Date: 8/11/2011
Suggested RIPE WG for discussion and publication: Database Working Group
Proposal Type: a. new
Policy Term: b. Indefinite
Summary of proposal: Policy text: b. New policy text
This is a proposal to remove the display the "auth:" attribute for auth type "MD5-PW" in WHOIS information, in order to increase the security of a number of user's mntner objects.
Rationale: a. Arguments supporting the proposal
Numerous sources have demonstrated the vulnerability of the MD5-PW to compromise when presented with modern compute power, a number of alternate "auth" scheme exist which provide far more security to the mntner. By allowing these attributes to be exposed in WHOIS information, malicious entities could direct their efforts to computing a plaintext input of the hash and thus compromise mntner objects (and hence protected resources) of their choice.
b. Arguments opposing the proposal
The database group state: "Since any change in the current process means significantly changing the behaviour of the RIPE Database* and will break existing use cases of the system, it is not something the RIPE NCC can make a decision on.", this could involve significant work for the Database Group.
*- As an example, current Update process requires the full object -including the hashes for maintainer objects- to be used in the update message.
---------------------------
David Kessens ---
My apologies for sending the previous email to the full working group.
That's OK, Thanks for sharing :) , this reply back to list is intentional. With regards to my first proposal, I'd like to quote from Denis' article I cited: "Next steps * If the community agrees to the deployment of this change, the RIPE NCC will develop and deploy it in a short space of time. * The RIPE NCC will then contact all the maintainers of MNTNER objects containing passwords and ask them to change these for new, strong passwords. " Added by Emilio: " They only need some discussion in the DB WG." Since this has now been discussed over the scope of two meetings (62 + 63), *and* on the mailing list, Can we please agree that the end-result is a good thing(tm), allow the NCC to implement this and move on with our lives? Dave. On 12/12/2011 19:15, "David Kessens" <david.kessens@nsn.com> wrote:
Emilio, Wilfried, Nigel,
Emilio wrote:
My apologies for sending the previous email to the full working group. It was intended for the Database Working Group Chairs.
But now that you accidentaly mailed us, I would like to take the opportunity to mention that I believe that we don't need the PDP process invoked for these kind of changes.
I hope that we as a community have not petrified that far that we cannot request the RIPE NCC to make a change to the RIPE database and be done with it. To say it in a different way, the issue at hand is much closer (but not quite the same) to a bug fix/operational issue than a public policy change.
David Kessens PS And regarding the topic of shadow passwords in the RIPE database, you might be interested in the following presentation by me from 1995, page 11: ftp://ftp.ripe.net/ripe/presentations/ripe-m22-david-DB-REPORT.ps.gz ---
On Mon, Dec 12, 2011 at 10:55:23AM +0100, Emilio Madaio wrote:
Hi Nigel and Wilfried,
as promised last week to Nigel, I'd like to make a short recap and have your attention on the following.
I have been contacted by David Freedman in regards of a couple of policy proposals he sent you for review and possible submission to the PDP. Below you can find, for more details, my summaries of the proposals and what analysis we did in the NCC.
As you will see, both cases can be tackled by the NCC with ideas that can be discussed by the DB WG and, if approved, easily implemented. Among the possible decisions you can take, there are also:
-starting discussion in the mailing list now; or -present and discuss at RIPE 64.
Obviously we can consider, as David asked, to start the PDP if you deem it necessary.
In any case, David did not have a chance to hear from you, so I kindly ask you to let him know, either your decision or that you acknowledged his intentions.
And please do not hesitate to let me know how I can help.
I included the email he sent so far and the aforementioned proposal texts.
Best Regards Emilio Madaio Policy Development Officer RIPE NCC
-----oooooooo-------- SUMMARIES:
1) The first proposal's scope regards the display of the MD5 password hashes in the "auth:" attribute. Since then the DB department published an article recommending the technical solutions of, in short:
-filtering out "auth:" attributes from all query results on MNTNER objects -adjusting Webupdates to require maintainer password authorisation over HTTPS before presenting the object to the user for updating.
This solution can be easy and quick to implement. They only need some discussion in the DB WG.
2) The second proposal's scope regards the restriction to secure channels for all the possible mntner authentications. In this instance as well, the NCC can provide some quick technical alternatives for the DB WG to discuss.
-------- Original Message -------- [..]
Date: Tue, 15 Nov 2011 09:44:31 +0000 From: David Freedman <david.freedman@eu.clara.net> To: db-wg-chairs@ripe.net Subject: My proposals
Hi there,
On 08/11 I sent you two policy proposals for review, concerning the publication and use of MD5 authentication attributes in the database.
Since then, Denis Walker has published an article on RIPE labs describing a potential solution to one of these issues
https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-datab ase
Could you please tell me what happens next in the scope of both my proposals and security community support for Denis' idea?
Regards,
David Freedman
Date: Tue, 8 Nov 2011 16:10:35 +0000 From: David Freedman <david.freedman@eu.clara.net> To: db-wg-chairs@ripe.net Subject: Re: Policy Proposal "Removal of auth: MD5-PW from WHOIS information"
s/scheme/schemes, apologies
On 08/11/2011 16:03, "David Freedman" <david.freedman@eu.clara.net> wrote:
Please see below:
---------------------------
Number: (assigned by the RIPE NCC)
Policy Proposal Name: Removal of auth: MD5-PW from WHOIS information
Author: a. David Freedman
b. david.freedman@uk.clara.net
c. Claranet
Proposal Version: (assigned by the RIPE NCC)
Submission Date: 8/11/2011
Suggested RIPE WG for discussion and publication: Database Working Group
Proposal Type: a. new
Policy Term: b. Indefinite
Summary of proposal: Policy text: b. New policy text
This is a proposal to remove the display the "auth:" attribute for auth type "MD5-PW" in WHOIS information, in order to increase the security of a number of user's mntner objects.
Rationale: a. Arguments supporting the proposal
Numerous sources have demonstrated the vulnerability of the MD5-PW to compromise when presented with modern compute power, a number of alternate "auth" scheme exist which provide far more security to the mntner. By allowing these attributes to be exposed in WHOIS information, malicious entities could direct their efforts to computing a plaintext input of the hash and thus compromise mntner objects (and hence protected resources) of their choice.
b. Arguments opposing the proposal
The database group state: "Since any change in the current process means significantly changing the behaviour of the RIPE Database* and will break existing use cases of the system, it is not something the RIPE NCC can make a decision on.", this could involve significant work for the Database Group.
*- As an example, current Update process requires the full object -including the hashes for maintainer objects- to be used in the update message.
---------------------------
Date: Tue, 8 Nov 2011 16:10:14 +0000 From: David Freedman <david.freedman@eu.clara.net> To: db-wg-chairs@ripe.net Subject: New proposal : Prevention of use of MD5-PW over insecure channels
See below
-----------
Number: (assigned by the RIPE NCC)
Policy Proposal Name: Prevention of use of MD5-PW over insecure channels
Author: a. David Freedman
b. david.freedman@uk.clara.net
c. Claranet
Proposal Version: (assigned by the RIPE NCC)
Submission Date: 8/11/2011
Suggested RIPE WG for discussion and publication: Database Working Group
Proposal Type: a. new
Policy Term: b. Indefinite
Summary of proposal: Policy text: b. New policy text
This is a proposal to ensure that all mntner authentication which makes use of MD5-PW for an object transaction, do so over a secure channel, in order to increase the security of such transactions.
Rationale: a. Arguments supporting the proposal
Numerous sources have demonstrated the vulnerability of the MD5-PW to compromise when presented with modern compute power, a number of alternate "auth" schemes exist which provide far more security to the mntner. By allowing the plaintext password to be passed over insecure channels, information could be intercepted and the plaintext password obtained, potentially compromising mntner objects (and hence protected resources).
b. Arguments opposing the proposal
A number of object maintainers may currently make use of such insecure channels (for example, unencrypted SMTP), these functions may be related to legacy systems which are costly to update.
-----------
Date: Tue, 8 Nov 2011 16:03:30 +0000 From: David Freedman <david.freedman@eu.clara.net> To: db-wg-chairs@ripe.net Subject: Policy Proposal "Removal of auth: MD5-PW from WHOIS information"
Please see below:
---------------------------
Number: (assigned by the RIPE NCC)
Policy Proposal Name: Removal of auth: MD5-PW from WHOIS information
Author: a. David Freedman
b. david.freedman@uk.clara.net
c. Claranet
Proposal Version: (assigned by the RIPE NCC)
Submission Date: 8/11/2011
Suggested RIPE WG for discussion and publication: Database Working Group
Proposal Type: a. new
Policy Term: b. Indefinite
Summary of proposal: Policy text: b. New policy text
This is a proposal to remove the display the "auth:" attribute for auth type "MD5-PW" in WHOIS information, in order to increase the security of a number of user's mntner objects.
Rationale: a. Arguments supporting the proposal
Numerous sources have demonstrated the vulnerability of the MD5-PW to compromise when presented with modern compute power, a number of alternate "auth" scheme exist which provide far more security to the mntner. By allowing these attributes to be exposed in WHOIS information, malicious entities could direct their efforts to computing a plaintext input of the hash and thus compromise mntner objects (and hence protected resources) of their choice.
b. Arguments opposing the proposal
The database group state: "Since any change in the current process means significantly changing the behaviour of the RIPE Database* and will break existing use cases of the system, it is not something the RIPE NCC can make a decision on.", this could involve significant work for the Database Group.
*- As an example, current Update process requires the full object -including the hashes for maintainer objects- to be used in the update message.
---------------------------
David Kessens ---
I think we've seen enough support for this in the community for this to go ahead without invoking the PDP, which as David K has said is really overkill for this sort of thing. RIPE NCC can you start this off please? Thanks Nigel -----Original Message----- From: db-wg-bounces@ripe.net [mailto:db-wg-bounces@ripe.net] On Behalf Of David Freedman Sent: 13 December 2011 09:07 To: David Kessens; Emilio Madaio Cc: pdo@ripe.net; Database WG Subject: Re: [db-wg] MD5 and Password Security in the RIPE DB, Fwd: Wonder if you can help - re: PDP
My apologies for sending the previous email to the full working group.
That's OK, Thanks for sharing :) , this reply back to list is intentional. With regards to my first proposal, I'd like to quote from Denis' article I cited: "Next steps * If the community agrees to the deployment of this change, the RIPE NCC will develop and deploy it in a short space of time. * The RIPE NCC will then contact all the maintainers of MNTNER objects containing passwords and ask them to change these for new, strong passwords. " Added by Emilio: " They only need some discussion in the DB WG." Since this has now been discussed over the scope of two meetings (62 + 63), *and* on the mailing list, Can we please agree that the end-result is a good thing(tm), allow the NCC to implement this and move on with our lives? Dave. On 12/12/2011 19:15, "David Kessens" <david.kessens@nsn.com> wrote:
Emilio, Wilfried, Nigel,
Emilio wrote:
My apologies for sending the previous email to the full working group. It was intended for the Database Working Group Chairs.
But now that you accidentaly mailed us, I would like to take the opportunity to mention that I believe that we don't need the PDP process invoked for these kind of changes.
I hope that we as a community have not petrified that far that we cannot request the RIPE NCC to make a change to the RIPE database and be done with it. To say it in a different way, the issue at hand is much closer (but not quite the same) to a bug fix/operational issue than a public policy change.
David Kessens PS And regarding the topic of shadow passwords in the RIPE database, you might be interested in the following presentation by me from 1995, page 11: ftp://ftp.ripe.net/ripe/presentations/ripe-m22-david-DB-REPORT.ps.gz ---
On Mon, Dec 12, 2011 at 10:55:23AM +0100, Emilio Madaio wrote:
Hi Nigel and Wilfried,
as promised last week to Nigel, I'd like to make a short recap and have your attention on the following.
I have been contacted by David Freedman in regards of a couple of policy proposals he sent you for review and possible submission to the PDP. Below you can find, for more details, my summaries of the proposals and what analysis we did in the NCC.
As you will see, both cases can be tackled by the NCC with ideas that can be discussed by the DB WG and, if approved, easily implemented. Among the possible decisions you can take, there are also:
-starting discussion in the mailing list now; or -present and discuss at RIPE 64.
Obviously we can consider, as David asked, to start the PDP if you deem it necessary.
In any case, David did not have a chance to hear from you, so I kindly ask you to let him know, either your decision or that you acknowledged his intentions.
And please do not hesitate to let me know how I can help.
I included the email he sent so far and the aforementioned proposal texts.
Best Regards Emilio Madaio Policy Development Officer RIPE NCC
-----oooooooo-------- SUMMARIES:
1) The first proposal's scope regards the display of the MD5 password hashes in the "auth:" attribute. Since then the DB department published an article recommending the technical solutions of, in short:
-filtering out "auth:" attributes from all query results on MNTNER objects -adjusting Webupdates to require maintainer password authorisation over HTTPS before presenting the object to the user for updating.
This solution can be easy and quick to implement. They only need some discussion in the DB WG.
2) The second proposal's scope regards the restriction to secure channels for all the possible mntner authentications. In this instance as well, the NCC can provide some quick technical alternatives for the DB WG to discuss.
-------- Original Message -------- [..]
Date: Tue, 15 Nov 2011 09:44:31 +0000 From: David Freedman <david.freedman@eu.clara.net> To: db-wg-chairs@ripe.net Subject: My proposals
Hi there,
On 08/11 I sent you two policy proposals for review, concerning the publication and use of MD5 authentication attributes in the database.
Since then, Denis Walker has published an article on RIPE labs describing a potential solution to one of these issues
https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-da tab ase
Could you please tell me what happens next in the scope of both my proposals and security community support for Denis' idea?
Regards,
David Freedman
Date: Tue, 8 Nov 2011 16:10:35 +0000 From: David Freedman <david.freedman@eu.clara.net> To: db-wg-chairs@ripe.net Subject: Re: Policy Proposal "Removal of auth: MD5-PW from WHOIS information"
s/scheme/schemes, apologies
On 08/11/2011 16:03, "David Freedman" <david.freedman@eu.clara.net> wrote:
Please see below:
---------------------------
Number: (assigned by the RIPE NCC)
Policy Proposal Name: Removal of auth: MD5-PW from WHOIS information
Author: a. David Freedman
b. david.freedman@uk.clara.net
c. Claranet
Proposal Version: (assigned by the RIPE NCC)
Submission Date: 8/11/2011
Suggested RIPE WG for discussion and publication: Database Working Group
Proposal Type: a. new
Policy Term: b. Indefinite
Summary of proposal: Policy text: b. New policy text
This is a proposal to remove the display the "auth:" attribute for auth type "MD5-PW" in WHOIS information, in order to increase the security of a number of user's mntner objects.
Rationale: a. Arguments supporting the proposal
Numerous sources have demonstrated the vulnerability of the MD5-PW to compromise when presented with modern compute power, a number of alternate "auth" scheme exist which provide far more security to the mntner. By allowing these attributes to be exposed in WHOIS information, malicious entities could direct their efforts to computing a plaintext input of the hash and thus compromise mntner objects (and hence protected resources) of their choice.
b. Arguments opposing the proposal
The database group state: "Since any change in the current process means significantly changing the behaviour of the RIPE Database* and will break existing use cases of the system, it is not something the RIPE NCC can make a decision on.", this could involve significant work for the Database Group.
*- As an example, current Update process requires the full object -including the hashes for maintainer objects- to be used in the update message.
---------------------------
Date: Tue, 8 Nov 2011 16:10:14 +0000 From: David Freedman <david.freedman@eu.clara.net> To: db-wg-chairs@ripe.net Subject: New proposal : Prevention of use of MD5-PW over insecure channels
See below
-----------
Number: (assigned by the RIPE NCC)
Policy Proposal Name: Prevention of use of MD5-PW over insecure channels
Author: a. David Freedman
b. david.freedman@uk.clara.net
c. Claranet
Proposal Version: (assigned by the RIPE NCC)
Submission Date: 8/11/2011
Suggested RIPE WG for discussion and publication: Database Working Group
Proposal Type: a. new
Policy Term: b. Indefinite
Summary of proposal: Policy text: b. New policy text
This is a proposal to ensure that all mntner authentication which makes use of MD5-PW for an object transaction, do so over a secure channel, in order to increase the security of such transactions.
Rationale: a. Arguments supporting the proposal
Numerous sources have demonstrated the vulnerability of the MD5-PW to compromise when presented with modern compute power, a number of alternate "auth" schemes exist which provide far more security to the mntner. By allowing the plaintext password to be passed over insecure channels, information could be intercepted and the plaintext password obtained, potentially compromising mntner objects (and hence protected resources).
b. Arguments opposing the proposal
A number of object maintainers may currently make use of such insecure channels (for example, unencrypted SMTP), these functions may be related to legacy systems which are costly to update.
-----------
Date: Tue, 8 Nov 2011 16:03:30 +0000 From: David Freedman <david.freedman@eu.clara.net> To: db-wg-chairs@ripe.net Subject: Policy Proposal "Removal of auth: MD5-PW from WHOIS information"
Please see below:
---------------------------
Number: (assigned by the RIPE NCC)
Policy Proposal Name: Removal of auth: MD5-PW from WHOIS information
Author: a. David Freedman
b. david.freedman@uk.clara.net
c. Claranet
Proposal Version: (assigned by the RIPE NCC)
Submission Date: 8/11/2011
Suggested RIPE WG for discussion and publication: Database Working Group
Proposal Type: a. new
Policy Term: b. Indefinite
Summary of proposal: Policy text: b. New policy text
This is a proposal to remove the display the "auth:" attribute for auth type "MD5-PW" in WHOIS information, in order to increase the security of a number of user's mntner objects.
Rationale: a. Arguments supporting the proposal
Numerous sources have demonstrated the vulnerability of the MD5-PW to compromise when presented with modern compute power, a number of alternate "auth" scheme exist which provide far more security to the mntner. By allowing these attributes to be exposed in WHOIS information, malicious entities could direct their efforts to computing a plaintext input of the hash and thus compromise mntner objects (and hence protected resources) of their choice.
b. Arguments opposing the proposal
The database group state: "Since any change in the current process means significantly changing the behaviour of the RIPE Database* and will break existing use cases of the system, it is not something the RIPE NCC can make a decision on.", this could involve significant work for the Database Group.
*- As an example, current Update process requires the full object -including the hashes for maintainer objects- to be used in the update message.
---------------------------
David Kessens ---
Dear colleagues, Thank you very much for your feedback on this issue. Based on your input, the RIPE NCC will move forward with implementing a solution to this issue at a technical level, and will not submit this solution to the RIPE Policy Development Process. More information on the MD5 hash issue and the RIPE NCC's proposed technical solution can be found in the RIPE Labs article available at: https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database This change will now be implemented as a high priority. We will notify the community as soon as the change has been implemented and the system is ready to go live. We still need to work with the community to develop a solution for sending clear passwords for email updates. The RIPE NCC will consult with the community to resolve this issue once the MD5 hash solution is in place. Regards, Emilio Madaio Policy Development Officer RIPE NCC On 12/13/11 11:10 AM, Nigel Titley wrote:
I think we've seen enough support for this in the community for this to go ahead without invoking the PDP, which as David K has said is really overkill for this sort of thing.
RIPE NCC can you start this off please?
Thanks
Nigel
-----Original Message----- From: db-wg-bounces@ripe.net [mailto:db-wg-bounces@ripe.net] On Behalf Of David Freedman Sent: 13 December 2011 09:07 To: David Kessens; Emilio Madaio Cc: pdo@ripe.net; Database WG Subject: Re: [db-wg] MD5 and Password Security in the RIPE DB, Fwd: Wonder if you can help - re: PDP
My apologies for sending the previous email to the full working group.
That's OK, Thanks for sharing :) , this reply back to list is intentional.
With regards to my first proposal, I'd like to quote from Denis' article I cited:
"Next steps * If the community agrees to the deployment of this change, the RIPE NCC will develop and deploy it in a short space of time.
* The RIPE NCC will then contact all the maintainers of MNTNER objects containing passwords and ask them to change these for new, strong passwords. "
Added by Emilio:
" They only need some discussion in the DB WG."
Since this has now been discussed over the scope of two meetings (62 + 63), *and* on the mailing list, Can we please agree that the end-result is a good thing(tm), allow the NCC to implement this and move on with our lives?
Dave.
On 12/12/2011 19:15, "David Kessens" <david.kessens@nsn.com> wrote:
Emilio, Wilfried, Nigel,
Emilio wrote:
My apologies for sending the previous email to the full working group. It was intended for the Database Working Group Chairs.
But now that you accidentaly mailed us, I would like to take the opportunity to mention that I believe that we don't need the PDP process invoked for these kind of changes.
I hope that we as a community have not petrified that far that we cannot request the RIPE NCC to make a change to the RIPE database and be done with it. To say it in a different way, the issue at hand is much closer (but not quite the same) to a bug fix/operational issue than a public policy change.
David Kessens PS And regarding the topic of shadow passwords in the RIPE database, you might be interested in the following presentation by me from 1995, page 11: ftp://ftp.ripe.net/ripe/presentations/ripe-m22-david-DB-REPORT.ps.gz ---
On Mon, Dec 12, 2011 at 10:55:23AM +0100, Emilio Madaio wrote:
Hi Nigel and Wilfried,
as promised last week to Nigel, I'd like to make a short recap and have your attention on the following.
I have been contacted by David Freedman in regards of a couple of policy proposals he sent you for review and possible submission to the PDP. Below you can find, for more details, my summaries of the proposals and what analysis we did in the NCC.
As you will see, both cases can be tackled by the NCC with ideas that can be discussed by the DB WG and, if approved, easily implemented. Among the possible decisions you can take, there are also:
-starting discussion in the mailing list now; or -present and discuss at RIPE 64.
Obviously we can consider, as David asked, to start the PDP if you deem it necessary.
In any case, David did not have a chance to hear from you, so I kindly ask you to let him know, either your decision or that you acknowledged his intentions.
And please do not hesitate to let me know how I can help.
I included the email he sent so far and the aforementioned proposal texts.
Best Regards Emilio Madaio Policy Development Officer RIPE NCC
-----oooooooo-------- SUMMARIES:
1) The first proposal's scope regards the display of the MD5 password hashes in the "auth:" attribute. Since then the DB department published an article recommending the technical solutions of, in short:
-filtering out "auth:" attributes from all query results on MNTNER objects -adjusting Webupdates to require maintainer password authorisation over HTTPS before presenting the object to the user for updating.
This solution can be easy and quick to implement. They only need some discussion in the DB WG.
2) The second proposal's scope regards the restriction to secure channels for all the possible mntner authentications. In this instance as well, the NCC can provide some quick technical alternatives for the DB WG to discuss.
-------- Original Message -------- [..]
Date: Tue, 15 Nov 2011 09:44:31 +0000 From: David Freedman <david.freedman@eu.clara.net> To: db-wg-chairs@ripe.net Subject: My proposals
Hi there,
On 08/11 I sent you two policy proposals for review, concerning the publication and use of MD5 authentication attributes in the database.
Since then, Denis Walker has published an article on RIPE labs describing a potential solution to one of these issues
https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-da tab ase
Could you please tell me what happens next in the scope of both my proposals and security community support for Denis' idea?
Regards,
David Freedman
Date: Tue, 8 Nov 2011 16:10:35 +0000 From: David Freedman <david.freedman@eu.clara.net> To: db-wg-chairs@ripe.net Subject: Re: Policy Proposal "Removal of auth: MD5-PW from WHOIS information"
s/scheme/schemes, apologies
On 08/11/2011 16:03, "David Freedman" <david.freedman@eu.clara.net> wrote:
Please see below:
---------------------------
Number: (assigned by the RIPE NCC)
Policy Proposal Name: Removal of auth: MD5-PW from WHOIS information
Author: a. David Freedman
b. david.freedman@uk.clara.net
c. Claranet
Proposal Version: (assigned by the RIPE NCC)
Submission Date: 8/11/2011
Suggested RIPE WG for discussion and publication: Database Working Group
Proposal Type: a. new
Policy Term: b. Indefinite
Summary of proposal: Policy text: b. New policy text
This is a proposal to remove the display the "auth:" attribute for auth type "MD5-PW" in WHOIS information, in order to increase the security of a number of user's mntner objects.
Rationale: a. Arguments supporting the proposal
Numerous sources have demonstrated the vulnerability of the MD5-PW to compromise when presented with modern compute power, a number of alternate "auth" scheme exist which provide far more security to the mntner. By allowing these attributes to be exposed in WHOIS information, malicious entities could direct their efforts to computing a plaintext input of the hash and thus compromise mntner objects (and hence protected resources) of their choice.
b. Arguments opposing the proposal
The database group state: "Since any change in the current process means significantly changing the behaviour of the RIPE Database* and will break existing use cases of the system, it is not something the RIPE NCC can make a decision on.", this could involve significant work for the Database Group.
*- As an example, current Update process requires the full object -including the hashes for maintainer objects- to be used in the update message.
---------------------------
Date: Tue, 8 Nov 2011 16:10:14 +0000 From: David Freedman <david.freedman@eu.clara.net> To: db-wg-chairs@ripe.net Subject: New proposal : Prevention of use of MD5-PW over insecure channels
See below
-----------
Number: (assigned by the RIPE NCC)
Policy Proposal Name: Prevention of use of MD5-PW over insecure channels
Author: a. David Freedman
b. david.freedman@uk.clara.net
c. Claranet
Proposal Version: (assigned by the RIPE NCC)
Submission Date: 8/11/2011
Suggested RIPE WG for discussion and publication: Database Working Group
Proposal Type: a. new
Policy Term: b. Indefinite
Summary of proposal: Policy text: b. New policy text
This is a proposal to ensure that all mntner authentication which makes use of MD5-PW for an object transaction, do so over a secure channel, in order to increase the security of such transactions.
Rationale: a. Arguments supporting the proposal
Numerous sources have demonstrated the vulnerability of the MD5-PW to compromise when presented with modern compute power, a number of alternate "auth" schemes exist which provide far more security to the mntner. By allowing the plaintext password to be passed over insecure channels, information could be intercepted and the plaintext password obtained, potentially compromising mntner objects (and hence protected resources).
b. Arguments opposing the proposal
A number of object maintainers may currently make use of such insecure channels (for example, unencrypted SMTP), these functions may be related to legacy systems which are costly to update.
-----------
Date: Tue, 8 Nov 2011 16:03:30 +0000 From: David Freedman <david.freedman@eu.clara.net> To: db-wg-chairs@ripe.net Subject: Policy Proposal "Removal of auth: MD5-PW from WHOIS information"
Please see below:
---------------------------
Number: (assigned by the RIPE NCC)
Policy Proposal Name: Removal of auth: MD5-PW from WHOIS information
Author: a. David Freedman
b. david.freedman@uk.clara.net
c. Claranet
Proposal Version: (assigned by the RIPE NCC)
Submission Date: 8/11/2011
Suggested RIPE WG for discussion and publication: Database Working Group
Proposal Type: a. new
Policy Term: b. Indefinite
Summary of proposal: Policy text: b. New policy text
This is a proposal to remove the display the "auth:" attribute for auth type "MD5-PW" in WHOIS information, in order to increase the security of a number of user's mntner objects.
Rationale: a. Arguments supporting the proposal
Numerous sources have demonstrated the vulnerability of the MD5-PW to compromise when presented with modern compute power, a number of alternate "auth" scheme exist which provide far more security to the mntner. By allowing these attributes to be exposed in WHOIS information, malicious entities could direct their efforts to computing a plaintext input of the hash and thus compromise mntner objects (and hence protected resources) of their choice.
b. Arguments opposing the proposal
The database group state: "Since any change in the current process means significantly changing the behaviour of the RIPE Database* and will break existing use cases of the system, it is not something the RIPE NCC can make a decision on.", this could involve significant work for the Database Group.
*- As an example, current Update process requires the full object -including the hashes for maintainer objects- to be used in the update message.
---------------------------
David Kessens ---
Nigel, On Tue, Dec 13, 2011 at 10:10:56AM +0000, Nigel Titley wrote:
I think we've seen enough support for this in the community for this to go ahead without invoking the PDP, which as David K has said is really overkill for this sort of thing.
RIPE NCC can you start this off please?
first off, the various proposals really are not PDP issues, so thanks for getting the procedural question sorted. However, what is 'this' in the request above? My current understanding is that we have been going in circles for quite a while with two bullet items being suggested:
1) The first proposal's scope regards the display of the MD5 password hashes in the "auth:" attribute. Since then the DB department published an article recommending the technical solutions of, in short:
-filtering out "auth:" attributes from all query results on MNTNER objects -adjusting Webupdates to require maintainer password authorisation over HTTPS before presenting the object to the user for updating.
This solution can be easy and quick to implement. They only need some discussion in the DB WG.
while I agree that concealing the hashes actually sound like a reasonable approach, it sacrifices a DB invariant, which is: every object will be displayed as-is (-B and other options non-withstanding).
2) The second proposal's scope regards the restriction to secure channels for all the possible mntner authentications. In this instance as well, the NCC can provide some quick technical alternatives for the DB WG to discuss.
So, what can we expect the NCC to 'start off'? Apologies for my confusion, Peter
On 13/12/2011 15:04, "Peter Koch" <pk@DENIC.DE> wrote:
while I agree that concealing the hashes actually sound like a reasonable approach, it sacrifices a DB invariant, which is: every object will be displayed as-is (-B and other options non-withstanding).
I guess yes, it does, MNTNER can't be displayed as-is if it is going to leak information like that (unless anybody can think of a better idea?, and yes, deprecating MD5 would be a lot simpler, but this is the approach which had supposedly the least pain). I'm sure also the FTP dumps will be tidied up and people will be advised to change these passwords to prevent an attack based off archived data? Dave.
On Tue, 2011-12-13 at 17:36 +0000, David Freedman wrote:
I'm sure also the FTP dumps will be tidied up and people will be advised to change these passwords to prevent an attack based off archived data?
AFAIK the FTP dumps are already "clean" as far as passwords. -- Shane
Peter, On Tue, Dec 13, 2011 at 03:04:47PM +0100, Peter Koch wrote:
first off, the various proposals really are not PDP issues, so thanks for getting the procedural question sorted. However, what is 'this' in the request above?
I hope the 'this' is two implementation plans for the two proposals with enough detail that people understand the pros and cons and brief enough that we don't make this a giant bureaucratic exercize that eats up valuable time that can be used to actually implement the plan. I even don't mind if the plan for option 1 gets implemented right away as long as the working group gets a chance to roll back/tune things if they are slightly different from what we hoped for.
while I agree that concealing the hashes actually sound like a reasonable approach, it sacrifices a DB invariant, which is: every object will be displayed as-is (-B and other options non-withstanding).
I fully agree that it should not go unnoticed that we are sacrificing this feature. I don't like it myself but I don't see how this can be avoided if we want to have a short/medium term fix before real accidents happen and without major overhauls of the security functionality. David Kessens ---
participants (6)
-
David Freedman -
David Kessens -
Emilio Madaio -
Nigel Titley -
Peter Koch -
Shane Kerr