[Date Prev][Date Next] [Chronological] [Thread] [Top]

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