Subject: which is our DIGEST-MD5 successor?

From: Tom Yu <[email-masked]>
Date: Mon, 10 Mar 2008 16:58:40 -0400

We have had several password-based SASL mechanism proposals submitted
to the WG for the purpose of replacing DIGEST-MD5.  Much of our
discussion has centered on SCRAM, but I would like to make sure that
we have consensus behind SCRAM and that all proposals presented to us
have been adequately considered.

I believe the HEXA proposal has been merged into SCRAM.  Simon
Josefsson has also submitted a password-based mechanism.  During
IETF70, I had misunderstood Simon's intention with this document and
believed that he was withdrawing it.  Simon has since stated that he
intends to continue pursuing his document.  The document remains
expired, as far as I can tell, so this may not be relevant anymore.
(Simon, do you intend to renew the document?)

I think Chris Newman said during the WG session at IETF70 that he
believed there was nothing in Simon's document that was not in SCRAM,
apart from a few paragraphs about making the protocol consistent with
GS2.  I later realized that Chris is listed as an author of SCRAM, and
would like additional opinions.

Has anyone other than Chris looked at Simon's document and concluded
that Simon's document is substantially feature-equivalent to SCRAM,
except for the few paragraphs about GS2 compatibility?  We can discuss
this during the WG session tomorrow, but getting some discussion
started on the mailing list in advance would also be useful.

---Tom

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 10 Mar 2008 23:47:42 +0100

> (Simon, do you intend to renew the document?)

Let me clarify: given that there weren't much interest from the SASL
community, I didn't think there were any point in describing the SASL
mappings of the GSS-API mechanism that my document specifies.  I may
have said that I would retire that part of the document.  My intention
is still to pursue the rest of the document as a normal GSS-API
mechanism.  I always wanted it possible to use the mechanism with GS2,
and when implementing I would probably use that as the first test case.

I do intend to pursue the GSS-API mechanism part of that document, but
alas haven't had time to implement it yet.  My document doesn't
necessarily have to be an IETF document though.  If SCRAM evolves into a
GSS-API mechanism, I would consider to use that instead, and drop my
proposal.  Or we could merge SCRAM and my draft, if people can agree on
the design.  My requirements are that it should be a GSS-API mechanism
and that it should use hashing, and not be specific to the SASL context.
I don't think I have other strong requirements.

A SASL-specific password-mechanism is likely to be simpler than a
GSS-API mechanism from a specification complexity point of view.  If
people want a dead simple SASL password mechanism specification that do
not mention GSS-API, I don't think that approach is compatible with my
goals.  Then we'll end up with two solutions for these two different
goals.

> would like additional opinions.

SCRAM isn't a GSS-API mechanism, as far as I know, so it fails the first
criteria I had when writing my password-auth document.  I must admit
that I haven't reviewed SCRAM since it was initially discussed.  Where
can I find the latest SCRAM document?

For reference, the latest version of my password document is available
from <http://josefsson.org/password/>.

/Simon

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 11 Mar 2008 05:30:06 +0100

Simon Josefsson wrote:

> Where can I find the latest SCRAM document?

<http://tools.ietf.org/html/scram> is a trick to find
drafts "by name", also nice as an "opensearch" form.

In draft-newman-auth-scram-05 appendix C (examples)
is still empty.
 
> the latest version of my password document is
> available from <http://josefsson.org/password/>.

Thanks, that uses HMAC-SHA-256 => nothing for me.

 Frank

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 11 Mar 2008 12:43:19 +0100

> In draft-newman-auth-scram-05 appendix C (examples)

Thanks.  SCRAM is not a GSS-API mechanism as far as I can tell, so I
believe we have different goals.  I guess it is up to the WG to decide
whether to base the password mechanism on GSS-API or not.

> Thanks, that uses HMAC-SHA-256 => nothing for me.

Could you elaborate why?  Supporting HMAC-SHA-1 or even HMAC-MD5 would
be easy, and the reason for picking HMAC-SHA-256 was rather arbitrary.

/Simon

---

From: Tom Yu <[email-masked]>
Date: Tue, 11 Mar 2008 09:28:27 -0400

> whether to base the password mechanism on GSS-API or not.

We have consensus to attempt making the new password-based mechanism a
valid GS2 mechanism (and thus also a valid GSS-API mechanism), only
specifying it in a way allowing for implementation without reference
to the GSS-API specs.

---Tom

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 11 Mar 2008 15:02:14 +0100

Simon Josefsson wrote:

> Could you elaborate why?

The short version:  My MD5 test suite is about MD5,
all MD5 examples in RFCs I'm aware of:
<http://omniplex.blogspot.com/2008/03/md5-16-pop3-and-uuid.html>

A somewhat longer version:  I don't trust SHA-*, I
think that folks wanting SHA-* claiming that it is
"better" often miss more than one point, I don't
have the 30..100K USD for a certificate (see SAAG
thread), and I don't like the SHA-* patent.  

That's as far as "for fun" is concerned, I'd have
no problem with implementing SHA-* professionally,
or using a certified library.  But I'd still ask
in what sense SHA-256 is "better" apart from the
obvious "twice as nothing happens" for 256=2*128.

Also a point in SCRAM, but I didn't check if it is
still there, does MD5( ... MD5( x ) ... ) make 
sense, apart from burning time ?  Why not simply
use MD5( counter || x ) instead of MD5^n( x ) ?

One nice property of MD5, I have vague ideas about
its limitations, e.g., nobody ever said that it is
suited to produce pseudo random numbers.  

 Frank

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 11 Mar 2008 10:16:50 -0400

> goals.  Then we'll end up with two solutions for these two different

I would be very disappointed to see separate password mechanisms for SASL 
and GSS-API, rather than one mechanism that can be used with either. 
Producing only a SASL mechanism would fail to meet the needs of GSS-API 
applications desiring support for password authentication (I would expect 
those to include NFSv4, though I haven't actually talked to that community).

While meeting the needs of pure GSS-API applications is not part of the 
SASL WG's mandate, I think we need to consider that there is going to be 
some demand for such a mechanism, which means it's likely to get done -- 
especially since Simon is telling us he's going to go ahead with that work 
whether or not it ends up also being the SASL WG's work product.

So, it seems highly likely there will be a GSS-API password mech.  Any such 
mech would have to go to some effort _not_ to work with GS2, which means 
that if we also do a SASL-only password mech, then there will be two 
independent password mechanisms that can be used with SASL.  That means we 
will have duplicated effort in developing those mechanisms, and there will 
be confusion among users, operators, and SASL application protocol 
designers and implementers as to which mechanism they should use.

Given all of that, I think everyone is best served by merging Simon's 
effort with SCRAM and producing a single mechanism which has the best 
properties of both, including the ability to be used as a GSS-API mechanism 
and a clear enough specification that it is possible to do a direct-to-SASL 
implementation without requiring a GSS-API library or an inderstanding of 
how GSS-API works.

> from <http://josefsson.org/password/>.

If you're going to continue this effort, I do think you should continue to 
maintain it as an internet-draft, where it can be easily found.  I also 
think that if the SASL WG ends up deciding to produce a SASL-only 
mechanism, you should pursue publishing your GSS-API mechanism on the 
standards-track via the individual submission process (i.e. find an AD to 
sponsor it).  While I would prefer to see a single mechanism that can be 
used with either framework, I believe that having two mechanisms would be 
preferable to not having a suitable password mechanism for GSS-API.

-- Jeff

---

From: Tom Yu <[email-masked]>
Date: Tue, 11 Mar 2008 11:13:16 -0400

> thread), and I don't like the SHA-* patent.  

Could you please elaborate on the SHA-* patent?  I only see one
message in the SAAG mailing list recently about that patent, and that
references an IPR notice claiming that the NSA makes the patent
available royalty-free.

---Tom

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 11 Mar 2008 22:36:21 +0100

Tom Yu wrote:
 
> that references an IPR notice claiming that the NSA makes
> the patent available royalty-free.

If you are talking about the IPR statement submitted by
Simon based on a report from a conference discussing hash
functions, that is what I had in mind:
<https://datatracker.ietf.org/ipr/795/>
<http://www.google.com/patents?q=6829355>

I only looked once in the NIST PDF referenced by RFC 4634.
Just copying the example code "as is" might be not good
enough for some applications:  IANAL.

 Frank

---

From: Chris Newman <[email-masked]>
Date: Wed, 12 Mar 2008 10:11:19 -0500

--On March 11, 2008 7:16:50 -0400 Jeffrey Hutzelman <[email-masked]> wrote:
> applications desiring support for password authentication

Having separate password-based mechanisms for SASL and GSS-API would be 
lunacy, IMHO.  Having the same password-based mechanism with different 
on-wire encodings for SASL and GSS-API is an option I want to leave on the 
table until I've seen the impact of GS2 on the on-wire encoding.

If the impact of GS2 on the authentication protocol is a fixed-size binary 
blob at the beginning of the protocol exchange (that can simply be omitted 
from diagnostic output and made optional when the code is running in debug 
mode), then I'm fine with a combined mechanism.  If the impact of GS2 is 
variable-sized binary or binary in multiple places in the authentication 
protocol, then I'd be much less comfortable with a dual-purpose 
wire-encoding.

If we have two wire encodings of the same mechanism, then SASL applications 
could access the same mechanism via two different names (e.g., 
SASL-FRIENDLY-NAME, GS2-KSDJFHSLKDSF).  But a simple applicability 
statement to not use the latter in SASL-based protocols is sufficient to 
resolve interoperability problems for this case.  I can't see this as a 
matter that will cause significant confusion.

While I prefer to avoid two different wire encodings for the same function, 
I consider the deployability of the mechanism to be a much more important 
concern and the deployment impact of binary in the SASL authentication 
protocol is significant in my experience.

While I once thought use of NUL for field delimiters in SASL PLAIN was 
clever (as it may benefit languages with NUL terminated strings and avoids 
quoting), my subsequent experience indicates it was a design error (not 
significant enough to merit a change now, but a mistake to avoid in the 
future).

		- Chris

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 12 Mar 2008 13:53:03 -0400 (EDT)

> matter that will cause significant confusion.

The problem in this case is that it requires GS2 implementations which
enumerate all GSS-API mechanisms and offer them all as SASL mechanisms to
know that _this_ mechanism is special and shouldn't be offered.  A large
part of the value of a wrapper is that it scales, making it unnecessary to
make specification or implementation changes to the SASL framework or SASL
applications for each new GSS-API mechanism.  Define a new mech (which
_anyone_ can do) and it just works.  The first time you require the
wrapper to handle a particular mechanism specially, you destroy that
property.

> protocol is significant in my experience.

Let us please be clear.  SASL is not a text-based.  SASL is binary.
SASL-using application protocols may be text-based, and this often
requires them to hex- or base64-encode SASL messages.  You are not going
to be able to look at the bits on the wire and debug a SASL mechanism,
especially in the text-based protocols that are its major users, without
some decoding assistance.

For example, IMAP's AUTHENTICATE command exchanges base64-encoded tokens;
this means that you cannot read SCRAM's semi-human-readable tokens in a
packet trace.

SMTP's AUTH command behaves the same way.

I'm seeing an awful lot of "GS2 is going to make the wire encoding more
complicated!  It's binary; binary is always complicated!" and similar FUD.
I really wish people would stop spreading that, RIGHT NOW, and go actually
read (or re-read) the documents in question.

As has been said repeatedly and at multiple meetings, the only additional
constraints the GSS-API places on tokens exchanged by a mechanism is the
presence of standard framing on the first context token, which is used
primarily to allow the recipient of such a token to tell what mechanism it
belongs to.  SASL doesn't need this, but it needs to be present anyway in
order to allow a pure-sasl implementation to interoperate with a
deployment in which a GS2 implementation has been layered on top of the
SCRAM GSS-API mechanism, _which may be done by an adminstrator without
either component knowing about it in advance_.

The emphasized part is an important capability; it's akin to being able to
buy your IP service from someone other than who provides the DSL layer,
and that from someone other than the local phone company.  Or, if you
prefer, being able to buy your email service from someone other than your
ISP.

The same issue is likely to contain some other constraints, because GS2
must use the GSS-API's abstract interface and operate the same for every
mechanism.  So, for example, it's going to exchange some number of tokens
to establish a context, and then it's going to exchange a token to
authenticate the channel bindings.  That last token can often be sent in
the same message as the last token of the context exchange, saving a round
trip.  But this can be done only by putting them in the same SASL token,
which means we have to have some way of representing the length of the
first token and whether the second is present or will require a separate
message (possibly this could be inferred).  Sam and Nico will tell us
exactly what this might look like for SCRAM, but it's likely to involve a
count of some sort.

I'm sorry if you don't like binary protocols, but I don't find "I prefer
ASCII only" a compelling argument for introducing market confusion,
interoperability problems, and/or implementation complexity in what is,
after all, _already_ a binary protocol.

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 Mar 2008 22:47:37 +0100

> SMTP's AUTH command behaves the same way.

In fairness, I've done a fair amount of SASL authentication debugging
using only a base64 decoder (e.g., emacs), and every time I have been
grateful that the protocol was textual rather than binary, even though I
had to by-pass the initial base64 obfuscation.

> read (or re-read) the documents in question.

For GS2, I think binary isn't an unreasonable choice, and I agree with
you.  I also think that there is some merit to having textual protocols,
and I think making our DIGEST-MD5 successor textual would be nice.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Mar 2008 17:05:46 -0500

> and I think making our DIGEST-MD5 successor textual would be nice.

There's very little binary anything in GS2:

 - two 32-bit unsigned network byte order lengths
 - another 32-bit quantity: maxbuf for security layers
 - a pair of one-byte flags for security layer and channel-binding
   negotiation
 - the actual GSS-API mechanism tokens in the authentication exchanges

Base64-encoding the GSS tokens would allow us to get rid of those two
lengths; the flags and the maxbuf can be expressed textually.

The GSS tokens in the _security layers_ would not need to be base64-
encoded -- that stuff (like the application plain-text) can be binary
and noone will mind.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 Mar 2008 23:23:37 +0100

> lengths; the flags and the maxbuf can be expressed textually.

That is true, and getting rid of the length fields would be neat.  But
if we are holding GS2, I suspect GS2 will be radically different when/if
brought back from its zombie state.  I'm not sure it makes sense to
spend time at this point to re-work the protocol for a technically small
change like this, when we may be doing larger changes later on.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Mar 2008 17:43:21 -0500

> change like this, when we may be doing larger changes later on.

I'm not done writing up the SCRAM+GS2 ABNF and related text.  After I
post that hopefully Chris and others will agree that it's not overly
complex, or perhaps they'll insist on making the changes I mention
above and then they'll find it agreeable.  That will get GS2 "unheld."

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 18 Mar 2008 20:41:51 -0400

--On Tuesday, March 18, 2008 05:05:46 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

>> > complicated!  It's binary; binary is always complicated!" and similar
>> > FUD. I really wish people would stop spreading that, RIGHT NOW, and go
>> > actually read (or re-read) the documents in question.
>>
> lengths

It would, but it would be otherwise unnecessary and would lead to a 
double-base64 in many cases.  That's a lot of bloat, not to mention making 
it more difficult to debug things when the underlying mechanism is 
text-based like SCRAM.  It makes the pure-SASL implementation of SCRAM look 
like "construct this string of key=value,..., then base-64-encode it.  Then 
(usually) base-64 encode it again."  I see developers of 
non-framework-using applications getting confused, and only applying the 
encoding once, or to the wrong thing, or....

I agree the flags and maxbuf can be expressed textually.  I submit that the 
lengths also can be, such that one might send

ctxlen=NNN\n<context token><wrap token>

(note the length of the wrap token is implicit.

-- Jeff