Subject: I-D ACTION:draft-ietf-sasl-crammd5-to-historic-00.txt

From: [email-masked]
Date: Mon, 24 Nov 2008 14:30:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.

	Title		: CRAM-MD5 to Historic
	Author(s)	: K. Zeilenga
	Filename	: draft-ietf-sasl-crammd5-to-historic-00.txt
	Pages		: 6
	Date		: 2008-11-24
	
This document recommends the retirement of the CRAM-MD5 authentication
  mechanism, and discusses the reasons for doing so.  This document
  recommends RFC 2195 and its predecessor, RFC 2095, be moved to
  Historic status.

  [[Note to RFC Editor: please publish at same time that [SCRAM] is
  published.]]

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-crammd5-to-historic-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: John C Klensin <[email-masked]>
Date: Tue, 25 Nov 2008 11:06:28 -0500

--On Monday, 24 November, 2008 14:30 -0800
[email-masked] wrote:

> A New Internet-Draft is available from the on-line
> Internet-Drafts  directories.
> This draft is a work item of the Simple Authentication and
> Security Layer Working Group of the IETF.
> 
> This document recommends the retirement of the CRAM-MD5
> authentication   mechanism, and discusses the reasons for
> doing so.  This document   recommends RFC 2195 and its
> predecessor, RFC 2095, be moved to   Historic status.

Folks,

While I have no particular attachment to CRAM-MD5 -- Paul,
Randy, and I created it as a service to the community -- I
suggest that you consider this active _very_ carefully.   In
particular (and playing the role of devil's advocate much more
than that of author):

* CRAM-MD5 was designed at a time when the IETF was campaigning
against clear-text passwords on the wire, as a "better than
nothing" alternative.  While its perceived strength has weakened
over the years, it may still have some value in that area.
More important, it did not require cryptography, which was
perceived as an important issue for places and circumstances
where cryptography was prohibited or significantly restricted.

* Empirically, CRAM-MD5 is quite widely deployed and
interoperable.  The claims in this document about the weakness
of the definition notwithstanding, the evidence on the ground is
that people have been able to make it work (possibly by
aggressive application of the robustness principle).  Replacing
it on a flag-day basis ("move this to Historic when SCRAM is
published") with a protocol that has not been similarly tested
and deployed seems to me to be unwise.

* The document appears to suggest that clear-text passwords over
TLS are more desirable than CRAM-MD5.   In a world in which

	 (i) all certificates were anchored in well-established
	and trustworthy CAs and based on more than "responds to
	email" or "has domain" and
	
	 (ii) an in-depth analysis had been done on the ability
	to use partially-known-plaintext attacks (based on the
	very predictable nature of the SMTP, POP, IMAP, etc.,
	session-initiation dialogues) on TLS and a conclusion of
	"no problems" reached

I would certainly agree with that conclusion about clear-text
over TLS if it were substantiated.  However, in a world in which
typical certs for mail servers seem to be either self-signed (or
certified on the basis of email address dialogues or domain name
ownership), in which attacks on the DNS are well-known and the
proper response to "Bind 8 is dead" may be "before or after Bind
4?", methods based on challenge-response may have one advantage
that the I-D does not discuss, namely being independent of the
certificate and DNS situation and relationships.  

* The previous effort to replace CRAM-MD5 with something else
involved an effort to deprecate it in favor of Digest-MD5 which
was argued to be much more secure, etc., etc.   That effort
fizzled out when it became clear that Digest-MD5 had its own set
of problems and that the marginal security benefits were
probably not worth the trouble.  I have not studied SCRAM, but,
absent an RFC-published specification and several years of
experience, I don't have significant reason to believe that, in
practice, it will offer much more marginal benefit over CRAM-MD5
than Digest-MD5 turned out to.   Trying to replace one mechanism
with another involves significant costs, especially to
interoperability as some systems select one of the methods and
others select other ones, so the advantages had better be
significant.

Given all of that, I wonder if denouncing CRAM-MD5 as strongly
as this document seems to is really appropriate.  Would it not
be a lot more sensible and realistic to:

	(i) Publish an updated version of 2195 that reflects at
	more length on the security issues and warnings about
	them?  I note that, given the requirement for two
	interoperable implementations, this document could be
	published at Draft Standard and that there is _no_ bar
	to doing so under the procedures specified in RFC 2026.
	
	(ii) Publish SCRAM and see if it gets any traction in
	practice.
	
	(iii) When, and only if, SCRAM actually does get
	significant deployment in practice, move CRAM-MD5 to
	Historic.

regards,
    john

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 25 Nov 2008 23:43:19 +0100

John C Klensin <[email-masked]> writes:

> suggest that you consider this active _very_ carefully.

The WG has discussed this particular issue for several IETF meetings
now.  It seems difficult to come to consensus around the issue.

> 	to doing so under the procedures specified in RFC 2026.

I would support this path, and given the deployment believe it makes
some sense to do this, but others (Sam?) have said they would not
support a backwards compatible CRAM-MD5 on the standards track.

> 	(ii) Publish SCRAM and see if it gets any traction in

+1.

/Simon

---

From: Paul Smith <[email-masked]>
Date: Wed, 26 Nov 2008 16:30:12 +0000

> certificate and DNS situation and relationships.  
I think this is an important issue. So, I agree with John's 'plan of
attack' here.

CRAM-MD5 makes it a lot harder for MITM attacks than plain text over an
unverified TLS link does. While plain text over TLS does stop attacks
from 'eavesdroppers' it does nothing for MITM attacks in most cases.

I think one thing that some people seem to forget is that most people
who use email have no clue what TLS is, or how certificates work. For
plain text over TLS to be more secure (IMV) than CRAM-MD5, average users
would have to check mail server certificates, which they won't do.

- I can see the point in the draft about an a priori agreement about
character set, but is that really a big deal? 'sequence of ASCII
printable characters encoded in an octet with zero parity, with no
normalization' pretty much covers every case of passwords I've ever seen
anyone use - even in non-latin character set countries.

- No, CRAM-MD5 doesn't protect the user ID from eavesdroppers, but plain
text over TLS protects neither the user ID nor the password from a MITM
attack if the certificate isn't verified. CRAM-MD5 does protect the
password from both eavesdroppers and MITM attacks. Given that a large
number of mail providers use easily guessable user IDs (for ease of use
by users), I'm not sure how significant this 'weakness' in CRAM-MD5 is
*in real life*.

Now, in *some cases* I can see that plain text/TLS is better than
CRAM-MD5 - where the mail system is managed by competent techies, and
where email software is installed for users by those techies (so
certificates can be configured properly), but in the vast majority of
cases out there, I think the choice would be CRAM-MD5, plain text over
an unencrypted session, or plain text over a dubiously encrypted session
- which is better?

CRAM-MD5 has a large deployed server base out there. I don't think PLAIN
over TLS is a secure alternative, and SCRAM is still 'work in progress'
(and I remember the issues that we STILL have because we deployed SMTP
'AUTH' support before that was finalised ('AUTH=CRAM-MD5' vs 'AUTH
CRAM-MD5' anyone?)).

-- 
Paul Smith

VPOP3 - POP3/SMTP/IMAP4/Webmail Email server for Windows

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 26 Nov 2008 17:52:44 +0100

> from 'eavesdroppers' it does nothing for MITM attacks in most cases.

I hesitated to correct John about this, but if similar claims are
repeated, I think we need to establish that CRAM-MD5 does not help
against an MITM.

CRAM-MD5 does not provide session security.  Thus an MITM can simply
wait after the correct user has authenticated, and then hijack the
session.  The attacker then has full access to the users' account.

The conclusion is that CRAM-MD5 needs TLS to protect against MITM's.

I believe TLS + CRAM-MD5 is better than TLS + PLAIN.  With TLS +
CRAM-MD5, the MITM at least does not learn the long-term secret to set
up new sessions.

/Simon

---

From: John C Klensin <[email-masked]>
Date: Wed, 26 Nov 2008 12:35:45 -0500

--On Wednesday, 26 November, 2008 17:52 +0100 Simon Josefsson
<[email-masked]> wrote:

>> CRAM-MD5 makes it a lot harder for MITM attacks than plain
>> text over an unverified TLS link does. While plain text over
>> TLS does stop attacks from 'eavesdroppers' it does nothing
>> for MITM attacks in most cases.
> 
> I hesitated to correct John about this, but if similar claims
> are repeated, I think we need to establish that CRAM-MD5 does
> not help against an MITM.

You can correct me any time you like, especially when I use
imprecise language.

To oversimplify somewhat, there are several possible attacks
that some people might describe in MITM terms.   One involves
impersonating the client and its credentials.   Without getting
into a debate about which Challenge-Response (CR) mechanism is
better than others, CR provides some protection against that
type of attach.  Another involves impersonating the server to
the client.  CR provides some protection there too.  And, in
both cases, it provides that protection even without
cryptography in general and session privacy protection in
particular.

Because session or link encryption (or the equivalent) are not
intrinsic to any CR method, they provide no protection against
session interception, especially of the passive data recording
(e.g., wiretapping) variety.  If the MITM attacker intends to do
anything more active, periodically reissuing the challenge can
make her life considerably more difficult although certainly not
impossible.

> CRAM-MD5 does not provide session security.  Thus an MITM can
> simply wait after the correct user has authenticated, and then
> hijack the session.  The attacker then has full access to the
> users' account.

As long as the MITM has the ability to do that, certainly yes.
To the extent to which the tools available to an MITM involve
hijacking by diversion of sessions at setup time, no.  And,
again depending on repeated challenge patterns and the nature of
the underlying application protocol, the MITM may be able to
monitor the transaction stream but may have only limited ability
to issue its own commands to the server and account.     Let's
remember that CR mechanisms, especially when used alone, have
never been legitimately considered as complete security
solutions, only as possibly-decent authentication ones when the
alternative is "nothing".  Conversely, let's not trick ourselves
into believing that all MITM attackers have access to seize any
connection, control the network, and fully operate any link they
can gain access to.

> The conclusion is that CRAM-MD5 needs TLS to protect against

It needs properly authenticated TLS or some other session or
link encryption mechanism.   Without the "properly
authenticated" part, the MITM is free to divert the connection
and simply simulate the server.   And, of course, DNS attacks to
arrange such diversions are the easiest of MITM attacks to
arrange.  

> I believe TLS + CRAM-MD5 is better than TLS + PLAIN.  With TLS
> + CRAM-MD5, the MITM at least does not learn the long-term
> secret to set up new sessions.

And, with properly authenticated TLS (or
equally-well-authenticated IPSEC), the risks are further reduced
because one then has host-to-host protection of the data stream
and user-to-account authentication to use as the basis for
authorization.   Of course, a symmetric CR model would be even
better, if one could get it deployed.

Once again, I'm not trying to defend CRAM-MD5, or any other CR
mechanism, as either session security or as a really strong
authentication method.  I do contend that, as an authentication
mechanism, it is significantly better than nothing.  I also
believe that the evidence so far about the security differences
among CR mechanisms is that we need a lot more analysis of
operational risks  --not just analysis of how one technique
might be slightly better than another-- to justify trying to
discard (or recommend that people stop using) one method that is
widely deployed in favor of one that is still untested in
practice.

I also recommend against getting two hung up on CR+TLS as a
requirement, not because it isn't a good idea, but because we
have a bunch of other link and session encryption methods
available to us that may provide effective session security at
least as good as TLS (especially weakly-authenticated TLS), and
because, as far as I know, we have never demonstrated that
double encryption is desirable in the general case.  Telling
folks that CR doesn't really offer string protection without
pre-established session encryption is one thing; insisting on
TLS is something else entirely.

    john