Subject: RE: Issues with current authmeth draft.

From: "Ramsay, Ron" <[email-masked]>
Date: Tue, 13 May 2003 12:25:33 +1000

I don't believe you can mandate simple/TLS! At the time RFC 2829 was debated, a large number on the WG wanted this. They did not get their way because of the complexity of the solution. It was argued that a password-based method would be better. I think they believed it would still be DN/password, though. 

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Tuesday, 13 May 2003 10:01
To: Mark Ennis
Cc: [email-masked]
Subject: Re: Issues with current authmeth draft.

At 04:24 PM 5/12/2003, Mark Ennis wrote:
>All the introductory text in RFC2829 and [authmeth] indicate that the reason for introducing and, in [authmeth] case, requiring DIGEST-MD5 is for security considerations relating to protecting passwords from eavesdropping. The only mention of non-LDAPDN authentication identities in the early parts of these documents are in reference to using these non-LDAPDN identities as authorization identities for backward compatibility with non-LDAP authentication mechanisms.

Since RFC 2829 is a largely a SASL profile, I wouldn't expect it
to discuss LDAPDNs except in contexts where SASL allows application
profiles to use application specific forms of identities.

However, RFC 2829 is fairly clear when it states (very early):
   An authentication identity is the name presented in a credential.

   There are many forms of authentication credentials -- the form used
   depends upon the particular authentication mechanism negotiated by
   the parties.  For example: X.509 certificates, Kerberos tickets,     
   simple identity and password pairs.  Note that an authentication     
   mechanism may constrain the form of authentication identities used   
   with it.

In DIGEST-MD5 clearly constrains the form of the authentication
identity to a simple identity string, a user name.

>You are suggesting DIGEST-MD5 and other SASL mechanisms were introduced for other than reasons related to security considerations and yet all the text in the documents introducing these mechanisms into LDAP indicate the reasons are security related and for backwards-compatibility only.

I am suggesting that RFC 2829 recommends implementation of
simple bind over TLS to support DN/password credentials.
But it requires implementation of DIGEST-MD5 to support
username/password credentials.

However, regardless of this, it should be clear that stuffing
LDAPDNs into usernames is not a path to interoperability nor
security.  Matching issues alone should be enough to kill that
idea.  We cannot morph DIGEST-MD5 into something its not, that
breaks mechanism commonality between application protocols.
We needed to use each mechanism in a manner consistent with
its specification.

Going forward, it would be much better to clarify that simple
+TLS is to be used for DN/password credentials and DIGEST-MD5
(or PLAIN+TLS) be used for username/password credentials.

I note that due to the specification and interoperability problems
with DIGEST-MD5 (not just with LDAP), I would not be opposed to
changing the mandatory-to-implement authentication mechanism
from DIGEST-MD5 to simple+TLS.

Kurt

PS: I was once suggested in an I-D how one could stuff DNs
into DIGEST-MD5 credentials, it got no where.  See LDAPEXT
archives.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 12 May 2003 20:14:49 -0700

At 07:25 PM 5/12/2003, Ramsay, Ron wrote:
>I don't believe you can mandate simple/TLS!

I certainly cannot mandate it.  But the IETF certainly can. 

>At the time RFC 2829 was debated, a large number on the WG wanted this. They did not get their way because of the complexity of the solution. It was argued that a password-based method would be better. I think they believed it would still be DN/password, though. 

I think clear from this discussion that some folks didn't
get what they thought they were getting.

If one takes the view that RFC 2829 intended DNs in DIGEST-MD5
user names, than RFC 2829 is serious broken.  DNs in DIGEST-MD5
is not workable.  So, it would be quite reasonable to open a
discussion on choosing a different mandatory-to-implement strong
authentication mechanism.

If one takes the view that RFC 2829 intended user name in
DIGEST-MD5 user names, then RFC 2829 just needs some clarification.
However, since significant specification and interoperability issues
exist with DIGEST-MD5, it would be reasonable here to open a
discussion on choosing a different mandatory-to-implement strong
authentication method.

At this point, I (as co-chair), consider the issue open.

Kurt

---

From: Mark Ennis <[email-masked]>
Date: Tue, 13 May 2003 16:35:49 +1000

Kurt,

Having reviewed RFC2222 and RFC2831, I do not accept your assertion that 
the username field in the SASL DIGEST-MD5 protocol messages is 
constrained to a simple representation as might be found in a Unix or MS 
Windows style username/password authentication mechanism and excludes 
the use of a LDAPDN.

RFC2222 only appears to directly address the identity in the 
authentication credentials in *3. Introduction and Overview*, paragraph 7:
    The transmitted authorization identity may be different than the
    identity in the client's authentication credentials.  This permits
    agents such as proxy servers to authenticate using their own
    credentials, yet request the access privileges of the identity for
    which they are proxying.  With any mechanism, transmitting an
    authorization identity of the empty string directs the server to
    derive an authorization identity from the client's authentication
    credentials.

The example regarding proxy servers actually *implies* that the 
difference permitted between authentication and authorization identity 
is a difference in identity asserted rather than a difference in form of 
the identity.

The only support for a difference in form of authentication and 
authorization identities is *implied* by the section on profiling 
requirements which requires a SASL profile to specify how the 
authorization identity should be interpreted. This section in no way 
prohibits a profile from also optionally providing a specification on 
how authentication credentials or authentication identity may be 
interpreted.

A review of draft-ietf-sasl-rfc2831bis-00.txt does indicate a problem 
which is the requirement to normalize the username-val content into 
Unicode Normalization Form KC 
[http://www.unicode.org/unicode/reports/tr15/]. Requiring the content of 
the username-val to be normalized in this way would certainly 
potentially change the semantics of a string which happened to be a 
LDAPDN. However, the purpose of this normalization is to provide 
consistent matching (in this case making sure that different 
implementations will generate the same digest). This could equally well 
be accomplished by moving the requirement to normalize the values to the 
point at which the values are used to generate the digest instead of 
requiring them to be normalized in the protocol message. Having not been 
a subscriber to the SASL mailing lists, I do not claim to know if this 
alternative approach has been considered and discarded for some reason, 
but I would certainly be interested in a reference to this discussion if 
it occurred.

I get the feeling that you view the SASL authentication as a way of 
having a single authentication server for a number of different 
applications of which LDAP is but one. I can see this view has benefits, 
however, I do not think RFC2222 in any way requires this model and I do 
not see that accepting the use of LDAPDN as a possible value to include 
in the username-val field in the SASL DIGEST-MD5 protocol necessarily 
breaks this model, provided the LDAP specification [authmeth] permits 
other forms of the username also.

Should the general opinion support the view that LDAPDN and DIGEST-MD5 
are absolutely incompatible, then I would propose defining a variation 
on DIGEST-MD5 for LDAP, possibly using an algorithm value other than 
"md5-sess", e.g. "md5-ldap", which uses the authzid syntax to encode the 
  username-val and introduces the Unicode Normalization Form KC at the 
point where the digests are being generated rather than where 
draft-ietf-sasl-rfc2831bis-00.txt is doing this.

- Mark.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 13 May 2003 08:31:26 -0700

At 11:35 PM 5/12/2003, Mark Ennis wrote:
>Having reviewed RFC2222 and RFC2831, I do not accept your assertion that the username field in the SASL DIGEST-MD5 protocol messages is constrained to a simple representation as might be found in a Unix or MS Windows style username/password authentication mechanism and excludes the use of a LDAPDN.

Neither did they account for LDAPDNs being used.  I believe
subsequent revision of RFC 2831 will make it very clear that
the DIGEST-MD5 is a user name.  To get an idea of where they
are going, you might read draft-ietf-sasl-saslprep.

Anyways, the fact is that many LDAP implementations support
DIGEST-MD5 using simple user names and passwords consistently
with the current specifications and revisions being discussed
in the SASL WG.  So changing the specifications in ways that
would break these existing implementations can only be done
with very good reasons.

Now, you argue that you have existing implementations which
do it a different way and specifications should be changed
to accommodate you.  The reasons you have stated so far are,
simply, not good enough.

Applications which have DN/password credentials should just
use simple+TLS as discussed in RFC 2829.

Also, I note that if you have comment regarding the revision
of RFC 2222, RFC 2831, or any other SASL framework/mechanism
technical specification, I suggest you take them to the SASL
WG.  They own the SASL revision work.

Kurt

---

From: Mark Ennis <[email-masked]>
Date: Wed, 14 May 2003 14:43:59 +1000

Kurt,

It is my opinion that RFC2829 intended to continue to use the LDAPDN as 
the primary authentication identity, including when using SASL 
DIGEST-MD5 mechanism. I believe I am not alone in this interpretation of 
RFC2829 and this view seems to be supported by text in the current 
[authmeth] draft.

It is clear that you disagree with my view and that current development 
of the SASL specifications will move the SASL specifications in a 
direction which would not support my interpretation of RFC2829.

Both sides of the argument have been expressed in detail and there is no 
point in continuing the discussion.

My original concern that the [authmeth] draft does not sufficiently 
address the issue of authentication identity seems to have been 
adequately demonstrated.

With regards to an alternative mandatory-to-implement authentication 
mechanism which is more secure than using cleartext passwords, I would 
like to see one which allows for distinguished names as one form of the 
authentication identity, but would be reluctant to support mandatory 
implementation of startTLS extended operation to achieve this if it can 
be avoided.

- Mark.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 14 May 2003 06:53:29 -0700

At 09:43 PM 5/13/2003, Mark Ennis wrote:
>With regards to an alternative mandatory-to-implement authentication mechanism which is more secure than using cleartext passwords, I would like to see one which allows for distinguished names as one form of the authentication identity, but would be reluctant to support mandatory implementation of startTLS extended operation to achieve this if it can be avoided.

Does your desire to avoiding StartTLS outweigh your desire for
credentials with LDAPDNs?  Or does your desire for credentials
with LDAPDNs outweigh your desire to avoid StartTLS?

Kurt

---

From: Mark Ennis <[email-masked]>
Date: Thu, 15 May 2003 08:59:07 +1000

My preference is for a digest (or similar challenge/response) 
authentication mechanism which allows distinguished names as a form of 
the authentication identity.

- Mark.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 14 May 2003 16:54:33 -0700

At 03:59 PM 5/14/2003, Mark Ennis wrote:
>My preference is for a digest (or similar challenge/response) authentication mechanism which allows distinguished names as a form of the authentication identity.

Such a mechanism is not available to us.

Kurt

---

From: Mark Ennis <[email-masked]>
Date: Thu, 15 May 2003 10:17:11 +1000

We've already had this argument. It is up to the working group to decide 
this. I doubt anyone could claim consensus has been reached on this 
topic so far.

- Mark.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 14 May 2003 22:14:27 -0700

At 05:17 PM 5/14/2003, Mark Ennis wrote:
>We've already had this argument. It is up to the working group to decide this. I doubt anyone could claim consensus has been reached on this topic so far.

The argument we had regarding interpretation in this area
is moot at this point.

In a recent post you stated:
  Current development of the SASL specifications will move the
  SASL specifications in a direction which would not support
  my interpretation of RFC2829.

Exactly!  If the WG were to accept your interpretation, then the
chairs would be forced to declare LDAP's use of DIGEST-MD5 as
unworkable.  The WG would either have to revise RFC 2829 to be
consistent with the revised SASL specifications or choose
another available mechanism.

Now, if the WG accepted my interpretation, it could be argued
that DIGEST-MD5 as specification is workable but just needs
some clarification.  However, as there are some known RFC 2831
specification/interoperability issues, I feel it reasonable
for the WG to consider other available mechanisms.

So, you see, we don't need the WG to decide which interpretation
is correct, we need the WG to decide which of the available
mechanisms should now be the mandatory-to-implement mechanism.

So, what shall it be?

Kurt