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

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Back to the discussion which started thus:

Kurt D. Zeilenga writes:

>>>>    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.  We cannot change that without causing
> loads of problems.


Kurt D. Zeilenga writes:

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

I think LDAP already differs too much from X.500 to reintroduce this
X.500 requirement now.  Both in implementation, and in the entire
situation about what one needs from Bind and password handling.

For one thing, LDAP implementations have been using password comparison
routines native to the system since Umich LDAP, and some of those in use
may not fit your interpretation of X.500's requirements.  Maybe some
system ignores whitespace or case, for example.  And I don't know if you
think Unix /etc/passwd-type password hashes are OK:  See below.

OTOH, LDAP simple bind lacks X.500's Simple Bind option with allows the
client to hash the password - with a seed which contains a random
component - before sending it to the server.  So LDAP Simple Bind
actually differs from X.500 in _both_ directions.

For the "formal" situation: LDAP has DIGEST-MD5, Simple Bind with
plaintext passwords over TLS, and EXTERNAL which may or may not use TLS
certificates.  X.500 has "native" certificates, and the above option to
hash Simple Bind passwords.  And maybe something parallel to TLS, I
don't know.

> 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 don't see where.  X.509 section 6 states plainly that Simple Bind
compares with userPassword, and even that it does so with the Compare
operation.

Also, if the X.500 client hashes the password sent with Simple Bind (it
also sends the seed), the server can't compute the same hash to compare
with unless it knows the plaintext password.  However, I don't know if
X.500 installations that support Simple Bind are required to enable this
option.

For that matter, I do not see the point in making part of the X.500 spec
explicit in LDAP at the same time as you state the intent of wiggling
out of that part of the spec.  Though you could resolve that with
another wording which more clearly says what you actually want.

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

Yup.  At least the 'manner' part.  I expect 'shared secret' may be OK
if the reader is expected to know the terminology of modern Internet
security, or something.  I hope they are not: I do not know it well.

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

So, getting back to a few examples: Will Unix crypt() from /etc/passwd
do for a hash function when we must compare 'in an octet wise manner'?
It doesn't sound like that to me, since the octets after the eight first
ones are ignored.  Do you intend to forbid that hash function?  Or if
you allow that, can you at the same time forbid a hash function which
first translates the passwords to lowercase?  Both variants
systematically ignore parts of the password.

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

OK.

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

Agreed, it can be said to do so.  Your suggested wording, however, can
easily be interpreted very differently.  So if we are going to introduce
this change, I suggest you provide a wording which doesn't need a lot of
explanation in order not to be misunderstood.

However, I still don't know why we should change it.  I've named some
things the change might break.  As I said, I like the current
flexibility (if one ignores the X.500 requirements), and I don't quite
buy that there will be 'loads of problems' if we 'change' the spec to
retain the rfc2251 meaning.  No, not quite the way you put it, I know:-)


Finally, I'm wondering about a possible oversight: Did you really intend
these restrictions to only apply to passwords associated with directory
entries?  If so I _really_ don't understand why you argue for strict
X.500 compatibility, at the same time leaving such a hole open.  What of
a DN/password store outside the directory which accidentally-on-purpose
"happens" to only include DNs that exist in the directory?

-- 
Hallvard