Re: Authentication issues (Re: authmeth review notes [long])

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

I'm going to avoid responding with nested comments as things are
getting a bit convoluted.

LDAP simple bind method is related to the X.500 simple bind method.
(DIGEST-MD5 is tangential.)

As LDAP servers are to act in accordance with X.500, understanding
how simple bind works in X.500 is key to understanding how LDAP
servers are to act.  X.500 is quite clear that simple bind shared
secret is an octet string and is to be compared in an octet wise
manner.  One can argue that X.500 is even more restrictive
(requires userPassword), but I think it also can be reasonable
be argued the X.500 allowed a limited amount wiggle room here.

I think simply saying that the LDAP simple bind shared secret
is an OCTET STRING to be compared in an octet wise manner gives
plenty of wiggle room, but then it seems I am taking a more
liberal view of what 'shared' and what 'manner' means here.

I don't think 'shared' means that server necessarily has
knowledge of the secret, but that it is able to verify
that the client has knowledge of the secret, an OCTET STRING.
And 'manner' doesn't necessarily imply that this verification
needs to be perfect, but that the server can use a reasonable
verification method.  That is, I think this allows use
of hashes because comparison of hashes is reasonable
verification that the client shares the secret.

Another way to look at this: the specification is providing
a conceptional view of the process, implementation details
may vary.  This is good way to look at the SASLprep issue.

The key SASLprep point is, when textual passwords are used,
that shared secret is the output of SASLprep.  That is what
the client puts on the wire and that's what is to be
verified.

A server is certainly free to, instead of storing this
shared secret, to store something else which can reasonable
be used for verification purposes.  And just as the server
can hash the asserted value as part of the verification
process, a server can apply other reasonable mappings to
the asserted value.

If a server stores the SHA1 hash of a UTF32 password, it
should ensure that stores SASLprep'ed password (or it
restricts passwords to those which x=SASLprep(x)).
Then it compare function can be written:
  if assertedPassword is (looks like) UTF-8;
  then return storedPassword equals
        SHA1(toUTF32(SASLprep(assertedPassword)))
  else return FALSE

This comparison can be said to act in an octet wise manner
as it reasonable verification that the client has knowledge
of the shared secret, an OCTET STRING.

Kurt


At 07:34 AM 3/13/2004, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>>At 09:24 PM 3/11/2004, Hallvard B Furuseth wrote:
>
>>>>>>> 7. Simple Authentication
>
>>>>>> s/password value/password value, an OCTET STRING.
>>>>>
>>>>> Why?
>>>>
>>>> Because the value, in the protocol, is an OCTET STRING.
>>>
>>> That's why it's pointless to specify it.
>>
>> No.  It is reenforcing that this value, which has been misinterpreted
>> as being a character string, is in fact an OCTET STRING.
>
>OK.  A slight change, to make it look less like a definition:
>
>s/password value/password value (an OCTET STRING)/.
>
>
>>>>>>>    DSAs that map the DN sent in the bind request to a directory entry
>>>>>>>    with an associated set of one or more passwords will compare the
>>>>>>>    presented password to the set of passwords associated with that
>>>>>>>    entry.
>>>>>
>>>>>> s/more passwords/more passwords, each an OCTET STRING,/
>>>>>> s/compare/compare octet wise/
>>>>>
>>>>> No!
>>>>
>>>> This mechanism's shared secret has always been an OCTET STRING,
>>>> to be compared octet wise.  (...)
>>>
>>> I can find no indication of either claim in RFC 2251.
>>
>> RFC 2251 has lots a holes.
>
>If you mean 'hole' as in under-specified compared to X.500, as far as I
>can tell LDAP already differs from X.500 in this respect, in that X.500
>does not support DIGEST-MD5.  An LDAP/X.500 server can support it over
>LDAP, but an LDAP-X.500 gateway can not.  You are also suggesting LDAP
>may use a password management entity or the authPassword attribute,
>while X.500 explicitly states that Simple bind must compare with the
>userPassword attribute (which contains plaintext passwords).
>I've only checked X.500(1993) very briefly just now, though:
>  X.511: 8.1 (Bind): Only simple/password & strong/certificate auth.
>  X.509: 6 (Simple auth): Bind operation sends password, server compares
>  with userPassword.
>
>
>Pasting back from your your previous message (I snipped it because I
>partly misunderstood you):
>
>> We cannot change that without causing loads of problems.
>
>I'm asking for a non-change, not a change.  RFC 2251 does not contain
>the text you wish to add.  So people must already be having those loads
>of problems.  Then why didn't LDAPbis find it necessary to address them
>years ago?  Which problems are you referring to anyway?
>
>I'm rearranging the following and snipping some misunderstandings and
>clarifications:
>
>>> In this case you are totally prohibiting anything else than The LDAP Way
>>> To Compare Passwords, which will _differ_ from what most systems do.
>>> And since that way will not even allow us to compare passwords by
>>> hashing the Bind password and comparing with a stored hash, we'll even
>>> be required to store all the users' plaintext passwords somewhere.  That
>>> is utterly unacceptable.
>>
>> The intent was to say things had to be compared in an octet wise
>> manner, but not necessarily octet wise.
>
>Still sounds like not hashing the bind password to me.  But just to be
>sure I know what you are talking about, I expect you mean something
>like: comparison where all bits (in each octet) are significant though
>there may be unorganized information loss?  (Organized information loss
>would allow caseIgnore comparison, or only checking the first 8 octets
>of the password like old Unix crypt() does.  Don't know if you wish to
>forbid both.  As you can tell, I wish to forbid neither.)
>
>As for 'passwords, each an OCTET STRING', that looks like a clear
>statement that the password itself must be represented in an octet
>string, and not some hash of it.  If you want this statement just so you
>can talk about octet wise comparison, and if my guess about what you
>meant with comparison above is OK, you can probably drop ", each an
>OCTET STRING" and instead say that when comparing, each bit in the
>password received over the protocol is significant.
>And then I will vote against that too:-)
>
>>>>> - [SASLprep] may apply first.
>
>I still don't get this:
>
>> When textual passwords are used, the shared secret
>> (on both sides) is the UTF-8 encoded output of SASLprep.  It is
>> storage mechanism specific when and where this preparation is done,
>> we can just say that the password management entity takes care of it.
>> (Note the preparation could occur before or after storage.)
>
>OK, but now the shared server-side secret is the plaintext password
>again, never a one-way hash of the password.  Having it in a password
>management entity doesn't fix that.
>
>-- 
>Hallvard