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

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

Kurt D. Zeilenga writes:
>At 10:09 AM 3/9/2004, Hallvard B Furuseth wrote:
>>>> 6. Anonymous Authentication
>>>> 
>>>>    Directory operations that modify entries or access protected
>>>>    attributes or entries generally require client authentication.
>>>>    Clients that do not intend to perform any of these operations
>>>>    typically use anonymous authentication.
>>> 
>>> I hope this is not typical.
>> 
>> Why?
> 
> Because even clients which access attributes or entries that don't
> require client authentication often authenticate anyway.

Fine, but that doesn't explain why you apparently think it's bad if many
clients don't do that.  Not that it matters to Authmeth, I'm just
curious.

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

No, [Protocol] specifies that BindRequest.name is an LDAPDN, as it
specifies the format or syntax of other fields used in [Authmeth].
[Authmeth] should not duplicate that work, except with reminders of what
[Protocol] says at places where we feel that is useful.  Here it is not
useful; everywhere core LDAP mentions DNs (except in [LDAPDN] itself) it
means the LDAP string representation.

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

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.

>>> 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.
Doing so doesn't even restrict what it may contain, since an OCTET
STRING can contain anything.  And to encode the provided value with the
correct ASN.1 type is a [Protocol] matter, not an [Authmeth] matter.

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

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

- userPassword is OCTET STRING, but implementations can just as well
  use other attributes.

- I can find no mention of how to compare Bind passwords or Simple Bind
  passwords in general.

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

> and by password management client (or other management agent).

I don't know what that means, but if it means the server-side password
checker, you just contradicted that comparison is done octet wise.

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

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.

-- 
Hallvard