Subject: Re: Interoperability (was: WG Last Call: draft-ietf-sasl-crammd5-08.txt)

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 11 Aug 2008 11:15:50 -0700

I believe there is consensus within the WG that RFC 2195 failed to  
adequately specify how character data inputs, in particular the shared  
secret, are to be encoded and prepared for input to cryptographic  
functions and this has lead to interoperability problems.  Your input  
was considered by the WG, but not found to be compelling.

-- Kurt

On Mar 14, 2007, at 12:40 PM, Frank Ellermann wrote:

>
>> address feedback to the Working Group mailing list.
>
> | prone to interoperability problems (see Section 4).
>
> If folks used their own kludges to negotiate charsets out of band
> it's their problem, not a problem in 2195.  The RFC 822 <msg-id>
> in the challenge is clearly ASCII.
>
> RFC 2277 published one year after 2095 clearly mandates to use
> UTF-8.  Alexey proposed to add a "SHOULD UTF-8" somewhere, IMO a
> "MUST" is clearer.
>
> The only "interoperability problem" left will be to use SASLprep,
> and that solves an inherent interoperability problem for Unicode.
>
> RFC 4616 also doesn't spread FUD about alleged "interoperability
> problems" wrt SASLprep, so I don't see why that should be needed
> here (in chapter 1).
>
> Frank
>
>

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 11 Aug 2008 11:36:38 -0700

On Aug 11, 2008, at 11:15 AM, Kurt Zeilenga wrote:

> adequately specify how character data inputs, in particular the  
> shared secret, are to be encoded and prepared for input to  
> cryptographic functions and this has lead to interoperability  
> problems.

I should add here:

I also believe there is consensus within the WG that draft-ietf-sasl- 
crammd5, while significantly better in this area (given the UTF-8 and  
SASLprep SHOULDs), it also fails to be precise enough to ensure  
interoperability between independent deployers of the mechanism.

> Your input was considered by the WG, but not found to be compelling.

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 12 Aug 2008 00:09:45 +0200

Kurt Zeilenga wrote:
 
> I believe there is consensus within the WG that RFC 2195
> failed to adequately specify how character data inputs,
> in particular the shared secret, are to be encoded and
> prepared for input to cryptographic functions

RFC 2195 was written before RFC 2277, the IETF Policy on
Character Sets and Languages.

Above its reference to RFC 822 (STD 11), which uses ASCII,
RFC 2195 was obviously designed for use with POP3 and IMAP
as specified in RFC 1731 and 1734 at this time.

RFC 2195 and 1734 both intend to be better than APOP, with
a reference to RFC 1731 in 1734 for some syntax fine print.

RFC 1731 in turn is based on RFC 1730 for the secrets of a
<userid> and <password> at this time:

   password        ::= astring
   userid          ::= astring

That boils down to the known concepts of ASCII atoms etc.
as used everywhere in protocols related to RFC 822 mail.

That RFC 1730 itself with its CHAR8 concept is not more
state of the art is understood, and IMO this needs no WG
consensus:  The RFCs replacing RFC 822, 1730, and 1734
are supposed to represent an IETF consensus at the time
when they were approved, or really soon wrt say 2822upd.

> this has lead to interoperability problems.

I've not heard of interoperabilty problems for RFC 2195
in the context of its specification.

If some implementations allowed non-ASCII, and missed the
fact that this requires a common charset, and that UTF-8
is the only candidate as specified in RFC 2277 published
three months after RFC 2195, then such "interop problems"
would be entirely the fault of these implementations.

The crammd5 drafts and the WG Charter tackle this trivial
issue, RFC 1730 <astring> or similar ASCII limitations are
obsolete, but fortunately UTF-8 can work "as is" in 8bit
clean code.

I'm fine with using SASLprep "everywhere" (incl. CRAM-MD5)
in SASL, or maybe switch to RFC 5198 "everywhere" when it
turns out that SASLprep is not implemented.

> Your input was considered by the WG, but not found to be

I appeal that decision.  As remedy I propose to issue an
IETF Last Call of the CRAM-MD5 draft on standards track.

 Frank

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 11 Aug 2008 17:28:51 -0700

>> prepared for input to cryptographic functions

Your message appears to be a rehash of prior comments.  I respond  
mainly to provoke some clarification precisely what you are appealing.

> as used everywhere in protocols related to RFC 822 mail.

The WG could have, I guess, chosen to limit the CRAM-MD5 userid and  
password to astrings.  Are you now suggesting the WG now (re)consider  
this?

> in the context of its specification.

I recall you participating in discussions where interoperability  
problems where discussed.   In particulars, discussions concerning  
interoperability issued due to RFC 2195 lack of precise specification  
of the character set/encoding/normalization of the CRAM-MD5 password  
word.

> would be entirely the fault of these implementations.

As I understand RFC 2277, RFC 2277 state what character set is used  
for any particular piece of character data used in any protocol.  It's  
a statement of what protocols ought to be capable of, not a statement  
of default character set/encoding for existing or future protocols.

> obsolete, but fortunately UTF-8 can work "as is" in 8bit

I believe there is significant disagreement that saying "use UTF-8" is  
sufficient to ensure interoperability of character data inputs to  
cryptographic functions.   I note that the WG discussed this various  
issue when revising RFC 2222 and that discussion lead to the following  
statement in RFC 4422 (which replaces RFC 2222):
>> In order to avoid interoperability problems due to differing  
>> normalizations, when a mechanism calls for character data (other  
>> than the authorization identity string) to be used as input to a  
>> cryptographic and/or comparison function, the specification MUST  
>> detail precisely how and where (client or server) the character  
>> data is to be prepared, including all normalizations, for input  
>> into the function to ensure proper operation.

Hence, I believe that consensus is that a "use UTF-8" statement is  
inadequate.   (I note that the crammd5 I-D says "should use UTF-8",  
which weaker than a "use UTF-8" statement".)

> in SASL,

I guess I don't quite understand what part of my statement you are  
appealing.   Are you arguing for a MUST UTF-8, MUST SASLprep?
> or maybe switch to RFC 5198 "everywhere" when it

> I appeal that decision.

Are you saying, that in your opinion, that the WG didn't consider your  
input?

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 11 Aug 2008 17:46:08 -0700

On 11 Aug 2008, at 5:28 PM, Kurt Zeilenga wrote:

> for any particular piece of character data used in any protocol.   
> It's a statement of what protocols ought to be capable of, not a  
> statement of default character set/encoding for existing or future  
> protocols.

s/RFC 2277 state/RFC 2277 does NOT state/

Sorry, Kurt

---

From: Sam Hartman <[email-masked]>
Date: Mon, 11 Aug 2008 21:15:56 -0400

Frank, when filing an appeal it is generally advisable to make it
clear whether you are appealing the process--in this case arguing that
the WG did not have the consensus Kurt claims it does--or appealing
the technical decsion--arguing that the WG is wrong.

It is also advisable to explain why you think the decision is
wrong--something that I do not believe you have done.

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 11 Aug 2008 18:44:16 -0700

On 14 Mar 2007, at 1:11 PM, Frank Ellermann wrote:

>
> | CRAM-MD5 is no longer considered to provide adequate protection.

I believe the WG consensus supports the inclusion of this statement in  
the I-D, as well as the detailed consideration text that follows it.

>
>
> That's not the case, as it depends on the circumstances where
> CRAM-MD5 is used.  E.g. over TLS it could be fine (ignoring the
> issue discussed in a separate thread wrt 2554bis), and CRAM-MD5
> is certainly better than APOP (as stated in 2195) or "LOGIN".
>
> It's also "better" than DIGEST-MD5 where it's easy to implement
> and almost impossible to get it wrong.  Where somebody managed
> to implement 2069 / 2617 / 2831 / 2831bis with their many more
> or less subtle differences CRAM-MD5 still isn't much worse for
> its purpose:  It only has no <cnonce> and no <response-auth>.
>
> That's noted in the 3rd paragraph of the security considerations.
> Readers are able to draw their own conclusions without this
> "executive summary" at the begin.  Besides there is already
> another summary in the intro:
>
> | The mechanism offers inadequate protection against common
> | attacks against application-level protocols (see Section 5)
> | and is prone to interoperability problems (see Section 4).
>
> Section 5 explains why that's not limited to application-
> level protols, therefore this statement could be truncated:
>
> | The mechanism offers inadequate protection against common
> | attacks (see Section 5).
>
> Frank

I believe the WG has considered your input here.   I do not see  
adequate support within the WG to make any of the changes you suggest.

-- Kurt

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 11 Aug 2008 18:41:46 -0700

On 14 Mar 2007, at 12:13 PM, Frank Ellermann wrote:

> Tom Yu wrote:
> | The CRAM-MD5 mechanism is intended to have limited use on the  
> Internet.

I believe WG consensus supports the general statement of applicability.

> That's not the case, as it clearly contradicts what RFC 2195 says.
> It's also in conflict with BCP 46, RFC 2244, RFC 2645, and 2554bis.

I believe the WG has considered your input in this area.

Regards, Kurt

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 11 Aug 2008 18:52:30 -0700

On 14 Mar 2007, at 12:05 PM, Frank Ellermann wrote:

>
> Tom Yu wrote:
>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-sasl-crammd5-08.txt
> [...]
>> Please review this document, and address feedback to the Working
>> Group mailing list.
>
> Why does it say "MUST NOT interpret the challenge in any way" ?

In reviewing the archives, I see no response to this specific  
question.   I ask that the editor, or other kind individuals, respond  
directly to this question.

Frank, to the extent you desire some change in the document here,  
please offer specific replacement text (stating precisely what OLD you  
want replaced with what NEW).   Thanks, Kurt

> It
> used to be an STD 11 <msg-id> as described in STD 53 (= different
> for each challenge).
>
> "Random data" is NEVER a <msg-id>, it could be the same no matter
> how unlikely that is.  A <msg-id> is supposed to be worldwide unique
> _forever_ (the 2195 use of the term "timestamp" also suggests this).
>
> Frank
>
>

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 12 Aug 2008 05:55:29 +0200

Kurt Zeilenga wrote:
 
> Your message appears to be a rehash of prior comments.

Just in case, I'm pretty sure that yesterday was the first
time I looked up any details in RFCs 1734, 1731, and 1730.

And of course I'm not sure that my "reconstruction" of the
historical RFC 2195 context is correct.  I recall that one
of the RFC 2195 co-authors supported my *prior* comments
in a similar direction on the general list some years ago:

<http://article.gmane.org/gmane.ietf.general/22272/>
<http://article.gmane.org/gmane.ietf.general/22297/>

> I recall you participating in discussions where
> interoperability problems where discussed.

Likely that was the thread on the general list two years
ago containing the articles linked above.  As noted I'm
not aware of practical CRAM-MD5 interop issues, otherwise
I'd have mentioned such issues in the interop report.

BTW, no new insights from my POV.  The about three times
in the last years I saw questions about CRAM-MD5 it was
about simple "how to" issues, not about interoperability.

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 12 Aug 2008 06:11:02 +0200

> On 14 Mar 2007, at 12:05 PM, Frank Ellermann wrote:

Rather old.  As long as the new MUST causes no procedural
problems I can live with it.  It is against the *concept*
of a Message-ID from my POV, but I can't judge if that is
actually an issue in the context of CRAM-MD5.

I also cannot judge if a Message-ID "nearer" to the idea
of channel-bindings than this new MUST, or how far beside
the point it was when I asked this question 21 months ago.

Maybe something I wrote off-list today hits a SASL point:
Is PLAIN over TLS without channel bindings less desirable
than CRAM-MD5 over TLS without channel bindings ?

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 12 Aug 2008 06:31:14 +0200

Sam Hartman wrote:

> it is generally advisable to make it clear whether you are
> appealing the process--in this case arguing that the WG did
> not have the consensus Kurt claims it does--or appealing

ACK.  There were some off list messages meanwhile, and I hope
that Pasi now has enough facts to figure out what it's about:

I'm not aware of any interop issues wrt RFC 2195, and I don't
consider CRAM-MD5 as a hopeless case.  I also couldn't say
that DIGEST-MD5 is hopeless, but it is certainly worse than
CRAM-MD5 wrt interoperability.

Kurt asked me to post one point also on the list, here it is:

|>> It is IMHO not posssible to promote CRAM-MD5 on standards
|>> track if its i18n issue is FUBAR.
[...]
| obviously I *disagree* with the premise of this statement,
| it is *not* impossible to add i18n to CRAM-MD5.  

| Your consensus statement exactly is this *disputed* premise,
| you indirectly say that CRAM-MD5 is a hopeless case.  

 Frank

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 11 Aug 2008 22:16:35 -0700

> than CRAM-MD5 over TLS without channel bindings ?

Depends on which traits one thinks are desirable.   In general, I  
would say that CRAM-MD5 offers slightly better security than PLAIN,  
while PLAIN offers better ability to support external/legacy password  
stores, proxy-authz, etc.

I don't think either is well suited for general use on the Internet  
without TLS.

(I note that I ignored the "without channel bindings" phrases in your  
question as neither PLAIN nor CRAM-MD5 provide channel bindings.)

---

From: Lyndon Nerenberg <[email-masked]>
Date: Mon, 11 Aug 2008 22:35:22 -0700 (PDT)

> Depends on which traits one thinks are desirable.   In general, I would say 
> that CRAM-MD5 offers slightly better security than PLAIN, while PLAIN offers 
> better ability to support external/legacy password stores, proxy-authz, etc.

Where is the peer reviewed analysis of CRAM-MD5 vs. PLAIN that everyone 
alludes to? A simple reference to it in son-of-2195 would solve this 
argument.

--lyndon

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 12 Aug 2008 11:31:20 +0200

Kurt Zeilenga wrote:

> I ignored the "without channel bindings" phrases in your  
> question as neither PLAIN nor CRAM-MD5 provide channel
> bindings.

Good, that is what I meant.  Likely I'm mistaken, but one
point of channel bindings appears to be an answer to the
question "am I talking with the site I wish to talk with"
(as opposed to a MITM). 

Even if that is an unrelated issue, PLAIN can't be a good
plan when I'm not sure about the other side. 

The right hand side of a challenge in "Message-ID format"
can be twisted into what I expect by an attacker, it's no
security feature.

I just wondered s/21/17/ months ago why the draft insists
on ignoring the format of the challenge with new MUSTard.

 Frank

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 12 Aug 2008 11:34:22 +0200

Lyndon Nerenberg <[email-masked]> writes:

>> while PLAIN offers better ability to support external/legacy
>> password stores, proxy-authz, etc.
>
> Where is the peer reviewed analysis of CRAM-MD5 vs. PLAIN that
> everyone alludes to? A simple reference to it in son-of-2195 would
> solve this argument.

I'm not aware of any existing good analysis of C vs P, but a comparison
can be made in a table.  Here is a starting point.  Questions of the
applicability of PLAIN vs CRAM-MD5 often comes up in deployment
discussions, so I agree that adding it to 2195bis would be a good thing.
This straw-man needs to be expanded and reviewed carefully though.

                        PLAIN               CRAM-MD5

Support for
Authorization             Yes                  No
Identity

Transfers
Passwords
in Clear Text             Yes (*)              No

Compatible with
hashed password           Yes                  No
databases, such
as Unix
/etc/shadow (**)

Requires a
mechanism-                Yes                  No
specific
password database (**)

Supports a
Channel Binding            No                  No

Cryptographic security
status                     None                Medium (***)

Support for non-ASCII
identities (SASLPrep       Yes                 No (?)
or UTF-8)

...

(*) PLAIN solves the security problem by being used under TLS.

(**) This is a consequence of the previous item, but explained from a
different point of view which often comes up in deployment.

(***) There are no published attack against HMAC-MD5 even though the
underlying MD5 function has been attacked.  There are analysis that
suggests HMAC can be used securely even with moderately broken hash
functions. [Reference to Krawczyk's paper]

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 12 Aug 2008 11:51:43 +0200

>> is certainly better than APOP (as stated in 2195) or "LOGIN".

I believe Frank has a point here: CRAM-MD5 under TLS with server
authentication does not have any of the security problems mentioned in
section 5, at least as far as I can tell from a quick read of the -10
document.

CRAM-MD5 does have interoperability problems in that it historically
doesn't require use of UTF-8 and SASLPrep.  However, support for
SASLPrep in PLAIN was added in a later revision of PLAIN.  The same
could be done for UTF-8 and SASLprep in CRAM-MD5 too, which would remove
that interoperability problems.

Summarizing, we could do for CRAM-MD5 what we did for PLAIN (require TLS
and require UTF-8 + SASLprep).  None of the arguments made in the
document would still stand against that construct (I think).  What is
puzzling is that the document already appear to strongly suggest use of
TLS and UTF-8 and SASLprep, so I think we have already solved the
security and interoperability problem inherent in the old CRAM-MD5
specification.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 12 Aug 2008 12:16:28 +0200

> turns out that SASLprep is not implemented.

Given how poor SASLprep works in practice (*), I think this could be
discussed (but separately from CRAM-MD5).

The IDNAbis effort seems now well under way, and it seems clear we
cannot re-use much of their work since they abandon the StringPrep
approach.  Passwords have quite different properties than domain names:
it is normal and encouraged for passwords to contain characters from
different scripts.  For example, some of the steps made by current
SASLprep reduces entropy (e.g., translates ª to a), which seems like a
property we failed to discuss at the time.  We cannot re-use much of the
output from the IDNAbis design discussions either, because they are
based on different assumptions.

The discussions about Unicode versioning in RFC 5198 is better than in
SASLprep.  Some elements of SASLprep, such as prohibiting certain
non-printable characters is useful.

Possibly SASLprep2 could be a profile of RFC 5198: applying certain
algorithmic tests to restrict some characters on top of the RFC 5198
output.

/Simon

(*) Primarily because of the restriction to Unicode 3.2, but partly
because it hasn't been widely implemented.

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 12 Aug 2008 13:06:05 +0200

Simon Josefsson wrote:

> Passwords have quite different properties than domain names:
> it is normal and encouraged for passwords to contain characters
> from different scripts.

Yes.  Recently I looked into a years old archive about the
creation of tables inverting simple passwords from various
forms (incl. MD5), and the various pre-configured subsets
of supported characters where limited to what you'd see on
US keyboard layouts.

The size of the tables and the time to compute them (once)
increased dramatically with the number of supported input
characters.  That's (in theory) no obsctacle for say 128
characters, it could be hopeless for 100,000 characters...

> Possibly SASLprep2 could be a profile of RFC 5198: applying
> certain algorithmic tests to restrict some characters on
> top of the RFC 5198 output.

Simplified RFC 5198 is UTF-8 NFC minus some control chars.
What further restrictions do you have in mind ?

 Frank

---

From: Tom Yu <[email-masked]>
Date: Tue, 12 Aug 2008 07:38:14 -0400

> question "am I talking with the site I wish to talk with"

As I recall, the server cares about MITM as well.  TLS without channel
bindings may give the client assurance about who it is talking to,
given adequate validation of the server certificate, but without an
adequately validated client certificate, the server does not know that
it is not communicating with a MITM posing as the client.

> can be twisted into what I expect by an attacker, it's no

Might this have been an aborted attempt at specifying how to use the
challenge to transmit additional information to a server, such as
channel binding information?  Or am I thinking of DIGEST?

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 12 Aug 2008 13:57:36 +0200

> What further restrictions do you have in mind ?

See RFC 4013 section 2.3 and RFC 3454 section 3.1.  I'm sure that some
of those prohibited characters are a bad idea for passwords (because the
prohibited characters would have added entropy).  However, some of them
may make sense in order to avoid display or implementation issues (e.g.,
change-display properties and tagging characters).

/Simon

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 12 Aug 2008 14:06:13 +0200

> Might this have been an aborted attempt at specifying how
> to use the challenge to transmit additional information to
> a server, such as channel binding information?  Or am I
> thinking of DIGEST?

I'd guess that RFC 2195 uses the format of a Message-ID for
a challenge, because that's what APOP also uses, and a known
(for mail and news related protocols) concept.

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 12 Aug 2008 15:12:47 +0200

> See RFC 4013 section 2.3 and RFC 3454 section 3.1.

Okay, RFC 5198 might be not radical enough with C0 controls.

If users insist on trying the icon of a fruit (private use)
in their passwords they need a warning that this might be 
difficult to produce on other platforms.  And if they then
still insist on it they have been warned.

Similar case:  One password I need for 'runas' (a kind of
'sudo' for NT) has the funny feature that I can't input it
on a command line.  OTOH it's perfectly non-ASCII.

Some sets in RFC 4013 2.3 are also eliminated in RFC 5198,
e.g., surrogates.  The BOM in RFC 3454 3.1 is a MUST NOT
in RFC 5198, anything else in RFC 3454 is not *obviously*
critical from my POV, e.g., SHY.

> However, some of them may make sense in order to avoid
> display or implementation issues (e.g., change-display
> properties and tagging characters).

Okay, RFC 5198 says the other side should be prepared to
handle the difference between SHOULD NFC and "MUST", this
handler might be confused by invalid tagging attempts...

...on the other hand this WG can't "fix Unicode" for its
purposes.  If we'd want that we could keep SASLprep as is,
maybe updating it to Unicode 5.1.

 Frank

---

From: Sam Hartman <[email-masked]>
Date: Tue, 12 Aug 2008 10:22:22 -0400

>>>>> "Frank" == Frank Ellermann <[email-masked]> writes:

    Frank> Sam Hartman wrote:

    >> appealing the process--in this case arguing that the WG did not
    >> have the consensus Kurt claims it does--or appealing the
    >> technical decsion--arguing that the WG is wrong.

    Frank> ACK.  There were some off list messages meanwhile, and I
    Frank> hope that Pasi now has enough facts to figure out what it's
    Frank> about:

    Frank> I'm not aware of any interop issues wrt RFC 2195, and I
    Frank> don't consider CRAM-MD5 as a hopeless case.  I also
    Frank> couldn't say that DIGEST-MD5 is hopeless, but it is
    Frank> certainly worse than CRAM-MD5 wrt interoperability.

You need to appeal to Kurt and tom before you can appeal anything to
Pasi.  With one exception in RFC 3005, IETF appeals start with the
party whose decision you disagree with.

(I personally think the chairs should require you to publically state
the substance of your appeal, not handle it off-list)

---

From: Tom Yu <[email-masked]>
Date: Tue, 12 Aug 2008 11:21:55 -0400

> (for mail and news related protocols) concept.

I meant that the introduction in draft-ietf-sasl-crammd5 of a new
requirement that an implementation not interpret the "string that
RFC2195 required to look like a RFC822 msg-id" might have been an
aborted attempt to provide a "covert channel" for signaling the use of
a channel binding.

Alternatively, the new requirement that the client not interpret the
challenge string might be an effort to improve interoperability with
servers that do not send challenge strings that strictly conform to
the syntax of RFC822 or RFC2822 msg-id strings.

Authors or others, please elaborate if you recall the history of this
change.

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 12 Aug 2008 17:39:29 +0200

Sam Hartman wrote:
 
> You need to appeal to Kurt and tom before you can appeal
> anything to Pasi.

They'll tell me if something isn't as RFC 2026 6.1.5 wants
it.  I think it is clear enough what the dispute is about,
Kurt and I already discussed it on and off list, and what
might help now is somebody with a fresh view on the issue.

That is what "dispute resolution" is about, plus the known
fact that you never get what you asked for, therefore don't
ask if you are not ready for an answer.  

(For a philosophical debate about the magic word consensus
 and IETF dispute resolution procedures let's jump to the
 general list, they're used to have CRAM-MD5 as show case)

 Frank

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 12 Aug 2008 09:22:40 -0700

> section 5, at least as far as I can tell from a quick read of the -10

Which is why there is a recommendation that TLS be used.

Given the mechanism can be used without TLS, detailing considerations  
for use without TLS seems quite appropriate.  It's also appropriate to  
discuss considerations for use with TLS.

It is my belief that WG consensus is that the current text is adequate  
in both of these areas.   I encourage anyone who thinks the current  
text can be approved upon offer alternative text for the WG to consider.

> that interoperability problems.

Right, one could MUST Unicode, MUST SASLprep, MUST-UTF-8.   To date, I  
simply haven't seen significant WG support for changing the SHOULDs to  
MUSTs.

> and require UTF-8 + SASLprep).

Because of CRAM-MD5 use of cryptographic functions, CRAM-MD5 requires  
more than what PLAIN requires.  PLAIN could get away with a server- 
side SHOULD as it presumed the server knows what it might otherwise be  
able to do to ensure proper function.   With CRAM-MD5, the client  
traditionally has had to rely on a priori knowledge of the character  
sets/encoding/normalization to ensure proper function, and that means  
that one cannot independently produce an interoperable  
implementation.   If one desires independently developed  
interoperability, then providing a precise definition of the character  
encoding and normalization procedures is a necessary (as MUSTed by RFC  
4422).  Such MUSTs would likely cause disruption.

I have no seen adequate support for MUSTs here.

> None of the arguments made in the

I don't believe the SHOULDs are adequate to ensure independently  
developed interoperability.

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 12 Aug 2008 09:32:51 -0700

On 12 Aug 2008, at 3:16 AM, Simon Josefsson wrote:

> approach.

I think we can re-use, at a minimum, their approach for moving away  
from StringPrep.

In revising RFC 4013, as I noted during the IETF#72 session, was to  
rework SASLprep such that algorithm would not rely, to the extent  
possible, tables tied to a particular version of Unicode but instead  
rely largely on Unicode properties.  Like in the IDNAbis work, there  
may be a need for an "exceptions" table.  Hopefully use of the  
"exceptions" table will be limited to, well, truly exceptional cases.

It is my intent to SASprepbis to be produce the same output as  
SASLprep when used with Unicode 3.2.

-- Kurt

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 12 Aug 2008 19:31:49 +0200

> discuss considerations for use with TLS.

Sure, but if CRAM-MD5 is used with TLS, the initial statement above is
misleading: there is nothing in the security considerations of CRAM-MD5
that explains how CRAM-MD5 under TLS fails to provide adequate
protection.

> text can be approved upon offer alternative text for the WG to

I suspect people read different things into the first statement here.  I
suggest to change it to:

  CRAM-MD5 used without TLS is no longer considered to provide adequate
  protection.

Otherwise it is unclear whether 'CRAM-MD5' refers to the actual
HMAC-mechanism used by CRAM-MD5 (then the sentence is true) or whether
it refers to CRAM-MD5 used under TLS (then the sentence is false).

> simply haven't seen significant WG support for changing the SHOULDs to

Agreed.  Note that PLAIN merely says that TLS SHOULD be used.  I believe
a SHOULD is sufficient, especially considering the good explanation of
the problems that leads to recommending TLS in the CRAM-MD5 document.

> I have no seen adequate support for MUSTs here.

Nor have I, but I don't believe MUST is required.  PLAIN contains:

   By default, implementations SHOULD advertise and make use of the
   PLAIN mechanism only when adequate data security services are in
   place.

It continues with:

   Specifications for IETF protocols that indicate that this
   mechanism is an applicable authentication mechanism MUST mandate that
   implementations support an strong data security service, such as TLS.

That places restrictions on specifications, not implementations, which
is somewhat weird, but CRAM-MD5 could do the same.  That is what I
propose to do.

> developed interoperability.

SHOULD has worked fine for PLAIN, so I disagree.

/Simon

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 12 Aug 2008 11:31:33 -0700

> is somewhat weird, but CRAM-MD5 could do the same.  That is what I

I personally think such a change would be good.   I feel that TLS  
recommendations to protect CRAM-MD5 ought to be the same as those we  
made for the TLS protection of PLAIN.

> SHOULD has worked fine for PLAIN, so I disagree.

It works fine because of PLAIN's design.  The party, the server, is  
preparing both the presented and stored strings.   In CRAM-MD5, two  
parties need to agree on the preparation on what preparation to use  
for things to work properly.

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 12 Aug 2008 21:54:55 +0200

Kurt Zeilenga wrote:

  [TLS]
>> That places restrictions on specifications, not implementations,
>> which is somewhat weird, but CRAM-MD5 could do the same.  That
>> is what I propose to do.
 
> recommendations to protect CRAM-MD5 ought to be the same as those
> we made for the TLS protection of PLAIN.

Could work.  What about existing protocols, has this to be limited
to future specifications ?  Normally we say "SHOULD" when we mean
"old stuff has a good excuse, its old".  IIRC there are a two old
protocols with a mandatory CRAM-MD5, one of them (on demand relay)
won't be updated anytime soon, if ever.

  [i18n]
> for things to work properly.

I don't get this point.  A new user creating an account picks a
free userid, and a password.  The details can vary, one way is
online in a Web form.  If the server can note these credentials
for PLAIN, it can also note it for CRAM-MD5 or other mechanisms,
in any required format(s), even the somewhat odd "APR1" format.

In what way is the design of PLAIN different ?  Like CRAM-MD5 it
sends the userid as plain text.  

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 12 Aug 2008 22:10:33 +0200

Tom Yu wrote:
 
> Authors or others, please elaborate if you recall the
> history of this change.

I'm also curious, it was in all ID.ietf-sasl-crammd5 
back to 2003, long before I started to read this list.

It was introduced in ID.nerenberg-sasl-crammd5-01:

<http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=http://tools.ietf.org/id/draft-nerenberg-sasl-crammd5-01.txt>

 Frank

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 12 Aug 2008 16:16:32 -0400

> won't be updated anytime soon, if ever.

No, we say SHOULD when we mean "do this, unless you think you have a pretty 
good reason not to".  Occasionally we say SHOULD when we mean MUST but want 
implementations written prior to the specification that don't meet the 
requirement to be able to claim they are compliant with the spec. 
Generally this is a poor idea, because it also allows implementations 
written _after_ the specification to claim they are compliant.  In other 
situations we say SHOULD when we mean "MUST, but we know that some 
implementations will sometimes behave differently in order to interoperate 
with old stuff, which is a good reason".  In those cases, the goal is not 
to make the old stuff compliant, but to make it so new stuff can be 
compliant while still interoperating with the old stuff.

In this case, the requirement applies to protocol specifications, not 
implementations.  It's unnecessary to say SHOULD instead of MUST in this 
case, because doing so is not going to have any effect on existing 
published protocols, but may have the wrong effect on new protocols.

Incidentally, my recollection is that this is exactly the sort of situation 
that arose with making CRAM-MD5 "limited use".  We chose that designation 
because it was felt that the method should be avoided in new protocols in 
favor of whatever new thing we end up with, but there were some existing 
protocols that mandated it.  Again, "limited use" does not mean "not 
deployed" or "no one uses this"; it means "we don't think new uses of this 
are a good idea", along the same lines as a RFC2119 SHOULD NOT.

> sends the userid as plain text.

PLAIN also sends the password as plain text.  CRAM-MD5 does not, so if the 
client does not encode the password correctly, there is nothing the server 
can do about it.

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 12 Aug 2008 13:44:21 -0700

On 12 Aug 2008, at 12:54 PM, Frank Ellermann wrote:

> to future specifications ?

The RFC 4616 requirement upon technical specifications applies  
regardless of whether that technical specification details a new or  
existing protocol.   The requirements simply means that when one  
revises a technical specification then need to address an additional  
concern.

> Normally we say "SHOULD" when we mean
> "old stuff has a good excuse, its old".

There are many reasons to use SHOULD.

> IIRC there are a two old

One might view newer requirements upon technical specification as a  
reason to update older specifications...
> in any required format(s), even the somewhat odd "APR1" format.

The point is that server is viewed has having more knowledge about the  
properties of values stored in its password store than the client.    
The client has no clue as to what encoding / preparation was used  
within the password store.

With PLAIN, the client lack of knowledge doesn't matter.  It simply  
provides the UTF-8 encoded Unicode password.  The server can sort it  
out.

But with CRAM-MD5, for independently implemented interoperability, the  
client must prepare the password for input into the cryptographic  
functions the same way the server does.   The client and server need  
to agree as to how to prepare the input to the cryptographic functions.

Note that RFC 4616 actually does detail why it used a SHOULD instead  
of a MUST.   I would argue that CRAM-MD5, for consideration on the  
Standard Track, do likewise.

One could argue that one could get away with something like:
    Except where the client and server have an a priori agreement to  
utilize a different character set, encoding, and/or preparation, the  
password MUST be represented using Unicode, prepared using SASLprep,  
and encoded as UTF-8 prior to input to the cryptographic functions.

Or alternatively as:
    The password SHOULD be represented using Unicode, prepared using  
SASLprep, and encoded as UTF-8 prior to input to the cryptographic  
functions.  Use of Unicode, SASLprep, and UTF-8 are not mandatory to  
allow clients and servers which have a priori agreements to use other  
character sets, character set encoding, and/or preparation to use  
whatever character sets, character set encoding, preparation they  
might agree to.  How a client and server might reach such an agreement  
is outside the scope of this specification.  It is also noted that  
such agreements will hinder interoperability with clients and servers  
strictly implement this specification (e.g., adhere to the above  
SHOULD).

As I noted when I recently brought up intended publication track of  
this I-D, one option is Standard Track with waiver.    The above text  
is basically asking for a waiver from the RFC 4422 requirement.

> sends the userid as plain text.

Unlike CRAM-MD5, PLAIN sends the password as plain text.

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 12 Aug 2008 13:47:42 -0700

> Authors or others, please elaborate if you recall the history of this

If I recall correctly, there was concern that some implementations  
might verify that string adheres to requirements that might placed  
upon msg-id strings in other situations.   The desire was to say that  
string has no semantical value.  Maybe there is a better way to say  
that...

-- Kurt

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 13 Aug 2008 00:27:21 +0200

Kurt Zeilenga wrote:

>> Normally we say "SHOULD" when we mean "old stuff
>> has a good excuse, its old".
 
> There are many reasons to use SHOULD.

Sure, "old" is just one reason commonly accepted as 
"good excuse" without talking about it, because a
protocol or programs written before the SHOULD was
introduced typically could not foresee this.

For other reasons updated specifications with a new
SHOULD ideally mention what might be good excuses,
otherwise folks could claim that "because I say so"
is good enough to violate a SHOULD.

 [i18n] 
> With PLAIN, the client lack of knowledge doesn't
> matter.  It simply provides the UTF-8 encoded
> Unicode password.  The server can sort it out.

Okay, got it, when say SASLprep is used this has
to be done on the side of the client for CRAM-MD5
passwords.  For PLAIN passwords the server can do
it or something else, as long as the client sends
UTF-8 (maybe limited to Unocode 3.2).

Apparently the client "MUST NOT" use SASLprep for 
PLAIN, that could confuse "something else" on the
server side.  Is that correct ?

SASLprep(x) = SASLprep( SASLprep(x)) would help
if both sides try the same preparation for PLAIN.

So we need a MUST for CRAM-MD5 and UTF8-non-ascii
passwords on the side of the client.  

>     Except where the client and server have an a
> priori agreement to utilize a different character
> set, encoding, and/or preparation, the password
> MUST be represented using Unicode, prepared using
> SASLprep, and encoded as UTF-8 prior to input
> to the cryptographic functions.

+1  A different charset is not necessarily an issue,
when it is transformed to SASLprepped UTF-8 in the
preparation step.  That's remotely the same idea as
for IRIs in legacy charsets.

A legacy charset could be even an advantage, almost
all of them are covered by Unicode 3.2, as required
by SASLprep.

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 13 Aug 2008 00:39:16 +0200

> string has no semantical value.  Maybe there is a better way to say  

How abot this:

 The challenge SHOULD have the form "<" id-left "@" id-right ">" as
 specified for a Message-ID in [2822upd].

Really [2822upd], not RFC 2822, not RFC.usefor-usefor, not RFC 822.

I'm very sure about this.  The "SHOULD" clearly indicates "or else"
for implementors with funny ideas about checking the *syntax* for
the purposes of CRAM-MD5.  But it would allow for limited "I expect
a certain right hand side" use cases.  It would also allow for "the
same challenge more than once is broken" processing.

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 13 Aug 2008 01:51:41 +0200

Jeffrey Hutzelman wrote:

> In this case, the requirement applies to protocol specifications,
> not implementations.  It's unnecessary to say SHOULD instead of
> MUST in this case, because doing so is not going to have any effect
> on existing published protocols, but may have the wrong effect on
> new protocols.

Makes sense.  OTOH you can't have a "MUST TLS" for ESMTPA, because
the definition of ESMTPA (as opposed to ESMTPSA) is "no TLS".  

The ESMTPA classification is no "protocol", but CRAM-MD5 is.  And
CRAM-MD5 is *the* most popular instance of this class in practice.

A SHOULD with enumerated "good excuses" could cover this situation.
Or a MUST with enumerated exceptions (at most five exceptions).

> Incidentally, my recollection is that this is exactly the sort
> of situation that arose with making CRAM-MD5 "limited use".

Based on Simon's PLAIN vs. CRAM-MD5 comparison table, and still
confident that one i18n "question mark" can be resolved. e.g. as
proposed by Kurt, this "limited use" misses far too many points.

I'd prefer CRAM-MD5 over TLS instead of PLAIN over TLS.  And in
legacy scenarios I prefer CRAM-MD5 over USER:PASS, DIGEST-MD5,
and APOP.

Admittedly "at most five exceptions" would be limited, but does
not cover CRAM-MD5 over TLS.  If you look at the SASL registry
you see that DIGEST-MD5 is listed as "common", ditto OTP.  There
is no plausible reason for this difference.

> it was felt that the method should be avoided in new protocols
> in favor of whatever new thing we end up with

Well, you certainly got the message that I consider it as FUD,
like some statements in DIGEST-MD5 how much better this is in
comparison with CRAM-MD5.  Folks saying so in blogs, or on a
list, outside of RFCs and IANA registries, is okay.  But in an
RFC and IANA registries I prefer technically justified facts.

Clearly DIGEST-MD5 does have features not offered by CRAM-MD5.
Clearly some of them aren't used or have bad interoperability
issues (the MD5sess mess).  Ignoring all that, there just is
no cnonce in CRAM-MD5, and no rspauth.  OTOH it is simple and
easy to implement, let implementors pick what they really need.

> it means "we don't think new uses of this are a good idea"

But that's a highly controversial statement.  From your POV it
is correct, from my POV it is still "when are we ready to get
rid of USER:PASS and APOP ?"  My enthusiasm for advanced stuff
that I've never implemented is also limited, especially if it
claims to offer "security" or "privacy" as defined and sold by
[insert some company you don't like].

 Frank

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 13 Aug 2008 02:42:09 +0200

> for things to work properly.

Ah, I understand your objection now.

Given that RFC 2195 appears to be ASCII only, I don't see a problem with
extending it to UTF-8 in a revised version and mandate that using a
SHOULD or MUST though.  If some client/server uses some other mechanism
to send non-ASCII, they weren't following the RFC anyway.

/Simon

---

From: Lyndon Nerenberg <[email-masked]>
Date: Tue, 12 Aug 2008 19:14:30 -0700 (PDT)

> It was introduced in ID.nerenberg-sasl-crammd5-01:

The original format of the challenge as a message-id was to encourage 
uniqueness. But the message-id format suffers from two serious flaws when 
used as a challenge:

1) The format is highly predictable. In particular, the RHS of the message 
id is often easily derived from the host's IP address. And often the LHS 
is derived from the time (easily guessed) and the process id (generally 
sequentially allocated, and easily brute forced due to the restricted 
range).

2) The character set of the message-id is very restricted, reducing 
the search space for brute force attacks.

Because of this it was decided to relax the restrictions on the syntax of 
the challenge to encourage the generation of more random and less 
predictable challenges. The current syntax does this while preserving 
backwards compatibility with older CRAM implementations (based on a 
minimal message-id of 'x@y').

The discussion pre-dated the documents adoption by the WG, but I'm 
reasonably certain it took place on the WG mailing list. If you're 
adventurous, check the list archives.

--lyndon

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 13 Aug 2008 07:12:09 +0200

Simon Josefsson writes:
> SHOULD or MUST though.

It doesn't say the password is ASCII, only that the digest being
sent is.  Authentication breaks if the password is UTF-8, one
protocol peer SASLpreps it, and the other does not.

OTOH it also breaks if the password is Latin-1, one peer translates to
UTF-8, and the other does not.  "MUST use UTF8/SASLprep" in practice
implies "client and whoever creates server secret MUST know which
character encoding is in use, so it can translate to UTF-8 if needed".
Simple solutions to that would be to reject 8-bit input or make it the
user's problem and expect UTF-8 input, of course.

-- 
Hallvard

---

From: Lyndon Nerenberg <[email-masked]>
Date: Wed, 13 Aug 2008 01:50:06 -0700 (PDT)

> 1) The format is highly predictable. In particular, the RHS of the message id 
> is often easily derived from the host's IP address. And often the LHS is 
> derived from the time (easily guessed) and the process id (generally 
> sequentially allocated, and easily brute forced due to the restricted range).

Sorry folks, brain in neutral. The above isn't relevant to CRAM. That 
crept in from another project I worked on.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 13 Aug 2008 11:31:35 +0200

> user's problem and expect UTF-8 input, of course.

True.  However, I think it is reasonable to assume that RFC 2195
intended for passwords to be ASCII only.  We can fix this lack of detail
with new text that says MUST UTF-8+SASLprep before hashing in 2195bis.
This is a problem that can be fixed when revising a standard, it doesn't
necessarily mean the standard is broken without any chance of rescuing
it.

/Simon

---

From: Sam Hartman <[email-masked]>
Date: Wed, 13 Aug 2008 10:17:31 -0400

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> Sure, but if CRAM-MD5 is used with TLS, the initial
    Simon> statement above is misleading: there is nothing in the
    Simon> security considerations of CRAM-MD5 that explains how
    Simon> CRAM-MD5 under TLS fails to provide adequate protection.

    >> It is my belief that WG consensus is that the current text is
    >> adequate in both of these areas.  I encourage anyone who thinks
    >> the current text can be approved upon offer alternative text
    >> for the WG to consider.

    Simon> I suspect people read different things into the first
    Simon> statement here.  I suggest to change it to:

    Simon>   CRAM-MD5 used without TLS is no longer considered to
    Simon> provide adequate protection.

I don't object to this change.
I do object to cram-md5 on the standards track.

Kurt commented that recommendations for cram-md5 should be the same
for plain.  I disagree because since cram-md5 is a challenge/response
mechanism we can do better than plain.  Plain is the best we can do in
cases where you need to send a password to the server.

However for challenge/response mechanisms we can get mutual
authentication and tie the mutual authentication to integrity
protection and/or confidentiality.  Since cram-md5 does not support
these capabilities either through security layers or channel binding,
 I do not think it should be updated on the standards track.

Also, I do believe that cram-md5's mechanisms for converting a
password into a key are weaker than is current accepted security
practice.

--Sam

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 13 Aug 2008 07:55:04 -0700

> This straw-man needs to be expanded and reviewed carefully though.

Supports Mutual Authentication	No No

Transfers identities in clear text	Yes (*)	Yes (*)
> password database (**)

Your answers to this seem reversed.

PLAIN doesn't require a mechanism specific password store.  Given the  
server has the presented password, the server can verify it against  
any password store, regardless of the algorithms used in that  
storage.  Unlike CRAM-MD5.

> status                     None                Medium (***)

Though I am certainly not an crypto expert, I would not give CRAM-MD5  
a medium here.  I'd probably give it a Minimal, to imply that the  
security benefit the mechanism gains by its use of crypto is minimal.

> functions. [Reference to Krawczyk's paper]

There is still concerns about dictionary attacks.   Of course, this  
isn't much of an issue when TLS is used.

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 13 Aug 2008 17:27:00 +0200

Lyndon Nerenberg wrote:

>> often the LHS is derived from the time (easily guessed) and the
>> process id (generally sequentially allocated, and easily brute
>> forced due to the restricted range).
 
> Sorry folks, brain in neutral. The above isn't relevant to CRAM.
> That crept in from another project I worked on.

Wait, I think it *IS* relevant.  Where the opposition can predict
a plausible challenge it won't help with security.  However the
"new" MUST NOT asks clients to never look at the details of the
challenge, therefore this point would be moot.

In another article I proposed a SHOULD that might better express
"this is not about strict msg-id syntax, but it could be related
 to security" than the MUST NOT.

>> The discussion pre-dated the documents adoption by the WG, but
>> I'm reasonably certain it took place on the WG mailing list.
>> If you're adventurous, check the list archives.

My obsession with Message-IDs (worldwide unique forever, no hash
or random number is good enough) doesn't go that far today... :-)

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 13 Aug 2008 18:02:37 +0200

Kurt Zeilenga wrote:

 [password specific DB]
> PLAIN doesn't require a mechanism specific password store.
[...]
> Unlike CRAM-MD5.

Something is odd in the table here, CRAM-MD5 also does not
require a mechanism specific password store.  

Maybe what Simon had in mind was that both require to store
the passwords per user on the server in some form boiling
down to "as is" or "plain text".   

Of course the server needs to know how SASLprep works for
comparisons of canonical (as defined by SASLprep) strings.

> I am certainly not an crypto expert, I would not give
> CRAM-MD5 a medium here.  I'd probably give it a Minimal

I think "minimal" would be something like SHA-1, where
you could buy a "reverse table" for almost any keyboard
input up to length 14 or similar.

So far HMAC doesn't have this problem.  That's the reason
why I forwarded a recent statement by Paul Hoffman about
HMAC to this list some weeks ago.

Especially wannabe-improvements of HMAC-MD5 to HMAC-SHA1
appear to be snake oil, both do their job.  The (***) in
Simon's table and Paul hopefully qualify as experts for
the purpose of judging HMAC security.

 Frank

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 13 Aug 2008 18:00:04 +0200

> Supports Mutual Authentication	No No

I'd add (*) to these as well, since TLS support mutual auth.

> Transfers identities in clear text	Yes (*)	Yes (*)

Good addition.

> storage.  Unlike CRAM-MD5.

Exactly right, I got them reversed.

> security benefit the mechanism gains by its use of crypto is minimal.

Any reference?  As far as I know, the best published attack on HMAC-MD5
is this paper:

Jongsung Kim, Alex Biryukov, Bart Preneel, Seokhie Hong, "On the
Security of HMAC and NMAC Based on HAVAL, MD4, MD5, SHA-0 and SHA-1",
2006.  http://homes.esat.kuleuven.be/~kjongsun/papers/scn02006.pdf

However there is no attack on the full HMAC-MD5 in it.  HMAC-MD5 should
be deprecated, but it is not yet as fatal as other uses of MD5.

If I understand correctly, there is a security proof of HMAC-MD5 even
considering MD5 is weak in:

http://eprint.iacr.org/2006/043

The only reason I can see to say anything else than 'High' here is that
MD5 is likely to go away from libraries eventually, and that it is
safest to move away from HMAC-MD5 while we can.

Saying that the crypto HMAC-MD5 provides is minimal appears false: its
security does not seem to have been lowered from a practical point of
view after the MD5 attacks.

> isn't much of an issue when TLS is used.

Right.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 13 Aug 2008 18:18:34 +0200

> password into a key are weaker than is current accepted security

We disagree on the principal here.  Merely because there are known
vulnerabilities (which can be fixed by using TLS), that shouldn't
prevent something to go on the standards track.  If that were the
metric, we wouldn't publish SMTP on the standards track due to spam
concerns.  You make it sound as if only perfect protocols should be on
the standards track.

Your approach would send the message that we recommend users to prefer
PLAIN+TLS over CRAM-MD5+TLS.

/Simon

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 13 Aug 2008 18:31:38 +0200

Sam Hartman wrote:
 
> protection and/or confidentiality.

As far as DIGEST-MD5 was an attempt to offer these features
folks here apparently decided to give up on it, because there
was no big demand for these features, and interoperability
was lousy.  Maybe this is a hen and egg problem, but whatever
the DIGEST-MD5 problems might be, they're no bugs in CRAM-MD5.

> I do believe that cram-md5's mechanisms for converting a
> password into a key are weaker than is current accepted
> security practice.

Then propose something better than HMAC, get it on standards
track, and deployed.  Removing CRAM-MD5 from standards track
won't get you there.  One algorithm I looked at (APR1) is IMO
far too odd to pass as "better".

When I proposed to look at RMX in a SCRAM-discussion the WG
apparently preferred what's now in the draft, based on HMAC.

Maybe SCRAM will be that "better" thing, but that's unrelated
to WG Charter and status questions for CRAM-MD5.  

It's IMO very good that it is now again possible to discuss
such issues, the situation where you in essence had a veto
was unsound (actually a "bug" in RFC 2026, not in RFC 2195).

 Frank

---

From: Sam Hartman <[email-masked]>
Date: Wed, 13 Aug 2008 12:33:37 -0400

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> We disagree on the principal here.  Merely because there
    Simon> are known vulnerabilities (which can be fixed by using
    Simon> TLS), that shouldn't prevent something to go on the
    Simon> standards track.  If that were the metric, we wouldn't
    Simon> publish SMTP on the standards track due to spam concerns.
    Simon> You make it sound as if only perfect protocols should be on
    Simon> the standards track.

I don't think I'd characterize things that way.  I think we should put
something on the standards track when we believe it is a good instance
of whatever it does.  There should be no significant vulnerabilities
that we can fix while it's still the same thing.

I think plain meets this criteria today.  In a few years, I suspect
we'll decide that phishing concerns are more important than the
ability to support plaintext passwords over TLS.

In particular, plain is the best we can do while supporting legacy
password systems.

Cram-md5 is no longer a good instance of a challenge-response
mechanism.  The world has evolved and integrity/confidentiality
protection are important, as is mutual authentication all at one
layer.  As such, I think cram-md5 no longer meets good practice for
the design of a challenge-response mechanism, so we should not
recommend it.

Note that my arguments do not apply to digest-md5.  If people want to
update digest-md5 on the standards track, I will not stand in their
way.  I personally don't think it worth doing.

To come back to your example of SMTP, I think if we had viable
proposal for an email transport that did not have spam concerns, we
should seriously question whether SMTP should remain on the standards
track.  I'm aware of no such proposals.

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 13 Aug 2008 09:50:00 -0700

On Aug 13, 2008, at 9:00 AM, Simon Josefsson wrote:

> Any reference?

I think we're talking about to different qualities.  Your using this  
merely to indicate the relative strength of HMAC-MD5 over possible  
alternatives.   I'm using this to reflect that the mechanism makes  
limited use of crypto and that a challedge-response system could do  
much better.  But anyways (using your intended quality).

> As far as I know, the best published attack on HMAC-MD5
> is this paper:
>

I would argue that if HMAC-MD5 should be deprecated that the status  
should be less than Medium (which implies something better than  
"should be be deprecated").

So instead of "minimal", I might instead suggest "Deprecated (***)"  
where **** includes a statement "Uses functions which should be  
deprecated".

---

From: Paul Leach <[email-masked]>
Date: Wed, 13 Aug 2008 10:41:18 -0700

Lots of snips in what's quoted below, but I agree with Sam, and add that if CRADM-MD5 doesn't have channel binding capabilities, then the weaknesses he cites _can not_ be fixed by using TLS. (As recent DefCon talks have shown with other protocols.)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Josefsson
Sent: Wednesday, August 13, 2008 9:19 AM
To: Sam Hartman
Cc: Kurt Zeilenga; Frank Ellermann; [email-masked]
Subject: Re: Security

We disagree on the principal here.  Merely because there are known
vulnerabilities (which can be fixed by using TLS), that shouldn't
prevent something to go on the standards track...

---

From: Sam Hartman <[email-masked]>
Date: Wed, 13 Aug 2008 13:55:40 -0400

>> protection and/or confidentiality.

    Frank> As far as DIGEST-MD5 was an attempt to offer these features
    Frank> folks here apparently decided to give up on it, because
    Frank> there was no big demand for these features, and
    Frank> interoperability was lousy.  Maybe this is a hen and egg
    Frank> problem, but whatever the DIGEST-MD5 problems might be,
    Frank> they're no bugs in CRAM-MD5.

And decided to pursue channel binding rather than security layers.
Personally I'm happy with either channel binding or security layers, but think one is required.

    >> password into a key are weaker than is current accepted

    Frank> Then propose something better than HMAC, 

My problem is not with HMAC, but with the lack of PBKDF2.  Note that I
am acting on my proposals by contributing to scram.

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 13 Aug 2008 20:03:01 +0200

Sam Hartman wrote:

> we should not recommend it.

The draft is very clear about that, maybe even on the
wrong side of the border to exaggeration.

To take another example, just because RFC 862 is also
known as STD 20 doesn't mean that starting echo servers
is "recommended".  

It means "IFF you do that here is how this works since
25 years":  mature + interoperable != recommended.

Similar, the POP3 standard (STD 53) doesn't imply that
folks better stay away from IMAP (not a STD).  Quite
the contrary it is a point of POP3 that there will be
no additional (= unnecessary) features.

Ditto RFC 3986 (URIs, STD 66) vs. 3987 (IRIs, not yet
as mature as URIs).

> If people want to update digest-md5 on the standards
> track, I will not stand in their way.  I personally
> don't think it worth doing.

<shrug />  Alexey's drafts were near to ready from my
POV, but "squeeze more features into a SASL mechanism
already suffering badly from far too many features" was
no good idea.  

Splitting it into a "+" version with a new name was an
idea.  The current standardization situation is again
strange:  RFC 2617 and 2831 are almost identical, 2831
is slightly better (wrt i18n), the better version will
be deprecated, keeping a less capable RFC 2617 (or its
successor).  

But I'm not going to appeal the DIGEST-MD5 decision,
actually its featurism and implementation difficulties
are the reason why I defend the far simpler CRAM-MD5.

 Frank

---

From: Sam Hartman <[email-masked]>
Date: Wed, 13 Aug 2008 14:40:27 -0400

>> we should not recommend it.

    Frank> The draft is very clear about that, maybe even on the wrong
    Frank> side of the border to exaggeration.

    Frank> To take another example, just because RFC 862 is also known
    Frank> as STD 20 doesn't mean that starting echo servers is
    Frank> "recommended".

I think echo could be moved to historic too in the limited use
category of historic.

I think at this point we've staded our positions and additional
discussion on this point is useless.

I think you've made a case that if we chose to do so, we could publish
a new cram-md5 on the standards track.  However doing that requires WG
consensus.  Whether that consensus exists is a question first
evaluated by the chairs.  I've made my position clear: I will not be
part of that consensus.  I think you have made your position clear:
you want to be part of a consensus.

---

From: Paul Leach <[email-masked]>
Date: Wed, 13 Aug 2008 11:39:51 -0700

Again I agree with Sam. String-to-key functions that allow attackers to make 10s of millions of password guesses per second on a single PC are definitely not where the world is at today.
Use of iterated hashes to make computation of the key from the password take a few hundred milliseconds really makes a difference -- that's what PBKDF2 does.

---

From: Tony Finch <[email-masked]>
Date: Wed, 13 Aug 2008 19:52:44 +0100

On Wed, 13 Aug 2008, Frank Ellermann wrote:
> Something is odd in the table here,

Yes, the "yes" and "no" were backwards in that line of the table.

> CRAM-MD5 also does not require a mechanism specific password store.

It does if your existing password store contains Unix-style crypted
passwords.

> Maybe what Simon had in mind was that both require to store the
> passwords per user on the server in some form boiling down to "as is" or
> "plain text".

You don't need to store plaintext passwords for SASL PLAIN.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOLE: WEST VEERING NORTHWEST 5 TO 7, DECREASING 4 FOR A TIME. ROUGH OR VERY
ROUGH BECOMING MODERATE OR ROUGH. SQUALLY SHOWERS. GOOD.

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 13 Aug 2008 21:09:29 +0200

> You don't need to store plaintext passwords for SASL PLAIN.

ACK, I missed that point.  Adding Simon's fixed table to the
draft, maybe in an informative appendix, would be Good Thing.

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 13 Aug 2008 21:33:16 +0200

Paul Leach wrote:

> Use of iterated hashes to make computation of the key
> from the password take a few hundred milliseconds really
> makes a difference -- that's what PBKDF2 does.

I recently looked into the documentation of an old tool
creating such tables.  It didn't address the question of
the cumulative effect of milliseconds, but I was very
impressed by the cumulative effects of "increase the set
of potential input characters".

The math is trivial, but I never saw the consequences of
say one GB vs. 700 GB, or one day vs. 1000 days, before.  

The larger numbers were for some proper subset of ASCII,
the smaller numbers were for upper case ASCII letters.

I think the draft is clear wrt this attack, but we could
try to make it clearer:

 Sending a response to an attacker for a challenge chosen
 by this attacker will - for most choices of a plausible
 password - reveal this password.  The mere use of TLS
 does not remove this attack vector.

Frank

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 13 Aug 2008 12:56:14 -0700

> It does if your existing password store contains Unix-style crypted

The source of this requirement is not the mechanism but the password  
store.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 13 Aug 2008 19:46:39 -0400

I think another thing you should adopt from IDNABIS is the idea of
code points that fall into the maybe-yes category and a permissive
rather than exclusive strategy.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 14 Aug 2008 08:16:55 +0200

> where **** includes a statement "Uses functions which should be

That's a better label for it, thanks.

/Simon

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 16 Aug 2008 10:01:01 +0200

Simon Josefsson wrote:

>>> http://homes.esat.kuleuven.be/~kjongsun/papers/scn02006.pdf
>>> However there is no attack on the full HMAC-MD5 in it.
>>> HMAC-MD5 should be deprecated, but it is not yet as
>>> fatal as other uses of MD5.

Sorry, I see no "HMAC-MD5" should be deprecated in this paper,
also not for HMA-SHA1, and their NMAC-variants.

The details are beyond me, but apparently the authors found
a theoretical attack, which implies that some kind of "real"
attack should exist, however nobody found it yet.  

Please correct me if I got this wrong.  

>> instead of "minimal", I might instead suggest "Deprecated
>> (***)" where **** includes a statement "Uses functions
>> which should be deprecated".
 
> That's a better label for it, thanks.

Certainly clearer, but "nobody found it yet" could be a case
of "impossible to find it".  If we are going to decree that
HMAC (and NMAC) should be *deprecated* for MD5 (and SHA-1)
we need some compelling references.  

 Frank

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 26 Aug 2008 11:10:09 -0700

> PLAIN+TLS over CRAM-MD5+TLS.

The problem as I see it is that the draft doesn't make it clear that  
we're recommending CRAM-MD5+TLS.  The one recommendation statement  
isn't enough.

Most implementors and deployers and users of PLAIN understand PLAIN's  
weaknesses without even reading RFC 4616.  Reading RFC 4616 reinforces  
what folks already understand.  But even so, RFC 4616 reiterates the  
recommendation in the Abstract and Introduction, provides examples  
showing use with TLS, and then reinforces its recommendations by  
clearly stated security considerations.  RFC 4616 also places  
requirements on IETF protocols that state PLAIN is an applicable  
authentication mechanisms that the protocol specification MUST mandate  
implementation of strong data security services.

Implementors, deployers and users of CRAM-MD5 appear not to well  
understand CRAM-MD5's weaknesses and hence are more apt to ignore the  
recommendation, especially one buried on page 5 of the specification.   
The CRAM-MD5 specification places no mandate on IETF protocols that  
state CRAM-MD5 is an applicable authentication mechanism.

-- Kurt

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 26 Aug 2008 20:40:37 +0200

> state CRAM-MD5 is an applicable authentication mechanism.

All of the above appear to be fixable by changing the CRAM-MD5 document.
Right?

A more interesting discussion seems to be: Assuming the document
recommends CRAM-MD5+TLS sufficiently well (similar to the wording in the
PLAIN document), would such a document be acceptable to put on the
Standards Track and with the applicability of COMMON?

If that is not the WG consensus, it would be clearer to abandon the
current CRAM-MD5 specification and produce a "Moving CRAM-MD5 to
Historic" document.

However, I believe CRAM-MD5+TLS, with warnings about channel binding
vulnerabilities, is valuable to have on the standards track until there
is other solutions that we can recommend instead (i.e., GS2+SCRAM).

Alternatively, publish the "CRAM-MD5 to Historic" document
simultaneously as the GS2+SCRAM document.

Thanks,
Simon

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 26 Aug 2008 12:19:22 -0700

> All of the above appear to be fixable by changing the CRAM-MD5  

Yes.  But I have a hard time assuming that the changes will actually  
happen.

> Standards Track and with the applicability of COMMON?

I'm personally think the I-D has other issues (such as interop) would  
are not yet adequately addressed.  I do think it's possibly that the I- 
D could be revised such to address all of its known issues, but I'm  
concerned that this might be viewed as being too disruptive.

> current CRAM-MD5 specification and produce a "Moving CRAM-MD5 to

Seems like an approach worth considering...

> simultaneously as the GS2+SCRAM document.

I suspect the alternative is likely easier to gain consensus for....

-- Kurt