[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-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 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
>---
>