[db-wg] MD5 and Password Security in the RIPE DB, Fwd: Wonder if you can help - re: PDP

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 at ripe.net [mailto:db-wg-bounces at ripe.net] On Behalf Of David Freedman
> Sent: 13 December 2011 09:07
> To: David Kessens; Emilio Madaio
> Cc: pdo at 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 at 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 at eu.clara.net>
>>> To: db-wg-chairs at 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 at eu.clara.net>
>>> To: db-wg-chairs at 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 at 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 at 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 at eu.clara.net>
>>> To: db-wg-chairs at 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 at 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 at eu.clara.net>
>>> To: db-wg-chairs at 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 at 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
>> ---
>>
> 
> 
>