RE: Simple+TLS as mandatory-to-implement (RE: Issues with current authmeth draft.)

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

Hi Mark,

I thought Kurt made a specific objection to LDAP-DN, which is that it can have different values which match. I assume the protocol exchange is

C: (nothing)
S: challenge
C: hash(hash(username+realm+password)+challenge), username

If this is the case, the server will have to use the client-supplied DN to verify the response. One would not normally depend on the client normalising the DN (if this could be done unambiguously), so the server is prevented from storing the prehash, that is, passwords would have to be stored in the clear.

Ron

----Original Message-----
From: Mark Ennis [mailto:mark.ennis@adacel.com]
Sent: Tuesday, 13 May 2003 16:36
To: Kurt D. Zeilenga
Cc: Ramsay, Ron; ietf-ldapbis@OpenLDAP.org
Subject: Re: Simple+TLS as mandatory-to-implement (RE: Issues with
current authmeth draft.)


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.

Kurt D. Zeilenga wrote:
> 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 
> 
> 
>