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

From: Hallvard B Furuseth <[email-masked]>
Date: Sun, 4 Apr 2004 21:13:50 +0200

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

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sun, 4 Apr 2004 22:24:11 +0200

Kurt D. Zeilenga writes:
>At 10:09 AM 3/9/2004, Hallvard B Furuseth wrote:
>
>>>>    (2) Client authorization by means of access control based on the
>>>>        requestor's authenticated identity,
>>>
>>> Given that LDAP doesn't offer an authorization (access control)
>>> model, this seems dubious (even with the note below).  However, I
>>> don't have a suggestion (at the moment) on how to better address
>>> this.
>>
>> Put "Servers are expected to support" in front of the sentence?
>
> I don't think servers are necessarily expected to support a means of
> access control.  There are, after all, servers which do not support
> any form of authentication.  But more importantly, this list is of
> security services LDAP provides.  I don't think LDAP provide this
> expectation and, even if it did, it's only an expectation.

All true, but on the other hand, parts of Authmeth - at least the
authorization identity - are mostly pointless without access control,
while Bind in general is mostly done for access control in many
situations.  So I think we do need to mention it somehow.

Maybe

   (2) Servers can implement client authorization by means of access
       control based on the requestor's authenticated identity, though
       this is not part of this standard,

or turn it around a bit:

   (2) Server implementations can make use of the requestor's
       authenticated identity to implement client authorization by
       means of access control, though how to do so is not part of
       this standard,

Anyway, I've said my piece now and won't kick if (2) is deleted.

>>>>    Given the presence of the Directory, there is a strong desire to see
>>>>    mechanisms where identities take the form of an LDAP distinguished
>>>>    name [LDAPDN] and authentication data can be stored in the
>>>>    directory.
>>>
>>> s/see/use/
>>> s/take the form of an LDAP distinguished name/
>>> s/are represented as distinguished names [X.501][Models] in string
>>> form [LDAPDN]/.
>>
>>>>                This means that this data must be updated outside the
>>>>    protocol or only updated in sessions well protected against
>>>>    snooping.
>>>
>>> s/snooping/eavesdropping/ (use RFC2828 term)
>>
>> This sentence has nothing to do with DN identities and authentication
>> data in the directory.  It also applies if the server supports an
>> extended operation to modify passwords stored outside the directory,
>> with non-DN identities.  I think it belongs in Section 11 - unless
>
> This section is introductory.  It's providing some background as to
> why particular security services are offered and why particular
> applicability statements have been made.  Section 11 is basically
> stating a security consideration.

OK.  But then 'This means that' should be removed, and that sentence be
moved out of that paragraph.  At least I don't see the logic of why it
follows from the previous sentence.  The same applies to passwords _not_
stored in the directory, if there is an extended operation which can
update non-directory passwords.  Maybe the sentence should go to Section
11, maybe just to the next paragraph, I don't know.

>>> suggest:
>>>       It is also desirable to allow authentication methods to
>>>       carry identities (other than DNs) that are familiar to the
>>>       user or that are used in other systems.
>>
>> ...and also to authenticate against existing credentials maintained and
>> stored outside the LDAP installation.
>
> It can be argued that "used" encompasses both "maintained" and "stored".

True, but since this is an introductory text and not a text for
implementors to carefully interpret, it's better to be clear.
"used and/or stored" should be ample, though.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 04 Apr 2004 14:34:33 -0700

While I do not agree with many of your points (and could argue
them point by point), I'd like to refocus this discussion on
the offered text and how it could be word-smithed to be more
consistent the consensus already reached on a number of issues
in this area.

In particular,
>>>> s/compare/compare in an octet wise/ [as clarified]

is, I agree, problematic.  Mainly because it implies that the
each of the stored values is an OCTET STRING.  I also did
not intend to disallow use of various hash functions (or even
other functions such as U-Mich's ces) to be used in comparisons.
I do believe consensus did support changing the TS to allow
such (if it could be done in a reasonable manner).

My intent was more to clarify that the presented value is an
OCTET STRING and servers must be prepared to handle (but
not necessarily support) arbitrary content of this protocol
field.  While mostly a protocol issue, because of past problems
in this area, I think it something which [authmeth] should
at least hint to (and clarification to the earlier part of
this section should be sufficient).

Additionaly, as we discussed before, there are a number of
limitations on the kinds of password storage mechanisms that
can be used.  In particular, one's which require recovering
user input before application of SASLprep.  This likely can
be handled as a note to implementors.

To more this forward, I will shortly offer new changes for
the WG to consider.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 04 Apr 2004 19:27:16 -0700

At 01:24 PM 4/4/2004, Hallvard B Furuseth wrote:
>So I think we do need to mention it somehow.
>
>Maybe
>

Each of the paragraphs should be something which LDAP, as defined in this
specification, offers.  While it is true that LDAP implementations can
offer access controls, LDAP doesn't.  However, it can be said that LDAP
offers facilities to support local access control mechanisms (e.g.,
insufficientAccessRights result code).  So, maybe:
    (2) mechanisms to support vendor-specific access control facilities
       (LDAP does not offer a standard access control facility)

Alternatively, we could expand (1) to note that authentication methods
can be used in support of vendor-specific access control facilities.

>follows from the previous sentence.

I think it kind of follows from the concern "or worse, they will support
only clear text passwords that provide inadequate security for most
circumstances."   However, it's weak in that implies the mechanism
be used doesn't provide adequate protection itself (and not only for
itself, but also the session).

>The same applies to passwords _not_
>stored in the directory,

as well as to cases were the authentication identity is not in the form
of a DN.

>if there is an extended operation which can

I think it appropriate in the Introduction to state that because of the
strong desire to use simple DN+password, other plain text authentication
mechanisms, or mechanisms which do not provide data security services
for the session, it is desirable to define a mechanism for establishing
data security services at the transport layer.

Then in security considerations, we can focus on particular cases where
it important to establish data security services.

>"used and/or stored" should be ample, though.

I think "and/or stored" is distracting and hence less clear.  (It seems
quite irrelevant whether or not the identity used is ever stored.)  Are
just concerned that "used" is somehow more restrictive than
"used and/or stored"? A different wording might better address that
concern.  How about?
        It is also desirable to allow authentication methods to carry
        identities other than DNs, including ones familiar to the user
        or ones used in another system.