Subject: Advancing CRAM-MD5 (was: Re: datatracker for 2821bis)

From: John C Klensin <[email-masked]>
Date: Wed, 04 Jun 2008 14:36:09 -0400

--On Wednesday, 04 June, 2008 17:45 +0200 Frank Ellermann
<[email-masked]> wrote:

>...
>> The IESG can ignore it, I suppose, but I don't see that as
>> setting any sort of precedent for the next case.
> 
> Agreed, but I'm still interested "how stuff works", in
> practice. Example, I submitted the CRAM-MD5 report because I
> want it to be promoted on standards track at an appropriate
> point in time.

But it won't happen because, despite its very wide deployment
and demonstrations of utility, the lead author* believes that it
has been made clear that

-- There is a sufficiently strong preference for
	SASL-based mechanisms over standalone things like RFC
	2195 that the odds of a 2195bis being advanced are
	nearly zero.
	
-- There are enough concerns over challenge-response
	mechanisms based on MD5 (or keyed MD5) and the belief
	that CRAM-MD5 requires storing clear-text
	passwords/secrets on the server that the Security Area
	is likely to block any attempt to advance CRAM-MD5.
	Neither disclaimers in a Security Considerations section
	nor "better than clear-text passwords" arguments are
	likely to do much good here.

I even agree with the first of these.  I have mixed feelings
about the second, especially when the claimed solution is
Digest-MD5 instead of keyed-MD5, but no energy for arguments
with people who see the operational environment issues
differently that I do and who are sure they are right.

So, if there were any real desire to advance CRAM-MD5, it would
need to come from someone else.  It is not clear that I'd even
participate.

    john

* Paul Krumviede passed away some years ago and I don't know how
to find Randy these days, so...

_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 4 Jun 2008 22:53:21 +0200

John C Klensin wrote:
 
 [One of the co-authors believed:]
> There is a sufficiently strong preference for SASL-based
> mechanisms over standalone things like RFC 2195 that the
> odds of a 2195bis being advanced are nearly zero.

The author of draft-ietf-sasl-crammd5 apparently did not
believe this, and CRAM-MD5 is a registered SASL mechanism,
working as expected.

> There are enough concerns over challenge-response 
> mechanisms based on MD5 (or keyed MD5)

There are also concerns about using SHA-1, nevertheless 
even NIST has no problems with using HMAC-SHA-1 after 2010.
There are also concerns about using STD 20, nevertheless
it is a full Internet standard, listed in STD 1.

> and the belief that CRAM-MD5 requires storing clear-text

They could have to justify their actions before the IAB if
they break BCP 9.  Two interoperable implementations, no
known errata after 11 years => mature specification, "DS"
is IMO no price in a security area RFC popularity contest.

> likely to do much good here.

Apart from arguably missing [[WP:NPOV]] to some degree the
security considerations in draft-ietf-sasl-crammd5 are IMO
acceptable and proposed by a SASL co-Chair.

> mixed feelings about the second, especially when the
> claimed solution is Digest-MD5 instead of keyed-MD5

That's old history, they now want to deprecate DIGEST-MD5,
because they figured out that it is far too complex, not
interoperable, incompatible with RFC 2617 md5-sess due to
an - at the time of the RFC 2831 publication - unreported
RFC 2617 erratum, and folks anyway only use a part of the
specification, not its integrity/confidentiality features.

I'd toss a coin to decide which WG is more charming, SASL
or USEFOR.  The crammd5 draft is soon five years old, and
at the moment expired.

> if there were any real desire to advance CRAM-MD5, it 
> would need to come from someone else.

Yes, we talked about it two years ago on the general list
as an interesting procedural "problem".  IMO an attempt to
force an AD to vote YES for something he dislikes makes no
sense, no matter what RFC 2026 says, so the point was moot
while Sam was the SASL AD.

 Frank

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 4 Jun 2008 17:24:20 -0500

Why isn't this thread cc'ed to the SASL WG?

Nico
--

---

From: Dave Cridland <[email-masked]>
Date: Thu, 05 Jun 2008 10:43:44 +0100

> Why isn't this thread cc'ed to the SASL WG?

Wouldn't the SASL WG want to recast CRAM-MD5 as a GS2 mechanism?

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Jun 2008 09:03:09 -0500

> Wouldn't the SASL WG want to recast CRAM-MD5 as a GS2 mechanism?

No.  We've come to the conclusion that where we want both, a SASL and a
GSS mech we should separate the GSS work and prioritize SASL.

Also, we've decided that we can make a pure SASL mechanism look like a
SASL/GS2 mechanism without doing the work of specifying a GSS mechanism
too.  (Which reminds me, I must go do that work for one proposal...)

Nico

---

From: John C Klensin <[email-masked]>
Date: Wed, 04 Jun 2008 17:58:49 -0400

> believe this, and CRAM-MD5 is a registered SASL mechanism,

Frank,

I assumed from your initial note that you were talking about
advancing RFC 2195.  If, instead, you are talking about
restarting
draft-ietf-sasl-crammd5 and moving it forward, I collaborated
with Lyndon in some very small ways on that and see no reason,
personally, why it should not be done, at least to Proposed and
Draft.  Further than that, we would have a small difficulty
(unless things change) because, as far as I know, the dominant
CRAM-MD5 implementations for IMAP, and maybe POP, are
2195-conforming rather than SASL conforming.   On the other
hand, getting a SASL-conforming standards-track RFC published
and out there might be a useful step in changing that.

Whether draft-ietf-sasl-crammd5 could be construed as a DS
update to RFC 2195 would also be a matter of interpretation.  My
personal view (which doesn't count for much) is that, while the
key CRAM-MD5 part is the same, the difference in startup
mechanisms, ports used, etc., would make it quite a stretch.

> it is a full Internet standard, listed in STD 1.

In a perfect world in which everything was consistent and
rational, you would certainly be correct.  In one in which the
real issue is what the IESG would approve --and in which, for
example and despite promises and criteria documents to the
contrary, IESG members feel free to register DISCUSS positions
and then decline to engage in discussion or respond to
explanations from editors-- the rules are whatever the IESG says
they are and precedents like the ones you cite don't count
unless the IESG says they do.

> is IMO no price in a security area RFC popularity contest.

I agree.  However, as a matter of personal preference, that
isn't a battle I feel like fighting, especially with an IESG
that interprets RFC 2026 (BCP 9) as being as, or more, concerned
with the form of interoperability reports as with whether things
interoperate.

> specification, not its integrity/confidentiality features.

You left out "doesn't provide enough extra security in practical
cases to be worth the trouble".

> while Sam was the SASL AD.

Now you are beginning to sound as cynical and pragmatic as I am
:-(

   john