On Jan 29, 2013, at 12:04 AM, Michael Ströder <michael@stroeder.com> wrote:

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

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



> 
> Ciao, Michael.
> 
>> On Sun, Jan 27, 2013 at 2:41 AM, Michael Ströder <michael@stroeder.com
>> <mailto:michael@stroeder.com>> wrote:
>> 
>>    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.
> 
> _______________________________________________
> Ldapext mailing list
> Ldapext@ietf.org
> https://www.ietf.org/mailman/listinfo/ldapext