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

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

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