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