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

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

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.

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