On Jan 29, 2013, at 12:04 AM, Michael Ströder <[email protected]> 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 <[email protected]
>> <mailto:[email protected]>> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/ldapext
