RE: Authentication Methods for LDAP - last call

[Paul Leach <paulle@microsoft.com>]

> -----Original Message-----
> From: RL Bob Morgan [mailto:Bob.Morgan@Stanford.EDU]
> Sent: Thursday, August 13, 1998 4:34 PM
>
>  CRAM-MD5 is registered with the IANA as a SASL
> mechanism, as specified in RFC 2222.

I just registered Digest's SASL mechanism name.

<snip>

> 
> I don't think the same can be said of RFC 2069.  Your 
> proposed text is as
> far as I can see an interpretation of how to apply the same 
> basic ideas to
> a SASL security mechanism, but is it complete and definitive? 
>  Should the
> "stale" and "algorithm" fields be dropped, for example?

One could try to optimize RFC 2069 for use in LDAP, but I believe it
adequately specifies what to do about (e.g.) "stale" and "algorithm".

I agree it would be nice to have a spec for Digest as a SASL mechanism. I
also think it would be much better if section 8.1 said "here's how to use a
SASL mechanism in LDAP"; it shouldn't need to mention CRAM-MD5 at all if it
is well enough specified as a SASL mechanism. Of course, as you noted, there
is no spec that says "here's how to use CRAM-MD5 as a SASL mechanism",
either, and being more explicit there couldn't hurt.

  Are 
> there other
> things lost or added in the translation?

The onus of proof is on he who asserts the positive. What is lost?

  Do any of these affect the
> security properties of the scheme?

Ditto.

  Should any of the other 
> contributors
> to RFC 2069 and its successor docs be consulted on these issues?

Why? You're trying to create a smokescreen, it seems to me, with these three
items. 

> 
> Your proposed text refers to 
> draft-ietf-http-authentication-01.txt (I see
> -02 in the I-D archive).  I don't know the status on this doc 
> but it's too
> late IMHO to be basing the LDAP authmeth doc on another doc 
> that's still a draft.

Well, here's the status.
They are updates to RFC 2069, which is already Proposed Standard. -02 wasn't
submitted at the time  I wrote the note, so it couldn't be cited. It will be
WG last called at Chicago -- hence Digest is probably _farther_ along than
the LDAP Auth spec, which has never been at Proposed.

> 
> It's the time that it would take to clean up all these loose ends, and
> make Digest a fully-specified SASL mechanism, that has people 
> concerned
> (including me).  It might not be a year, but the authmeth is 
> long overdue
> already, and is holding up progress on all other LDAP docs.

What about all the time and money time vendors will have to waste
implementing a bogus mandatory-to-implement auth protocol so they can
truthfully claim compliance with an IETF standard? Is that a consideration?

Make Kerberos the MTI. Make TLS the MTI. Make something that is _worth_
implementing and that everyone is _going_ to implement the MTI.

Paul