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

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

At 09:24 PM 3/11/2004, Hallvard B Furuseth wrote:
>>>>> 7. Simple Authentication
>>>>>    An LDAP client may establish an LDAP association by sending a Bind
>>>>>    Request with a name value consisting of an LDAP distinguished name
>>>>>    [LDAPDN] and specifying the simple authentication choice with a
>>>>>    password value.
>>>> 
>>>> s/an LDAP distinguished name/a distinguished name in LDAP string
>>>> form [LDAPDN]/
>>> 
>>> I don't see why, except the [LDAPDN] reference.
>> 
>> Because the term "LDAP distinguished name" is ambiguous.  It could
>> mean an X.500 DN, or the LDAP string representation of a X.500 DN.
>
>I don't really care about just this change, if it's not repeated in
>other places, but:

I haven't looked at all the other places.  The key is it avoid
the term "LDAP DN" as it is ambiguous.  The ambiguity leads to
improper implementation of DN matching (comparing representations
of DN instead of properly comparing the DN values).

>everywhere core LDAP mentions DNs (except in [LDAPDN] itself) it
>means the LDAP string representation.

Whether you are referring to the current LDAP TS [RFC3377] or the
revised LDAP TS [Roadmap], I doubt this statement is correct.  The
very fact you state this kind of makes the case for more clarification
in this area.

>Actually, if we are going to fiddle with this one, I would rather
>shorten it:  'with a name (a DN [LDAPDN]) and specifying...'.

Since you referring to the name, not the name value, the reference
should be to [Models][X.501] not [LDAPDN].

>In any case, there are plenty of other places in [Authmeth] and some in
>[Protocol] that talk about DNs or LDAP DNs without clarifying that they
>mean the LDAP string representation.

In protocol, the term "LDAP DN" should be replaced with either
"DN" or "LDAPDN" or "string representation of the DN".

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

>Doing so doesn't even restrict what it may contain, since an OCTET
>STRING can contain anything.

Yes, but stating that it is an OCTET STRING reminds implementors that
they should be capable of handling (in terms of the protocol) any
arbitrary value.   For instance, where a server uses an external system
capable of storing only UTF-8 passwords, the server shouldn't puke
because the value wasn't restricted to UTF-8.

>And to encode the provided value with the
>correct ASN.1 type is a [Protocol] matter, not an [Authmeth] matter.

But using the value in the server is an [Authmeth] matter.  The
server implementor needs to reminded that protocol is providing
an OCTET STRING.

>Are we also going to specify that SaslCredentials.mechanism is an
>LDAPString and SaslCredentials.credentials an OCTET STRING when their
>values are mentioned too?

I'm not aware of any confusion there.

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

>>> - [SASLprep] may apply first.
>> 
>> Application of SASLprep, where necessary, is done by the binding
>> client
>
>Application to the client-side password, yes.  Application to the
>server-side password, no.

I think 'binding client' makes it pretty clear as to which side
I was referring to here.

>> and by password management client (or other management agent).
>
>I don't know what that means,

I likely should have just said "password management entity".

>but if it means the server-side password
>checker,

I don't necessarily (and generally don't) mean the "checker"
(see below).

>you just contradicted that comparison is done octet wise.

Not really.  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.)

>> The rest of your message seems to be a rehash external password
>> system limitations we already discussed in depth.
>
>If you refer to the SASLprep thread, yes.  But in that case there was a
>workaround:  One can choose passwords that SASLprep does not modify.

It is intended one can do that as well here.  See below.

>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.  A simple rewording should
provide plenty of wiggle room.

Kurt