Subject: LDAPDN and AuthMeth/DIGEST-MD5

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 18 Nov 1999 15:45:00 -0800

The AuthMeth draft does not specify a canonical DN form
for use with the DIGEST-MD5 algorithm.   Without such, the
server must dynamically determine response-value based upon
user provided DN and cleartext password stored for with this
DN.

I believe the AuthMeth draft should specify a canonical
DN form for use with the DIGEST-MD5 and similar mechanisms.
In fact, it may be appropriate to require use of this form
within AuthzIDs (though I suggest we remove AuthzIDs
altogether, but that another thread).

The AuthMeth draft should also clarify as whether or not the
DIGEST-MD5 username (and/or authzid) string provided by
client is string encoding of a DN, a string encoding of an
AuthMeth authzId, or a string encoding of a AuthMeth uAuthzId
userid value.  

I should also note that AuthMeth draft defined keywords
are easily confused with DIGEST-MD5 keywords (authzid
vs authzId).  I suggest that AuthMeth rename its authzId
keyword.

In addition, The AuthMeth document does not describe if or
how applications may advance features of DIGEST-MD5, such
as integrity protection and confidentiality protection.
The draft should explicitly note that these features are not
covered under this specification.

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Thu, 18 Nov 1999 17:31:14 -0800

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: Thursday, November 18, 1999 3:45 PM
> 

That's because there isn't one. It won't work with one. The form of user
name in Digest is determined by a system's implementation of Digest, not by
the application protocols that use it. The Digest user/password data base is
intended to be cross-application and system wide, even organization wide, so
that users don't have to remember different passwords for every service or
server. If ACAP, IMAP, POP3 and other protocols that use SASL mechanisms
such as Digest and use the same implementation on a system all tried to
mandate their own special forms for user names, like you're trying to have
LDAP do, there would be conflict and chaos.

> covered under this specification.

It is not necessary for an application protocol to specify how to use them;
the Digest spec says how they are to be requested and used.

I'll repeat -- the AuthMeth draft improperly (IMO) mandates layering
violations.

Paul

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 18 Nov 1999 19:00:34 -0800

I put forth that AuthMeth should be returned to the
WG until such time that it details a mechanism to
securely (no clear text password exchange) authenticate
clients desiring to use traditional LDAP DN based
authorization identities over a insecure transport
protocol (ie: TCP).

I recommend that the new bind method (non-SASL) be
drafted which adapts the algorithm suggested DIGEST-MD5
to support LDAP DN authorization identities.

At 05:31 PM 11/18/99 -0800, Paul Leach (Exchange) wrote:
>That's because there isn't one. It won't work with one.

>The form of user

I am attempting to make two independent points:

	1) AuthMeth, as defined, does not provide a secure
	bind method/mechanism for use with traditional DN based
	authorization identities.  It should.

	2) SASL does not care how the authorization identity is
	encapsulated within application protocol.  Encapulating
	the authorization identity ("kdz") in an AuthzId/uAuthzId
	("u: kdz") offers no benefit over encapsulating it in a
	DN ("uAuthzId=kdz").  However, the AuthMeth introduces a
	second on-the-wire representation and this will have a
	significant impact upon the LDAP information model.
	It should not.

>I'll repeat -- the AuthMeth draft improperly (IMO) mandates layering

I concur.  I believe we should resolve these layering issues
as well.

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Thu, 18 Nov 1999 20:20:28 -0800

> Sent: Thursday, November 18, 1999 7:01 PM
> 

I strenuously object to any LDAP-specific authentication protocol being
required.

There are dozens of application protocols -- if they all took this approach,
it will be in practice impossible to get all of their specific
authentication mechanisms correct.

The correct approach to security is to put all your eggs in one basket (or
at worst a few baskets) and then guard the baskets very carefully.

Paul

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 18 Nov 1999 21:10:00 -0800

At 08:20 PM 11/18/99 -0800, Paul Leach (Exchange) wrote: 
> I strenuously object to any LDAP-specific authentication protocol being required. 

Well, LDAP already specifies LDAP-specific authentication methods.
Though SASL is nice and wonderful, it's not a cure all.  Neither
is traditional LDAP authentication.  Neither is PKI.

LDAP is flexible enough to support all these approaches and more.
It's our responsibility to provide this flexibility in a secure
manner.

I believe that we must specify a LDAP secure bind method
for use with LDAP DN authorization identities as LDAP DN
based authentication is an integral part of LDAP.

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Fri, 19 Nov 1999 19:02:07 -0800

> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: Friday, November 19, 1999 6:17 PM
> To: Mark Wahl

> 
> Lastly, the DIGEST-MD5 mechanism described by AuthMeth does
> not work for DN-based authorization identities.  A canonical
> utf8 representation of DNs is necessary.

I don't think so. From the Digest-MD5 draft:

2.1.2.1	Response-value
The definition of "response-value" above indicates the encoding for its
value -- 32 lower case hex characters. The following definitions show how
the value is computed.
   response-value  = 
      HEX( KD ( HEX(H(A1)),
              { nonce-value, ":" nc-value, ":", 
                cnonce-value, ":", qop-value, ":", HEX(H(A2)) }))
 
If authzid is specified, then A1 is

   A1 = { H( { username-value, ":", realm-value, ":", passwd } ), 
        ":", nonce-value, ":", cnonce-value, ":", authzid-value }

Hence, all that is necessary is that the server use exactly the
authzid-value that the client used to compute A1 -- it does not need to be
canonicalized.

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Fri, 19 Nov 1999 19:19:37 -0800

> Cc: [email-masked]
> Subject: Re: LDAPDN and AuthMeth/DIGEST-MD5
> 
> 
> > let me see if I can summarize each person's position
> 
> My position is that users should be able to authenticate securely
> regardless of whether they provide a DN or non-DN authorization
> identity to the client.

First, authorization identities have nothing to do with authentication and
hence nothing to do with whether a user can authenticate securely.

Second, when using SASL, whether or not a particular form of authzid is
supported is up to the implementation of SASL mechanism, not LDAP. I believe
that section 11 of the AuthMeth draft is ambiguous -- but my interpretation
is that it defines how authzid works for non-SASL mechanisms (builtin LDAP
methods and EXTERNAL).

Finally, support for authzid is not required to be SASL compliant or
Digest-MD5 compliant.

> 
> I believe non-DN authorization identities should be encapulated
> within an LDAPDN so as to avoid introduction of a second on-the-wire
> representation of authorization identities.

For non-SASL mechanisms, I have no objection to this. I agree that u: or dn:
is just a different syntax, and your proposed syntax works just fine.

> 
> I believe that the server, upon successful authentication, SHOULD
> determine DN representing the user which is usable as the
> creatorsname, modifiersname, ACL subjectDN, etc..  This DN may
> or may not be the same DN provided by the client.

I think this conflicts with 2251, which says that those attributes are
optional.
If an implementation supports them, then it must map the user identity to a
DN, because they are DN valued attributes.
If an implementation does not support them, then the SHOULD is irrelevant.

Paul

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 21 Nov 1999 04:48:12 -0800

>authzid-value that the client used to compute A1

Which means that the server cannot precomute and store A1,
it must store the clear text password.  If it stores the
clear text password and the storage is cracked, the real
clear text password is exposed.

>it does not need to be canonicalized.

In needs to be canonicalized to allow servers to avoid
non clear text storage.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 21 Nov 1999 05:26:47 -0800

>hence nothing to do with whether a user can authenticate securely.

I will reword in an attempt to clarify my position:

My position is that users should be able to authenticate securely
regardless of whether they provide a DN or non-DN identity to
the client.

>I think this conflicts with 2251, which says that those attributes are

I do not believe my suggestion mandates that an implementation
provide a mapping NOR use it.  However, I do believe that since
RFC2251 says implementations SHOULD provide creatorsname and
modifiersname that AuthMeth should, when introducing non LDAP DN
authorization identities, state that implementations are allowed
to provide and use such a mapping to fulfill RFC2251 SHOULDs.

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Sun, 21 Nov 1999 17:53:55 -0800

> Sent: Sunday, November 21, 1999 4:48 AM

> it must store the clear text password.

Regardless of authzid, it can't precompute A1 because the computation
contains per-connection nonces.

> If it stores the

No. It can store
	H( { username-value, ":", realm-value, ":", passwd } 
which is what was intended to be precomputed, not A1.

> In needs to be canonicalized to allow servers to avoid

As shown above, that's not correct.

Paul

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 21 Nov 1999 18:40:23 -0800

My terminology was off and I confused A1 with the stored
hash.  I'll try to clarify my comments.

> which is what was intended to be precomputed, not A1. 

If the user provided identity (username-value) is an
LDAP DN, this cannot be precomputed unless both client
and server agree on a canonical string encoding for
DNs.  Without such an agreement, the password would
have to be stored in clear text.

From previous discussions, you noted that use of LDAPDN
format user identities was inappropriate for SASL based
authentication.  This may be true.  However, it does
leave AuthMeth without providing a secure mechanism for
authenticating users who provide LDAPDN identities.  Such
a mechanism is needed and, IMO, AuthMeth should not be
progressed without such a mechanism.

	Kurt

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Sun, 21 Nov 1999 21:09:49 -0800

> Sent: Sunday, November 21, 1999 6:40 PM
> To: Paul Leach (Exchange)
> Subject: RE: LDAPDN and AuthMeth/DIGEST-MD5
> 
> 

Now you're on solid ground. Yes, both client and server have to agree on the
format of username-value.
It's not quite true that there has to be a cononical form. For example, as
long as the user uses the same form consistently, including when giving
their username to the server when setting/changing their password, then no
canonical form is needed.

> authentication.

That's not quite what I said. One could certainly implement a Digest-SASL
mechanism that has LDAPDNs as the username. What I said was that it is
inappropriate for the LDAP protocol spec to mandate that such an
implementation be used, since SASL mechanisms are application protocol
independent. (It is equally inappropriate for POP3, IMAP4, ACAP, to mandate
that user names in the authentication mechanisms they use be e-mail
addresses.) In a system where the user name was an LDAPDN for all purposes
-- mail, web access, file access, directory access, etc. -- then use of an
LDAPDN as the user name is fine.

  This may be true.  However, it does
> authenticating users who provide LDAPDN identities.

Not true. If the username for the system is an LDAPDN, then one can do it.
Otherwise, not.

What you are trying to do is force all systems that run an LDAP server to
have the form of their username be an LDAPDN. I don't think _that_ is
appropriate.

Paul

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 21 Nov 1999 22:30:55 -0800

At 09:09 PM 11/21/99 -0800, Paul Leach (Exchange) wrote: 
> What you are trying to do is force all systems that run an LDAP server to have
> the form of their username be an LDAPDN.

No.  I am trying to ensure we provide secure authentication
and authorization services for identities of both DN and
non-DN forms.

Please note that my suggestion not to introduce a second on-the-wire
format for authorization identities IS NOT a call to eliminate user
(or application) specified non-DN identities.  It's a call to not
unnecessarily complicate the protocol and information model.

> Yes, both client and server have to agree on the format of username-value.
> It's not quite true that there has to be a cononical form.  For example,
> as long as the user uses the same form consistently, including when
> giving their username to the server when setting/changing their password,
> then no canonical form is needed.

It would be quite problematic to rely on users consistently entering
their DN... and different clients could rewrite them differently...
and admins could generate them using external tools.  A simple
specification of a canonical string representation of a DN would
eliminate these problems.

> Not true. If the username for the system is an LDAPDN, then one can do it.

Great.  All we then need is to include in AuthMeth a specification
for generating canonical LDAPDN string encoding of the user
specified DN.  This scheme should be mandatory for all clients
and servers supporting LDAPDN based authentication and
authorization.