Subject: [ldapext] Any implementations using userPassword;hash-scheme?

From: Michael Ströder <[email-masked]>
Date: Sat, 26 Jan 2013 16:41:24 +0100

HI!

Is anyone here aware of any implementation using userPassword;hash-scheme?

It was described in RFC 2307 but starting with a rather vague text:
"A future standard may specify LDAP v3 attribute descriptions to represent
hashed userPasswords"

The text was already dropped in draft-howard-rfc2307bis-02 section 5.2.2.1.
but without any further explanation.

So I guess there are no implementations but I want to make sure.

Ciao, Michael.

---

From: Luke Howard <[email-masked]>
Date: Sun, 27 Jan 2013 14:24:08 +1100

I don't think you're going to find anything that uses this. nss_ldap supported authPassword as a compile-time option but, looking through the revision history, I can't find anything referring to attribute descriptions.

-- Luke

On 27/01/2013, at 2:41 AM, Michael Ströder <[email-masked]> wrote:

> _______________________________________________
> Ldapext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ldapext

--
Luke Howard / [email-masked]
www.padl.com / www.lukehoward.com

---

From: Andrew Sciberras <[email-masked]>
Date: Tue, 29 Jan 2013 11:22:15 +1100

Hi Michael

Yes, the ViewDS product does support attribute value hashing using
attribute options to convey the hash scheme.

Andrew

-- 

*Andrew Sciberras CISSP
*Managing Consultant

Suite 1, 85 - 87 Charles St, Kew 3101 VIC

*t *+61 3 9851 8633
*e * [email-masked] <[email-masked]>
*w *www.eb2bcom.com
*ln *LinkedIn <http://au.linkedin.com/pub/andrew-sciberras/2/223/876>

---

From: Michael Ströder <[email-masked]>
Date: Tue, 29 Jan 2013 09:04:54 +0100

Andrew Sciberras wrote:
> Yes, the ViewDS product does support attribute value hashing using attribute
> options to convey the hash scheme. 

Ok, I will extend the spec described in
draft-stroeder-hashed-userpassword-values
in the next revision.

Ciao, Michael.

> On Sun, Jan 27, 2013 at 2:41 AM, Michael Ströder <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     HI!
>

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 29 Jan 2013 03:18:34 -0800

> draft-stroeder-hashed-userpassword-values

In writing an I-D for publication as an RFC, there a few options:
	1) Standard Track
	2) Informational
	3) Experimental

The second two allow for independent submission (directly to the RFC Editor, don't require IETF consensus, but do require IESG no-objection (aimed at detecting trying to run a "standard" around the IETF)).

For this particular specification, given past experiences in the IETF LDAP WGs and userPassword, I suspect you'll run into standardization issues.  Even if the IETF wanted to extend userPassword (which is questionable), the IETF doesn't own the specification of userPassword in the Directory.  That's owned by the ISO/ITU X.500 committee.  So changes/extensions to userPassword ought to be taken there, not to the IETF.

Experimental is for, well experiments.  Though 2307 was an experiment, I think we can say that experiment should be concluded.  One could have this I-D conclude the part about userPassword.  And informational would be an appropriate track to do especially since given the above userPassword standardization issue.

Informational is also a very good track on stating what current practice is.  In addition to providing a specification of that practice (which should note differences seen in the wild, especially those impacting interoperability), it should talk about other issues, such as interoperability issues with implementations adhering to the standard specifications (here the standard userPassword specification).   I think security issues are important to discuss here (a bit on that in a second).

I see this document is marked as being intended to be published as Informational, but it reads more like it's trying to be a standard.  I think trying to standardize this will not go far, so I suggest you take a 'document current practice' approach here (make it clear in the abstract and intro that's what the purpose of the document is, and then fulfill that purpose throughout the document).   Gold star if you conclude the 2307 experiment, at least in the userPassword area.

Security Considerations:  I think that it should be made clear that all of these schemes in the doc are quite prone to dictionary and brute force attack.  The viability of these attacks is not generally impacted by the length of the hash but by rate in which the attacker produce a value from an input.   (Salted variants hinders pre-computed dictionary attacks.)

I note that at Isode we have a 2307 style hash scheme that we use to hold SCRAM compatible hash.  Aside from being SCRAM compatible, it's designed to hinder dictionary and brute force attacks by significant increasing the cost of producing the stored value.   It would be good to include this as part of the 'current practice'.

-- Kurt

---

From: Michael Ströder <[email-masked]>
Date: Tue, 29 Jan 2013 22:22:25 +0100

Kurt,

thanks for your feedback.

Kurt Zeilenga wrote:
> The second two allow for independent submission (directly to the RFC
> Editor, don't require IETF consensus, but do require IESG no-objection
> (aimed at detecting trying to run a "standard" around the IETF)).

I'm not trying to run a standard around IETF. My aim is just to write down
what's current practice.

> For this particular specification, given past experiences in the IETF LDAP
> WGs and userPassword, I suspect you'll run into standardization issues.
> Even if the IETF wanted to extend userPassword (which is questionable), the
> IETF doesn't own the specification of userPassword in the Directory.
> That's owned by the ISO/ITU X.500 committee.  So changes/extensions to
> userPassword ought to be taken there, not to the IETF.

Even if ISO/ITU X.500 committee and IETF see standardization problems this
'userPassword' hash syntax is widely used. I feel it should be documented
pointing out the deficiencies and standardization issues - but fully and
completely documented.

> Experimental is for, well experiments.  Though 2307 was an experiment, I
> think we can say that experiment should be concluded.  One could have this
> I-D conclude the part about userPassword.  And informational would be an
> appropriate track to do especially since given the above userPassword
> standardization issue.

Well, draft-howard-rfc2307bis-02.txt also aims to be published as
Informational which seems appropriate to me given the wide use of the schema
described therein.

> Informational is also a very good track on stating what current practice
> is.  In addition to providing a specification of that practice (which
> should note differences seen in the wild, especially those impacting
> interoperability), it should talk about other issues, such as
> interoperability issues with implementations adhering to the standard
> specifications (here the standard userPassword specification).   I think
> security issues are important to discuss here (a bit on that in a second).

I thought that there is already some text pointing out possible interop issues
and security issues. Please provide more concrete points which are missing in
your opinion.

> I see this document is marked as being intended to be published as
> Informational, but it reads more like it's trying to be a standard.

Well, you don't want me to write a bad/incomplete document just to discourage
the use of this syntax - do you?

> I think trying to standardize this will not go far, so I suggest you take
> a 'document current practice' approach here

That 'document current practice' was exactly my plan but still being precise
in what is described.

> (make it clear in the abstract
> and intro that's what the purpose of the document is, and then fulfill that
> purpose throughout the document).

The abstract already contains "Furthermore it points out some of the
deficiencies of that approach.". I cannot imagine how to be more clear in the
abstract. You're welcome to provide better wording.

> Gold star if you conclude the 2307 experiment, at least in the userPassword
> area.

Not sure what you mean with "conclude" here.

Like it or not I'd estimate that over 95% of LDAP bind requests sent to LDAP
servers are simple bind requests against hashed passwords (IMHO I'm
underestimating here). But until now the hash syntax was not fully specified
anywhere. This draft is just documentation of what's widely used.

IMO there are enough hints to AuthPassword and SCRAM RFCs to point the reader
into the right direction and there's no wording in this draft which hinders
people implementing SCRAM.

> Security Considerations:  I think that it should be made clear that all of
> these schemes in the doc are quite prone to dictionary and brute force
> attack.  The viability of these attacks is not generally impacted by the
> length of the hash but by rate in which the attacker produce a value from
> an input.   (Salted variants hinders pre-computed dictionary attacks.)

The Security Considerations already includes:

   Applications SHOULD NOT use the non-salted password hash schemes and
   SHOULD use a sufficiently long salt value.
[..]
   As flaws may be discovered in the hashing algorithm or with a
   particular implementation of the algorithm or values could be subject
   to various attacks if exposed, values in attribute 'userPassword'
   SHOULD be protected as if they were clear text passwords.  Especially
   it is RECOMMENDED to avoid using hashing schemes based on MD-5
   because of known weaknesses of this digest algorithm [RFC6151].
   (taken from RFC 3112 like mentioned in "Acknowledgements")

I've changed/extended it to:

   Hashed values in attribute 'userPassword' SHOULD be protected as if
   they were clear text passwords because they are subject to dictionary
   or other attacks and flaws may be discovered in the hashing algorithm
   or with a particular implementation of the algorithm.

   Especially it is RECOMMENDED to avoid using hashing schemes based on
   MD-5 because of known weaknesses of this digest algorithm [RFC6151].

   Applications SHOULD NOT use the non-salted password hash schemes and
   SHOULD use a sufficiently long salt value.

How to make things more clear?

> I note that at Isode we have a 2307 style hash scheme that we use to hold
> SCRAM compatible hash.  Aside from being SCRAM compatible, it's designed to
> hinder dictionary and brute force attacks by significant increasing the
> cost of producing the stored value.   It would be good to include this as
> part of the 'current practice'.

You're welcome to provide more information about that to be added.

Ciao, Michael.

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 29 Jan 2013 14:23:05 -0800

My comments were not intended to discourage to try to produce a RFC in this area, but to provide some insight on issues you will face getting anything in this area published as an RFC.

I think an RFC that discussed how standard and various current practices (note, not singuaral) differ, how the range of current practices differ, and all of this impacts these differences upon interoperability and security and other areas of concern, would be useful.

A document is simply a technical specification of some additional hash schemes to an experimental extension is likely not to go down well in the IETF or the X.500 standards committee, especially if proposed to be published as anything but experimental independent-submission RFC.

Again, this is not intended to discourage you from trying... but more to let you know what you are getting yourself into.

-- Kurt

---

From: Michael Ströder <[email-masked]>
Date: Tue, 29 Jan 2013 23:59:39 +0100

Kurt Zeilenga wrote:
> My comments were not intended to discourage to try to produce a RFC in this
> area, but to provide some insight on issues you will face getting anything
> in this area published as an RFC.

Noted. Thanks.

> I think an RFC that discussed how standard and various current practices
> (note, not singuaral) differ, how the range of current practices differ,
> and all of this impacts these differences upon interoperability and
> security and other areas of concern, would be useful.

Hmm, this is beyond the scope of draft-stroeder-hashed-userpassword-values.
I think such a comparsion should not include the detailed specifications for
particular mechanisms. IMHO my document could be simply one of the documents
such a comparsion could refer to.

Ciao, Michael.