[ldapext] draft-stroeder-hashed-userpassword-values-00.txt

[Michael Ströder <[e-mail]>]

Kurt,

thanks for your feedback.

Kurt Zeilenga wrote:
> 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)).

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.