Re: more comments on authmeth-01 draft

[Chris Newman <Chris.Newman@innosoft.com>]

On Wed, 25 Mar 1998, RL Bob Morgan wrote:
> (2)  Big nasty question: Do we really think that CRAM-MD5 is fully
> defined as a SASL authentication mechanism by RFC 2195, a document
> that does not even mention SASL?  Further, if the application of
> CRAM-MD5 to LDAPv3 needs definition, this definition should IMHO be in
> a separate doc, not in an applicability statement such as this one.

CRAM-MD5 is fine as a SASL mechanism.  In fact, sufficient
interoperability of CRAM-MD5 in IMAP has been demonstrated that it is
ready to move to draft status as soon as SASL moves forward.  The fact
that it lacks an authorization identity is unfortunate, but justifiable
given CRAM-MD5's simplicity.  I think that problem (and others) can be
addressed by SCRAM-MD5 (draft-newman-auth-scram-03.txt) which is backwards
compatible with CRAM-MD5 and adds an authorization identity, server
authentication and optional integrity protection.  Review of that
mechanism would be welcome -- I've put a lot of work into it. 

> (3)  Another big nasty one:  The simple bind mechanism is inadequate
> in that it does not support a separate authentication identity (as
> SASL mechanisms are supposed to) and requires the client identity to
> be a DN.  It would be far preferable to specify the use of the SASL
> PLAIN mechanism for this purpose.  I know that SASL PLAIN is still in
> draft and so this introduces yet another dependency; perhaps this
> should motivate getting SASL PLAIN done.

Simple bind exists for backwards compatibility.  SASL PLAIN should only be
used when the authentication and authorization identities are different.

> Perhaps the concern is that if we take server impersonation and
> data-in-transit modification as serious threats, we would come to the
> conclusion that a mechanism like CRAM-MD5 login is useless since it
> doesn't provide protection against these threats.  Obviously this is
> not the right conclusion, since CRAM-MD5 does add value over
> passwords-in-the-clear.  The point IMHO is that server impersonation
> and data-in-transit modification are "active intermediary" attacks,
> and we think that such attacks are harder to mount and less prevalent
> in today's Internet than passive eavesdropping attacks (or active
> client attacks, for that matter).  But as the doc already says, this
> is the Internet we're talking about, and they do exist.

I will note that SCRAM-MD5 provides a lightweight method to get protection
from active intermediary attacks which is backwards compatible with
CRAM-MD5. The issue today is that while purchasing customers are becoming
concerned with exposed passwords they are largely not concerned with
active network attacks yet.  Active network attacks have been documented
and will become a more serious problem, but I think it suffices that we
have specs in progress for both lightweight (SCRAM-MD5) and heavyweight
(TLS) mechanisms to protect against them.

> The above list of protections doesn't include SASL-oriented
> protections.  It should be:
> 
>   (1)  Client authentication by means of a SASL mechanism or
>   the TLS credentials exchange mechanism,
> 
>   (2)  (as is)
> 
>   (3)  Integrity and confidentiality protection by means of a SASL
>   mechanism or the TLS protocol, using a bulk encryption algorithm of
>   appropriate strength,
> 
>   (4)  (as is)
> 
>   (5)  Server authentication by means of a SASL mechanism or the TLS
>   protocol.

I concur with these suggestions.

		- Chris