Subject: Re: Advancing CRAM-MD5

From: John C Klensin <[email-masked]>
Date: Wed, 04 Jun 2008 18:03:54 -0400

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

> 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.

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.

>> 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.

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.

>> 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.
> 
> 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.

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.

>...
>> 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.

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

>...
>> 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.

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

   john

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 5 Jun 2008 02:09:43 +0200

John C Klensin wrote:
 
> advancing RFC 2195.

Yes, I consider the crammd5 draft as 2195bis draft, apparently
you think it's different (?)

> the dominant CRAM-MD5 implementations for IMAP, and maybe POP,
> are 2195-conforming rather than SASL conforming.

Sure, but that affects only I18N of user names and passwords.
RFC 2195 doesn't say how to do this, the draft says SASLprep.
Not really incompatible, a working RFC 2195 ASCII user name 
and password will continue to work with the draft.  Anything
else wasn't explicitly specified.  

RFC 2195 is only six months older than RFC 2277, hopefully
implementors used UTF-8 for unspecified RFC 2195 extensions.

UTF-8 isn't the same as RFC 5198, let alone SASLprep, but it
might be good enough in practice.  I'd have no problem with
replacing SASLprep by RFC 5198, in the direction of "KISS".

> 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.

AFAIK there are no ports used in RFC 2195.  The crammd5 draft
is as it was, just adding SASLprep plus new example, keeping
the old examples, updated security considerations, and a new
MUST about not looking at the RHS of the challenge that could
cause a "recycle at PS", but this MUST can be simply removed.

> IESG members feel free to register DISCUSS positions and 
> then decline to engage in discussion or respond to 
> explanations from editors

If something is odd I'd try to cross-post to a public list or
to iesg@ietf to have it on public record.  So far the DISCUSS
explanation in the I-D tracker worked for me, a kind of review,
the author has to answer, and when the sponsoring AD is aware
of the answer the ball is again in their part of the field...
...with short periods when nobody knows where the ball is. :-)

> 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.

The published 2821 report is a bit odd, I wouldn't dare post
it in Wikipedia.  Of course the substance of my CRAM-MD5 report
is, while formally "nicer", not much better, and I freely admit
that I was inspired by the 2234 report, which is the output of
a "grep 2234" on a bunch of RFCs.

>> folks anyway only use a part of the specification, not its
>> integrity/confidentiality features.
 
> You left out "doesn't provide enough extra security in 
> practical cases to be worth the trouble".

Maybe, but CRAM-MD5 really has no mutual authentication, just
because the other side accepts a response doesn't mean that
it knows the secret and is the site folks want to talk with.

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

In this case I didn't try to sound cynical, I really consider
the rule forcing sponsoring ADs to vote YES as rather dubious.
No issue for individual I-Ds, authors can try to find another
AD, but for a WG draft it's a dilemma.  Maybe ADs should swap
"their" WGs biannually.

 Frank

---

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

> you think it's different (?)
RFC 2195 predates SASL, and is cast as a IMAP authentication method.  
Of course, everyone's used CRAM-MD5 as a SASL mechanism since SASL  
came about, so I think it's swings and roundabouts. I may be forced  
to invoke the "running code" argument, here.

> replacing SASLprep by RFC 5198, in the direction of "KISS".
I have to admit that I'm not strictly sure that this matters unduly -  
SASL itself didn't originally have i18n support, SASLprep et al  
postdate SASL by quite a way.

> cause a "recycle at PS", but this MUST can be simply removed.
Well, realistically, we could state that CRAM-MD5 is only defined for  
ASCII usernames and passwords, and simply specify it using modern  
language, with an updated Security Considerations. It's widely  
implemented, and I think deserves an updated specification which  
reflects lessons learnt.

A MUST NOT pay attention to the man behind the curtain - or indeed  
the RHS - is to my mind acceptable, but it could be neatly rephrased  
anyway as cautionary text to client implementors.

> >> integrity/confidentiality features.
Hey, I implemented that! (Well, the integrity, anyway).

> it knows the secret and is the site folks want to talk with.
Right - CRAM-MD5 has serious limitations, and is, these days, only  
useful when used under a TLS layer which itself has provided  
server-to-client authentication, and even then, you'll still be  
leaving cleartext passwords lying about on the server.

To make things clear, I think CRAM-MD5 is pretty close to rubbish,  
and has serious flaws compared with other, more modern, mechanisms. I  
think it should be used with caution, and the only reason to consider  
using it at all are because of its wide deployment.

But these are all excellent reasons to update the specification, in  
order to encourage safe usage, and discourage usage in general.  
Otherwise, the only documentation we have on CRAM-MD5 remains RFC  
2195.

> the rule forcing sponsoring ADs to vote YES as rather dubious.

I didn't know there was one - this seems somewhat odd for WG drafts,  
as you say.

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 10:28:55 -0500

> I didn't know there was one - this seems somewhat odd for WG drafts,  

I didn't either.  I am having a hard time believing that such a rule
would be a would one to have.

Nico

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 5 Jun 2008 21:36:39 +0200

Dave Cridland wrote:
 
>> I consider the crammd5 draft as 2195bis draft, apparently you
>> think it's different (?)

> RFC 2195 predates SASL, and is cast as a IMAP authentication 
> method.  Of course, everyone's used CRAM-MD5 as a SASL mechanism
> since SASL came about, so I think it's swings and roundabouts.
> I may be forced to invoke the "running code" argument, here.

Okay, we could say RFCs 2195 and 2222 were close enough for the
"DS" maturity as SASL mechanism.

> I have to admit that I'm not strictly sure that this matters
> unduly - SASL itself didn't originally have i18n support, 
> SASLprep et al postdate SASL by quite a way.

RFC 4422 is a PS, it would be nice to avoid this for a 2195bis.

> realistically, we could state that CRAM-MD5 is only defined
> for ASCII usernames and passwords, and simply specify it using
> modern language, with an updated Security Considerations. It's
> widely implemented, and I think deserves an updated specification
> which reflects lessons learnt.

+1  IMO the "limited use" note in the SASL registry for CRAM-MD5
makes no sense while less used mechanisms have a "common" note.

> A MUST NOT pay attention to the man behind the curtain - or
> indeed  the RHS - is to my mind acceptable, but it could be
> neatly rephrased anyway as cautionary text to client implementors.

I'd consider a challenge in the form of a message-id with its RHS
and "worldwide unique forever" blurb as an early attempt in the
direction of "mutual authentication" and "channel bindings", and
from that POV using "MUST" to express "not good enough" is harsh,
especially if this MUST could also force "recycle at PS".

    [DIGEST-MD5]

> Hey, I implemented that! (Well, the integrity, anyway).

Without a simple way to test it I didn't try it, but it's good
to know that RFC 2831 qop=auth-int implementations exist... :-)

 
> Right - CRAM-MD5 has serious limitations, and is, these days,
> only useful when used under a TLS layer which itself has provided  
 
> and has serious flaws compared with other, more modern, mechanisms.
> I think it should be used with caution, and the only reason to 
> consider using it at all are because of its wide deployment.
 
> But these are all excellent reasons to update the specification,  
> in order to encourage safe usage, and discourage usage in general.  

For different reasons DIGEST-MD5 is also rubbish.  It took my years
to figure out that RFC 2617 and 2831 md5-sess are simply different.

What's nice about CRAM-MD5 is that it is really easy to implement,
and in comparison with APOP or even AUTH LOGIN it is no snake oil.

 Frank

---

From: Bill Fenner <[email-masked]>
Date: Thu, 5 Jun 2008 15:53:47 -0400

> would be a would one to have.

I'm guessing you meant "a good one to have".

If a WG produces a document that the WG's AD does not think is good  
enough to ballot "YES" on, then there's a bigger problem.  The rule is  
there as basically an assertion that the AD is in agreement with the  
WG's direction.  If the WG is working within its charter, then the AD  
had better be in agreement, since the charter *is* the agreement  
between the WG and the IESG about what the WG will produce.

I wouldn't agree with Frank's characterization of the rule, however.   
Part of being a sponsoring AD is that you will ballot YES, i.e., you  
think it'd be good to publish the document.  So it's not so much  
forcing ADs to ballot YES as much as it's a procedural precondition of  
sponsoring a document to ballot YES.

Maybe I'm being naive.  What do you see as the problem with this  
procedure?

Thanks,
   Bill

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Jun 2008 14:57:05 -0500

> Maybe I'm being naive.  What do you see as the problem with this  

That you may find a technical problem worth voting no for?  I guess that
means DISCUSS till it's fixed.
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: "Bill Fenner" <[email-masked]>
Date: Thu, 5 Jun 2008 16:16:19 -0400

> means DISCUSS till it's fixed.

This is the reason for the 'AD Review' phase: to fix problems before
bringing the document to the IESG.  (Why waste the IESG's time
reviewing a document with known problems?)

There is no 'no' position.  The positions are described at
https://datatracker.ietf.org/idtracker/help/evaluation/ .

Note that these are not absolute rules; they are the procedures that
the IESG follows but the details of the IESG's working is left to the
IESG.  This means that if circumstances warrant (e.g., some draft
needs to be published quickly), it's quite possible for a sponsoring
AD to bring a document to a telechat while holding a DISCUSS position.

  Bill

---

From: Ted Hardie <[email-masked]>
Date: Thu, 5 Jun 2008 13:26:04 -0700

At 1:16 PM -0700 6/5/08, Bill Fenner wrote:
>It's quite possible for a sponsoring

It's also possible for the sponsoring AD to change the position from Yes
to DISCUSS during the processing.  For example, if an AD notes a problem
but trusts the sponsoring AD's judgement on how to fix better than his/her
own, then the sponsoring AD may end up holding the DISCUSS for the issue.
Sometimes this is informal as a "I won't let this go until this is done"
promise, but it can be formal if the release of the document
with all positions at No-ob or Yes would otherwise happen.

				Ted