Subject: New GS2 design -- much simplified, and simplified SCRAM

From: Nicolas Williams <[email-masked]>
Date: Fri, 20 Feb 2009 18:06:47 -0600

Jeff Hutzelman and I spent a few hours re-designing GS2 so it's very
simple AND meets our channel binding constraints as discussed recently
on the list.  I've sent Jeff ABNF and sample possible exchanges; when
Jeff replies I will post the complete design, but not later than Monday
(I just want to make sure the actual description will not have obvious
mistakes).

[I may also send a copy to Simon, Sam and/or Alexey off-list.]

The goal: to make GS2 simple enough that SCRAM-as-GS2 can look as simple
as an incremental update to DIGEST-MD5, whether described as a pure SASL
mechanism or as a GSS-API mechanism used via GS2.

The following are the constraints we must meet as Jeff and I understand
them right now:

a) MUST NOT require any GSS-API changes;
b) MUST NOT require any changes to SASL APIs beyond the obvious and
   optional interface by which applications can pass channel bindings
   data to SASL;
c) MUST NOT include length encodings;
d) MUST NOT include two GSS tokens in one SASL auth message;
e) SCRAM-as-GS2 MUST NOT have that annoying GSS-API initial context
   token header naming the mechanism OID;
f) MUST support secure negotiation of security layers and max buffer
   size;
g) MUST support secure negotiation of channel bindings so that TLS
   libraries that don't support channel bindings APIs can be used;
h) channel binding failure MUST result in authentication failure;
i) MUST be round-trip optimized in the common case, but it's acceptable
   for an extra round-trip to occur when the client's max buffer and/or
   security layers requests are unacceptable to the server.

Not required and therefore abandoned:

 - The old GS2 negotiation of security layers being conditional on
   channel binding outcome.

Brief outline:

 - The new GS2 would use GSS-API channel bindings instead of doing
   channel binding at the GS2 layer.  This allows us to satisfy (c), (d)
   and (f).  No GSS-API per-message tokens would be used in the
   construction of SASL GS2 authentication messages.

 - The new GS2 would use two different SASL mechanism name forms to
   indicate whether the server application supports channel binding.
   Combined with the use of GSS-API channel bindings this allows us to
   satisfy (g).  And combined with GSS-API channel binding semantics
   we satisfy (h).

 - The new GS2 would compress the presence/absence of the GSS-API
   initial context token header into a boolean.  This will allow
   pure-SASL implementators of SCRAM-as-GS2 to not have to know how to
   encode/decode that annoying header.  This way we satisfy (e).

 - The new GS2 would incur an extra round-trip when the client's max
   buffer and/or security layers requests are unacceptable to the
   server, thus meeting (i).  This is needed in our design in order to
   meet all the other requirements, particularly (a), (c) and (d).

 - The new GS2 would require no changes to the GSS-API, thus meeting
   (a).

 - The new GS2 would imply no changes to SASL APIs other than the
   implied and optional need for a way to pass channel binding data to
   SASL, thus meeting (b).

Cheers,

Nico
--

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 21 Feb 2009 15:45:16 +0100

Nicolas Williams writes:
> The following are the constraints we must meet as Jeff and I 
> understand them right now:

Looks good. I'd say SHOULD instead of some of the MUSTs (e.g. OIDs have 
a bad reputation due to SNMP mistakes, but aren't instantly lethal). 
Looking forward to seeing the results.

Arnt

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 21 Feb 2009 12:40:22 -0600

> Looking forward to seeing the results.

In our case OIDs are just constant, opaque octet strings -- there's no
need to parse them, no need to do any conversions whatever.  Thus they
are mostly harmless (the biggest issue is making sure you don't make a
mistake when entering the constant strings into your source code).

In any case, a pure SASL implementation will not have to deal with OIDs.

The GS2 SASL mechanism names will continue to be based on hashing
GSS-API mechanism OIDs.  Jeff proposes that we have nicer names (e.g.,
"GS2A-SCRAM") and a registry of GSS-API mech OID -> SASL mech name that
can be looked up using extended GSS-API mechanism inquiry functions...

...but as I recall Sam opposes this on the reasonable grounds that since
no implementations of extended GSS-API mechanism inquiry exist this will
mean hardcoding these mappings in source code or configuration.
However, given the small number of standard GSS-API mechanisms (Kerberos
V, and soon SCRAM and PKU2U) I think this should be manageable until
extended GSS-API mechanism inquiry becomes widely implemented.  Pretty
SASL mechnames would just be icing on the cake though -- the other
issues are far more important.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 21 Feb 2009 14:23:33 -0600

> mechanism or as a GSS-API mechanism used via GS2.

Specifically, I think it can just be draft-newman-auth-scram-09.txt, but
executed in the context of the new GS2.  The new GS2 effectively adds a
little header to some SCRAM messages (with no ambiguities, no length
encodings, no base64 encodings of SCRAM messages, nothing fancy) and a
little header to the TLS (or whatever) channel binding data.

Nico
--

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 22 Feb 2009 21:30:37 +0100

Nicolas Williams writes:
> need to parse them, no need to do any conversions whatever.

AFAICT they don't suffer from the evils that have given OIDs a bad name 
either. But that won't stop people from getting a bad impression if 
they see the word OID.

Dave: Would you please repeat your usual story about buzzwords, first 
impressions and the likelihood of reading the RFC at all, etc, etc?

Arnt

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 22 Feb 2009 15:15:23 -0600

> impressions and the likelihood of reading the RFC at all, etc, etc?

It's all not relevant: SCRAM-as-new-GS2 will not be using OIDs at all
(except when used as a pure GSS-API mechanism outside the world of SASL,
and then only because RFC2743 requires it).

---

From: Dave Cridland <[email-masked]>
Date: Mon, 23 Feb 2009 10:40:05 +0000

> issues are far more important.

Then you misunderstand the reality of the situation - I'm afraid that  
whatever you might wish for, the reality is that the name is  
crucially important. I'm finding myself struggling to see where the  
incomprehension stems from.

Let's review how this mechanism, under whatever form it finally turns  
out, gets implemented and deployed.

1) Step one is that it gets designed and specified.

2) Step two is that the SASL libraries, or GSS-API libraries, include  
support for it. In particular, this means libraries like Cyrus SASL,  
et al. These implementations are done by people familiar with, and  
probably involved with, the specification.

3) Step three, optional, is that a protocol or environment uses it as  
a MTI. (In SCRAM's case, the candidate is XMPP, but we won't do this  
if we're concerned about complexity).

4) Step four is when server implementations which aren't using SASL  
libraries start to include support. In the XMPP world, many servers  
use Cyrus SASL or some such, and that accounts for some widely  
deployed servers like ejabberd, but not (as I recall) all of the  
popular ones. The email world tends to be more conservative, and many  
server-side SASL implementations are bespoke at least in my  
experience.

5) Step five, which occurs concurrently, is where client deployment  
starts. Most client authors will not include support for SCRAM until  
it's widely deployed in servers, and many client authors - especially  
in the relatively scattered email world - will first hear of the  
mechanism by seeing it advertised. Essentially all client SASL  
implementations are bespoke - although in principle Cyrus SASL et al  
support a client mode, for whatever reason it seems very unpopular to  
use it.

I strongly suspect that if a bespoke implementor finds GS2 before  
they find SCRAM they'll give up at that point irregardless of how  
simple the mechanism is. I'm not even convinced that most developers,  
faced with a mechanism name consisting of random characters, will  
even look up a specification. To get these developers to read and  
implement the specification, the mechanism needs to be not only  
simple, but seen to be simple.

To a certain extent, then, those that read the specification aren't  
really the audience you need to convince - nor, indeed, is anyone  
here.

Even if they get as far as reading the spec, most client authors will  
probably decide to do what I did, which is to interrogate the hash  
library as to what hashes I have available and look for mechanism  
names. This approach to hash agility is handy, in as much as with  
GS2, it won't require me to perform a preimage attack on the  
mechanism name, however it has the disadvantage that with GS2's  
cryptographically secure names [I'm told I shouldn't call them  
encrypted] I have to implement a DER encoder (at least for OIDs).

Oddly enough, for an XMPP/IMAP kind of guy, I actually know how to do  
this, and even know enough to think it might be the same as BER,  
hence I've even written it before, but it's relatively niche  
knowledge in the XMPP and email worlds.

And, perhaps more tellingly, I cannot be bothered to do this -  
SCRAM-HMAC-* took me about three or four hours, including a rough  
stab at channel binding. From prior experience, writing sufficient  
code to make this a GS2-<<MD5(SCRAM-HASH)>> will take me an  
equivalent amount of time. And no, in my implementation, supporting  
GSS-API isn't really an option.

Which means hash agility is actually harmed, and yes, it really is  
all in a name - Will S notwithstanding, a SCRAM by any other name  
turns out not to smell as sweet.

On a more positive note, I'm firmly convinced that wire  
interoperability between GSS-API and "native" SASL mechanisms is so  
unimportant as to be a waste of time to persue. I never did  
understand the argument that we should somehow retire SASL to  
increase wire compatibility between protocols which are  
wire-incompatible.

The important compatibility factor is allowing multiple mechanisms  
and authentication systems to share a common backend.

In our (Isode's) case, for example, we have two situations we care  
about:

a) Passwords are stored in the DSA in the clear. Mechanisms like  
DIGEST-MD5 and CRAM-MD5 are available to clients.

b) Passwords are stored in the DSA hashed. Only PLAIN (and X.509  
Simple Auth, XEP-0078, IMAP LOGIN, etc) are supported.

This is a Hobson's choice - wire security or DSA security. SCRAM  
allows this to be extended with a third choice - if we can choose the  
hashing mechanism in the DSA (which we often can), we can support  
SCRAM, too.

You all, hopefully, knew all this, but I get the impression that  
somewhere along the line, this has been forgotten.

If we did much with GSS-API (we don't), then we'd care about  
supporting some secure-ish password based mechanism in GSS-API, too,  
using the same attributes in the DSA. I doubt we'd bemoan the sad  
lack of wire compatibility, for the same reason we don't care about  
the sad lack of wire compatibility between X.509 Simple Auth and  
XEP-0078 - we just check a password. Writing the additional code to  
support all these PLAIN-a-likes isn't a huge amount of effort, and  
there's one of these *per protocol*, not just per authentication  
system.

This backend compatibility is great - nay, awesome - for us, and,  
too, for most service operators out there. To my mind, wire  
compatibility is - and I quote - "NEAT to have, not need to have".

I can tell this issue of wire-compatibility is important to you, but  
I don't believe for a moment it's important to your customers, it's  
certainly not important to ours, and I think it's going to actively  
damage deployment.

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

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 23 Feb 2009 10:51:24 -0600

> incomprehension stems from.

I don't see why the particular bits that appear on the wire as
"mechanism name" are all that important -- that's what I was talking
about.

The *actual* mechanism name -- the name by which we know it in
conversations, e-mails, documentation, ... -- that matters greatly.

Does that resolve the conflict?  Or did you really mean that the bits
that appear on the wire as "mechanism name" are greatly important?

> simple the mechanism is. I'm not even convinced that most developers,  

Which is why we want a SCRAM-as-GS2-but0described-as-pure-SASL document.

> simple, but seen to be simple.

But I don't think they'll be faced with "a mechanism name consisting of
random characters" (besides the fact that they are only random-looking
:)

The fact is that when customers request support for SCRAM they won't
say "I want you to support GS2A-EVBXI4ERUDP3Z7AT" or anything of the
sort.

> encrypted] I have to implement a DER encoder (at least for OIDs).

Not really.  I've seen DER-encoded OIDs hardcoded in C source plenty.

> And, perhaps more tellingly, I cannot be bothered to do this -  

You don't have to be.  The name is effectively constant and so can just
be hardcoded, just as you'd hardcode the name if it weren't
random-looking.

> Which means hash agility is actually harmed, and yes, it really is  

This is NOT about hash agility.

> increase wire compatibility between protocols which are  

Do you support or have you deployed GSS-API and SASL based applications?
I do/have.  I find the inability to use the same authentication
infrastructures in a variety of application protocols to be a serious
issue.  This is not about retiring SASL!  This is about getting
commonality of mechanisms.

> I can tell this issue of wire-compatibility is important to you, but  

Actually, it's not at all.  There is no wire compatibility in this case.
That was never the point.  The point is re-use.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 23 Feb 2009 11:20:20 -0600

> > >issues are far more important.

Also, to be clear, the point I was making in the above quote is this:
of all the problems we need to surmount in making GS2 and SCRAM-as-GS2
acceptable, the form of the mechanism names that appears on the wire was
the least of them, thus, solving that problem after solving all the
others was "icing on the cake."

And, to be clear, I don't oppose Jeff's proposal as to how to get pretty
SASL mechnames on the wire, but I recall that Sam did once oppose it,
and I explained what the reasons were as I recalled them.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 23 Feb 2009 12:50:55 -0600

> The following are the constraints we must meet as Jeff and I understand

Below is the new design, which needs to be read in conjunction with the
text I sent on Friday describing what the new goals and requirements
are.

This is a long post because it contains:

 - ABNF
 - Two sets of examples: one by reference to the ABNF, one with what an
   actual SCRAM-GS2 exchange would look like
 - Plenty of descriptive text

Fee free to read this out of order.

The new, simplified GS2 would be more or less as follows:

 - Only GSS security context tokens are used in the SASL authentication
   exchanges.

 - GSS-API channel binding is used to provide integrity protection for
   all plaintext bits on the wire added by GS2, as well as to provide
   channel binding support for SASL.

 - GS2 bits on the wire are used for:

    - SASL max buffer negotiation
    - SASL security layer negotiation
    - channel binding negotiation

Very little needs to be changed in draft-newman-auth-scram-09.txt to
make it a pure SASL description of SCRAM-as-new-GS2.

First let's look at generic SASL/GS2 authentication message exchanges.
Here I'll be making reference to the ABNF for GS2.  Further below I'll
actually give some examples of what SCRAM-GS2 will look like based on
draft-newman-auth-scram-09.txt, with actual/made up values instead of
ABNF rule names.

Terminology note: "initiator" and "acceptor" are GSS-API terms roughly
corresponding to SASL's "client" and "server".  Below when I use the GSS
terminology I am referring to the GSS-API mechanism wrapped by GS2, and
when I use the SASL terminology I am referring to the SASL application
and/or GS2.

Case 1: The GSS-API mech initiator has the last token and client max
	buffer/sec layer requests are acceptable to the server.

      C: Request authentication exchange (not a GS2 message, but a SASL one)
      S: Empty Challenge
      C: gs2-client-first-message	; see ABNF below
      S: gs2-server-first-response	; "   "    "
      C: gss-sec-token			; "   "    "
      S: gss-sec-token
      ...
      C: gss-sec-token
      S: Outcome of authentication exchange (not a GS2 message, ...)

Case 2: The GSS-API mech acceptor has the last token and client max
	buffer/sec layer requests are acceptable to the server.

      C: Request authentication exchange (not a GS2 message, ...)
      S: Empty Challenge
      C: gs2-client-first-message
      S: gs2-server-first-response
      C: gss-sec-token
      S: gss-sec-token
      ...
      C: Empty Response
      S: Outcome of authentication exchange (not a GS2 message, ...)

Case 3: The client's max buffer/sec layer requests are not acceptable to
	the server.  This case has an extra round-trip.

      C: Request authentication exchange
      S: Empty Challenge
      C: gs2-client-first-message
      S: gs2-server-first-response
      C: gs2-server-params gs2-client-first-message
      S: gss-sec-token
      C: gss-sec-token
      ...
      <rest as in case #1 or case #2>

The ABNF for the GS2 messages is as follows.

; Basic types
; OCTET, ... are core ABNF types; their definitions are excluded here
;
gss-sec-token = *OCTET		; a GSS-API security context token
buf-size = 4OCTET		; SASL buffer size
sec-layer =  "n"	; no sec layer
sec-layer =/ "i"	; integrity sec layer
sec-layer =/ "c"	; confidentiality (+ integrity) sec layer
sasl-gs2-mech-name =  "GS2A-" 16BASE32
sasl-gs2-mech-name =/ "GS2B-" 16BASE32
	; See notes below on why there are two GS2 SASL mech name forms.
	; Also, see separate thread about how we might get pretty
	; mechanism names, instead of ugly names that have base32
	; encoded hash of GSS-API mechanism OIDs...

client-max-bux = buf-size
server-max-buf = buf-size
client-sec-layer-req = sec-layer
server-sec-layers = 1*3sec-layer	; list of sec layers; this can
					; probably be specified better

; GS2 error message / header for first acceptor GSS sec context token
gs2-server-params = server-max-buf server-sec-layers
gs2-server-first-response =  ( R gs2-server-params )	; server rejects
							; the client's
							; max buffer
							; and/or sec
							; layers reqs
gs2-server-first-response =/ ( A gss-sec-token )	; server accepts
							; the client's
							; max buffer
							; and/or sec
							; layers reqs

; Types for GS2 header for first initiator GSS sec context token

; Compression of RFC2743 initial sec context token header (which has an
; annoying DER length that must be computed; here we elide it so that
; pure SASL implementors can avoid the pain of DER length
; encoding/decoding).
gss-init-token-standard-header-present = T / F
	; If the GSS-API standard init sec context OID header is present
	; then set this to T and remove that header from the initial
	; GSS-API context token, else set this bit to F

; If TLS (or whatever) channel binding is being done the client
; indicates it in the header using a boolean.
channel-bindings-present = T / F

; The actual header, including max buffer, sec layer, and the above two
; types.
gs2-client-first-header =  ( client-max-bux client-sec-layer-req
			      gss-init-token-standard-header-present
			      channel-bindings-present )

; Actual GS2 first client message: the header and the GSS-API initial
; context token (minus the RFC2743 initial context token header).
gs2-client-first-message = ( gs2-client-first-header gss-sec-token )

; The following is the ABNF for the GS2 header prefixed to the GSS-API
; channel binding data.
channel-type = *ALPHA "-"
channel-binding-data = *OCTET
channel-bindings-header = ( sasl-gs2-mech-name [gs2-server-params]
			    gs2-client-first-header )
;
; If the server rejected the client's initial max buffer / sec layer
; requests then the server's parameters are included in the channel-
; bindings-header (see optional bits above).
;
; GSS-API channel binding is *always* used, even when no channel is
; being bound (see optional bits below).
;
; Finally, note that this rule is not referenced above.  That's because
; it's only used to construct the channel bindings that will be fed to
; the mechanism and does not appear in the message exchanges show above,
; not directly.
gs2-channel-binding-data = channel-bindings-header
			   [(channel-type channel-binding-data)]

There will be two GS2 SASL mechnames for every GSS-API mechanism: one to
indicate that the server supports channel binding (e.g., to TLS), the
other one to indicate that the server does not.  This, combined with the
channel-bindings-present boolean in the gs2-client-first-header and in
the channel-bindings-header lets GS2 prevent downgrade attacks in the
case that a) TLS (or whatever) is in use and b) the server can't do
channel binding (e.g., because either or both of its TLS or SASL
libraries don't support it).

The mechname form GS2A-<OID-hash> will indicate channel binding support,
and the form GS2B-<OID-hash> will indicate the opposite.  The server
will advertise one or the other, BUT NEVER BOTH.

When a server advertises GS2A-<OID-hash> and the client uses
GS2B-<OID-hash> then there's a downgrade attack and the server MUST
reject authentication.  The server detects this because the mechname
chosen by the client will be bound into the GS2 exchange using the
GSS-API channel bindings -- *all* GS2 plaintext, including the mechname,
is integrity protected by including said plaintext in the channel-
bindings-header.

As you can see the new GS2 would consist of small headers used in just a
few places, with no length encodings anywhere.  And the new GS2 still
manages to be round-trip optimized in the common case.

GS2 security layers are *exactly* the same as specified in RFC2222.

This means that SCRAM should specify how to do GSS wrap tokens with
integrity protection.  This is very simple for SCRAM: the token will
consist of a sequence number, a MAC (of the wrapped data and sequence
#), and the wrapped data (no length need be encoded by SCRAM itself,
though there is a length encoding in the GS2 layer since there is one in
RFC2222's "GSSAPI" mechanism).  I'm assuming separate session keys for
each direction, otherwise there should be a direction flag in the token
as well.

A confidentiality sec layer could also be done for SCRAM, but I don't
think that's worthwhile.

A formal description of the new GS2 wouldn't be much longer than the
above text with RFC2119 terminology and references thrown in.

And now the examples with actual values.

Case 4: Same as case #1 above.  Additionally the client wants 8192 as
        its max buffer size, channel binding, and no security layers.

      C: Request authentication exchange (not a GS2 message, but a SASL one)
      S: Empty Challenge
      C: 0x00002000 n T T n=Chris Newman,r=ClientNonce
	 ---------------  ----------------------------
	 GS2 header           SCRAM message
         ^^^^^^^^^^ ^ ^ ^ ----------------------------
	 max buffer | | | 
	            | | |
	            | | channel binding is being used
	            | |
	            | SCRAM, as a standard GSS mech, would have that
		    | RFC2743 header, thus we compress it as "T" here
		    |
		    sec layer (none)

	 The channel bindings data will have been:

	    GS2A-SCRAMhash 0x00002000 n T T <actual TLS channel binding>

      S: A r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
         ^ -------------------------------------------
	 |          SCRAM message
	 |
	 GS2 header indicating that the server accepts the client's max
	 buffer size and requested sec layers
      C: c=0123456789ABCDEF,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4
      S: v=WxPv/siO5l+qxN4
      C: Empty message
      S: Outcome of authentication exchange (not a GS2 message, ...)

Case 5: Same as case #4, but with the server rejecting the client's max
	buffer proposal.

      C: Request authentication exchange (not a GS2 message, but a SASL one)
      S: Empty Challenge
      C: 0x00002000 n T T n=Chris Newman,r=ClientNonce
	 ---------------  ----------------------------
	 GS2 header           SCRAM message
         ^^^^^^^^^^ ^ ^ ^ ----------------------------
	 max buffer | | | 
	            | | |
	            | | channel binding is being used
	            | |
	            | SCRAM, as a standard GSS mech, would have that
		    | RFC2743 header, thus we compress it as "T" here
		    |
		    sec layer (none)

	 The channel bindings data will have been:

	    GS2A-SCRAMhash 0x00002000 n T T <actual TLS channel binding>

      S: R 0x00001000 ni
         ^ ^^^^^^^^^^ ^^
	 |     |      |
	 |     |      T server supports none and integrity for sec layers
	 |     |
	 | The server supports 4096 as the largest max buffer
	 |
	 Client proposal rejected

      C: 0x00001000 n T T n=Chris Newman,r=ClientNonce

	 The channel bindings data will have been:

	    GS2A-SCRAMhash 0x00001000 ni 0x00001000 n T T <actual TLS channel binding>

      S: A r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
      C: c=0123456789ABCDEF,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4
      S: v=WxPv/siO5l+qxN4
      C: Empty message
      S: Outcome of authentication exchange (not a GS2 message, ...)

All the hash values and channel bindings data are fake.

Comments?

Nico
--

---

From: Dave Cridland <[email-masked]>
Date: Mon, 23 Feb 2009 19:56:15 +0000

On Mon Feb 23 16:51:24 2009, Nicolas Williams wrote:
> Does that resolve the conflict?

No, because the developers that represent the great bulk of potential  
implementors won't be a party to the conversations and e-mails, and  
will only get as far as the documentation if sufficiently interested.

>   Or did you really mean that the bits
... and these "bits on the wire" are going to be their first contact,  
and they'll form a first impression very quickly based on that.  
They'll even base their decision to find and read the specification  
based purely on the name, and how often they see it.

> say "I want you to support GS2A-EVBXI4ERUDP3Z7AT" or anything of the
No, of course not. They'll say (as they do say to us, sometimes) "We  
have a policy that no passwords may be stored in the clear, how can  
you help us?". Typically, whatever solution we suggest will receive  
an immediate question of "How many of the common clients implement  
that?". As such, I'd like our answer to the former to involve SCRAM,  
and our answer to the latter to be "Lots".

I couldn't give a rodent's hindquarters how elegant the integration  
is with GSS-API, I only care whether I can get the right answers to  
my customers. I appreciate this is possibly a little pragmatic, and  
pragmatism is looked down upon in security circles.

> be hardcoded, just as you'd hardcode the name if it weren't
But I *haven't* hardcoded the names, yet I *have* implemented  
SCRAM-HMAC-* with multiple hashes, so your argument is dashed to  
peices on the hard rocks of reality. (I've hardcoded "SCRAM-HMAC-",  
"MD5", and "SHA-" - the 1 or bitlength is appended based on what I  
find in the Python hashlib).

> This is NOT about hash agility.
Nope. But I think there's an impact there.

> Do you support or have you deployed GSS-API and SASL based  

I've implemented SASL libraries, and bespoke SASL code. Yes, I'm  
probably biased toward SASL, but I have at least supported and  
deployed multiple different flavours of plaintext auth, and the fact  
they differ in syntax doesn't bother me a jot. 
I've also deployed multi-protocol services for relatively large ISPs  
with common authentication infrastructures over a variety of  
protocols - none of them based on GSS-API, mind.

> issue.

Right! *This* is the serious problem. The inability of SASL to have  
any mechanism besides the piss-poor PLAIN which can be used with  
something similar to /etc/shadow is a real pain. The fact that we  
currently give our customers a choice of "Security on the server or  
the wire, pick one" appalls me. (Okay, we do offer X.509 Strong Auth,  
too, but in terms of passwords...)

SCRAM solves this, and I have a burning need to ensure this solution  
is available ubiquitously - otherwise I'd have not bothered entering  
this debate at all.

>   This is not about retiring SASL!  This is about getting
And I'm telling you it's unimportant - it's the commonality in the  
authentication infrastructure that's important. Yes, a commonality of  
mechanisms does imply a commonality of infrastructure, and it's quite  
an elegant solution if it can be made to work, but I don't think it's  
sufficiently transparent to be made to work as effectively, and I  
think the SASL mechanism name alone is sufficient to cause serious  
deployment shortfall.

> That was never the point.  The point is re-use.

Great. So get the reuse where it's important, and worry about it  
there.

I get the distinct impression that a "true" GSS-API mechanism based  
around the same algorithm as SCRAM-HMAC-* is possible, and would look  
somewhat different (ie, it might well have security layers, and  
sundry other GSS-API-ish properties that fit better there). I'd have  
thought that this would surely offer the best of both worlds.

Dave.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 23 Feb 2009 15:02:17 -0600

I spoke to Sam about this today and we have an agreement on what to do
to make pretty SASL mechs on the wire possible.

I'll write it up later, but the point is: the name issue will go away
too.

So please review the example message exchanges (I should have put those
first) in the new design that I sent today.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 23 Feb 2009 15:21:33 -0600

On Mon, Feb 23, 2009 at 11:45:29AM -0800, [email-masked] wrote:
> > I find the inability to use the same authentication
> That's your goal. My goal is different: I want a mechanism that's capable of
> actually deploying into the application clients and servers I'm interested in,
> including but not limited to assorted email protocols, XMPP, and calendar. All
> the commonality of mechanism in the universe doesn't mean squat to me if nobody
> bothers to add support for either one, which is the likely outcome unless we
> hammer every last bit of unnecessary obscurity and complexity out of this.

We (Sam, Jeff and I) know now how to get rid of this last bit of
obscurity.

> Not to be catty or anything, but use has to preceed re-use.

Please be catty, but do at least review the following :)

This is what SCRAM would look like in the new GS2, and with pretty
names.

Here the client wants channel binding, no security layers, and max
buffer == 8192:

		    sec layer requested (none)

	    SCRAM-CB 0x00002000 n T T <actual TLS channel binding>

Here's the same exchange, but with the server rejecting the client's
proposed max buffer:

		    sec layer requested (none)

	    SCRAM-CB 0x00002000 n T T <actual TLS channel binding>

      S: R 0x00001000 ni;
         ^ ^^^^^^^^^^ ^^^
	 |     |      |

	 Same as above, but with the smaller max buffer.

	    SCRAM-CB 0x00001000 ni; 0x00001000 n T T <actual TLS channel binding>
	             ^^^^^^^^^^^^^^
		     |
		     The server's proposal gets added to the channel
		     bindings to provide integrity protection for it.

All the hash values and channel bindings data are fake.  The SCRAM
messages are taken straight from Chris' draft.

Comments?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 23 Feb 2009 15:54:53 -0600

>  - ABNF

The ABNF I posted contained one bug: the server-sec-layers rule results
in an ambiguity.  This is trivial to fix.

Also, the name rule will now be exactly what it is in RFC4422:

    sasl-mech    = 1*20mech-char
    mech-char    = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE
    ...

and a punctuation char (say, ';') can be used to separate the sasl-mech
name from other protocol elements.

The updated ABNF, then:

; Basic types
; OCTET, ... are core ABNF types; their definitions are excluded here
;
gss-sec-token = *OCTET		; a GSS-API security context token
buf-size = 4OCTET		; SASL buffer size
sec-layer =  "n"	; no sec layer
sec-layer =/ "i"	; integrity sec layer
sec-layer =/ "c"	; confidentiality (+ integrity) sec layer
sasl-gs2-mech-name =  sasl-mech "-CB" ";"
sasl-gs2-mech-name =/ sasl-mech "-NOCB" ";"

server-sec-layers = 1*3sec-layer ";"	; list of sec layers; this can

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 23 Feb 2009 16:02:52 -0600

> first) in the new design that I sent today.

Here's what we'll do about GS2 mech names:

1) Create a registry of GSS-API mechanism OID -> pretty SASL mech name
   mappings.

2) Add an abstract API to the GSS-API: GSS_SASL_name() that outputs the
   SASL name of a GSS-API mechanism.

3) GS2 will use the pretty name on wire for all GSS-API mechanisms
   except for mechanisms that have no registered SASL name.

   For mechanisms that have no registered SASL name GS2 will use a
   hash-based name.  This means it's important for GSS-API mechanisms to
   be born with a SASL name.

   (Also, what we call "composed mechanisms" may not have pretty SASL
   names ever, but that's really not an issue as no such mechanisms
   exist now and anyways they are mechanically composed, thus they
   arguably don't need pretty names or, in any case, might end up having
   very long composed pretty names.)

I think that should settle the last major issue.

Nico
--

---

From: [email-masked]
Date: Mon, 23 Feb 2009 11:45:29 -0800 (PST)

> that appear on the wire as "mechanism name" are greatly important?

'm afraid Dave really does mean that. And while I'm not quite as adamant about
the urgency of being able to advertise comprehensible mechanism on the wire as
Dave is, I do agree that having incomprehensible ones is a barrier to
deployment. And given how unlikely this is to deploy at this late date so
matter what we do, such barriers need to be removed if at all possible.

> random characters" (besides the fact that they are only random-looking

They will in the case of someone examining the output of what mechanisms a
particular server offers.

> say "I want you to support GS2A-EVBXI4ERUDP3Z7AT" or anything of the

Of course not. But this is entirely beside the point.

> I do/have.

I've supported and deployed multiple SASL-based applications. I have attempted
to do GSS-API stuff on a couple of occasions but have never been successful.

				Ned

---

From: [email-masked]
Date: Thu, 26 Feb 2009 10:54:54 -0800 (PST)

> Comments?

Asuuming the GS2 headers here are constants, I think this is simple ehough.

				Ned

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 26 Feb 2009 13:31:57 -0600

> Asuuming the GS2 headers here are constants, I think this is simple ehough.

The GS2 headers contain:

a) max buffer size, which is not really a constant, but which isn't all
   that variable in practice;

   (for apps that want channel binding this will be a constant as it's
   not relevant if no sec layers are used)

b) security layer proposals, which also are not really constants, and
   also not that variable in practice;

   (for apps that want channel binding this will be a constant, and for
   apps that don't want channel binding this will be a constant in the
   cases of SCRAM if we decide to provide only integrity protection)

c) the mechanism name;

   (for apps that want channel binding this is not a constant, but it
   does come from listing the server's SASL mechs; for apps that don't
   want channel binding this is as good as constant)

c) a small handful of boolean flags:

    - one is a constant in the SCRAM case (the RFC2743 compression flag);
    - one is true if channel binding is in being done;
    - and a flag to indicate server acceptance/rejection of client
      maxbuf and sec layers proposals.

   (for apps that keep to fixed maxbuf/channel binding proposals these
   are as good as constant)

These aren't all exactly constants, but the variability is minimal.

Nico
--

---

From: [email-masked]
Date: Fri, 27 Feb 2009 15:34:14 -0800 (PST)

> These aren't all exactly constants, but the variability is minimal.

Hmm. Well, it's a fair bit more variability that I'd like to see in there. So
this is really going to boil down to specsmanship and whether or not
it can be described in a way that's sufficiently clear all the GS2
stuff doesn't appear so unwieldy. Perhaps some sort of quickstart
guide on how to set all this stuff in the non-GSS-API case would help.

				Ned

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 27 Feb 2009 18:03:57 -0600

> guide on how to set all this stuff in the non-GSS-API case would help.

With the changes I describe below we have a single field that's likely
to be variable: the security layers request from.

SASL must handle max buffer negotiation and security layers negotiation,
right?  That's why I have that in GS2.  It means not having to have it
in SCRAM (is it a bug in Chris' I-D that SCRAM doesn't have these?).

RFC4422 doesn't seem to REQUIRE that max buffers/sec layers be
negotiable.  We clearly want negotiable sec layers, and negotiable
channel binding.  We don't necessarily want negotiable max buffer.

The flag indicating whether channel binding was done can actually be
removed, since the server can try to validate the client's HMAC both
ways, with and without channel binding.  And since that flag effectively
gets duplicated in the mech name I think I can just remove that flag.

By having a reasonable minimum max buffer and by requiring that the
server allow "none" and "integrity" sec layers (when the mechanism
supports integrity sec layers) we can also make sure that a SCRAM client
never triggers server rejection of the client's proposals.  That turns
one more byte into a constant and removes one alternative.

We're left with this:

      C: Request authentication exchange (not a GS2 message, but a SASL one)
      S: Empty Challenge
      C: 0x00002000 n T  n=Chris Newman,r=ClientNonce
         --------------- ----------------------------
           GS2 header          SCRAM message
         ^^^^^^^^^^ ^ ^
         max buffer | |
         (can be    | |
          constant) | |
                    | |
                    | SCRAM, as a standard GSS mech, would have that
                    | RFC2743 header, thus we compress it as "T" here
                    | (is constant for SCRAM, always)
                    |
                    sec layer (none in this case) (can be constant)

            SCRAM-CB 0x00002000 n T <actual TLS channel binding>
            ^^^^^^^^ ^^^^^^^^^^ ^ ^
            |        |          | |
            |        \          / /
            |         \        / /
            |          \      / /
            |           \    / /
            |            \  / /
            |             \/ /
            |             + /
	    |             |/
	    |             +
	    |             A copy of the header in front of SCRAM
            |
            |
            Mech name, effectively constant, provided by the app and
	    likely taken from server's SASL mech list.

      S: A r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
         ^ -------------------------------------------
         |          SCRAM message
         |
         GS2 header indicating that the server accepts the client's max
         buffer size and requested sec layers (constant if the client's
	 requested max buffer size is less than or equal to the minimum
	 max buffer size).

      C: c=0123456789ABCDEF,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4
         -------------------------------------------------------------
	 SCRAM message
      S: v=WxPv/siO5l+qxN4
         -----------------
	 SCRAM message
      C: Empty message
      S: Outcome of authentication exchange (not a GS2 message, ...)

The variant of the above without channel binding is trivial.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 27 Feb 2009 22:13:18 -0500

--On Friday, February 27, 2009 06:03:57 PM -0600 Nicolas Williams 
<[email-masked]> wrote:

>> Hmm. Well, it's a fair bit more variability that I'd like to see in
>> there. So this is really going to boil down to specsmanship and whether
>> or not it can be described in a way that's sufficiently clear all the GS2
>> stuff doesn't appear so unwieldy. Perhaps some sort of quickstart guide
>> on how to set all this stuff in the non-GSS-API case would help.
>

The max buffer size is specifically the maximum amount of protected data 
that can be sent in one security-layer message.  It doesn't have to be 
negotiable, but if it is not, then GS2 must fix a value.

This, and the field used to negotiate use of a security layer, are _not_ 
artifacts of GS2 or of trying to produce a dual-mode mechanism.  They are 
purely requirements of producing a SASL mechanism which is capable of 
negotiating these SASL features.  A GSS-API-only SCRAM would _not have_ 
these fields, but a SASL-only SCRAM _would_ have them.

Unless...
draft-newman-auth-scram-07.txt does not have these fields or their 
equivalent, because it does not provide a security layer.  Nico's proposal 
in its current form causes GS2 to provide a security layer when used with 
any GSS-API mechanism that supports GSS_wrap(), including SCRAM.  If we 
were to decide that GS2 didn't need to provide a security layer, then this 
would all go away.  I'm not sure there is a clean way to make security 
layer negotiation go away for GS2-SCRAM while still having GS2 provide it 
for other mechanisms.

We really should come to a consensus once and for all as to whether SASL 
security layers are a desirable feature or should be deprecated.  If they 
are desirable, then we bite the bullet and include support for them, 
including negotation of max buffer size, in GS2 and SCRAM (regardless of 
whether we continue with Nico's proposal or abandon it and define SCRAM as 
a SASL-only mechanism).   If we decide security layers are deprecated, then 
rip them out of GS2 entirely, and this whole negotiation thing goes away.

> gets duplicated in the mech name I think I can just remove that flag.

That flag does _not_ get duplicated in the mech name.

The mech name indicates whether the server is capable of supporting channel 
bindings; this _must_ be the same as the name the server actually 
advertised, and the server _must_ check that they are the same.  This is 
critical for the security of channel bindings, because it prevents an MITM 
attacker from forcing a downgrade when both sides actually support channel 
binding.

The flag in the message indicates whether the client actually sent channel 
binding data.  At first glance, it seems that this flag is redundant, since 
the HMAC will verify for at most one of the two possible CB data formats. 
However, it is required in the GS2 layer because GS2 only gets one chance 
to decide which CB data form it will pass to GSS_accept_sec_context().  You 
can't be sure you can just try the call a second time, because you need to 
provide the CB data starting on the first call, may not get the answer 
until the last call, and a multi-round-trip mechanism might produce tokens 
which cannot be replayed.  In fact, I could trivially construct a mechanism 
for which this would break, out of a pseudo-mechanism stacked above RFC4121.

I believe the channel-bindings-present flag has to stay.  Unless you want 
to abandon the semantics that allow authentication to succeed even when one 
side provides channel bindings data and the other does not, which sounds 
like asking for an interoperability problem.

Hint: sometimes interoperability means providing for negotiation.

> one more byte into a constant and removes one alternative.

Yes, one thing we can do is eliminate the server's ability to reject choice 
of security layer, instead requiring that it support everything the 
underlying GSS mechanism is capable of (for SCRAM, that means 'n' or 'i'). 
As you say, if we do that and fix the max buffer size, then we eliminate 
the possibility of extra round trips due to renegotiation of rejected 
options.  This also eliminates the need for the accept/reject flag on the 
server reply; if the client requests a security layer the mech doesn't 
support, then the server simply fails the authentication.

Then the exchange looks something like this:

C: <SASL request-auth>
S: <empty challenge>
C: nT+ n=Chris Newman,r=ClientNonce
S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
C: c=0123456789ABCDEF,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4
S: v=WxPv/siO5l+qxN4
C: <empty response>
S: <auth succeeds>

Where...
- Everything but the "nT+" on the client's first message is exactly
  as it would be in draft-newman-scram-auth
- "n" = no security layer (could be 'i' or 'p')
- "T" = channel bindings used (could be 'F' if not)
- "+" = GSS standard framing compression (fixed for SCRAM; could be '-'
        for GS2 with some non-standard GSS-API mechanism)
- The channel binding data looks like:
  "SCRAM-HMAC-SHA1-CB nT+ <TLS channel data>"

Without channel bindings, the client's first message contains nF+ instead 
of nT+, and the CB data is just "SCRAM-HMAC-SHA1-CB nF+".

If the server didn't support channel bindings (a fact which was advertised 
as part of the SASL mechanism name), then the client's first message always 
contains nF+ instead of nT+, and the CB data is "SCRAM-HMAC-SHA1-NC nF+".

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 27 Feb 2009 22:24:10 -0600

On Fri, Feb 27, 2009 at 10:13:18PM -0500, Jeffrey Hutzelman wrote:
> equivalent, because it does not provide a security layer.  [...]
> [...]
> security layers are a desirable feature or should be deprecated.  [...]

Chris said that he wants channel binding and no sec layers, but later it
was pointed out that not every implementor is ready to do channel
binding to TLS at this time, so I *think* we have consensus that SCRAM
should provide at least an integrity sec layer.

Which means that SCRAM will have to do at least sec layer negotiation,
and preferably also max buffer negotiation.  And since GS2 can provide
that, the complexity we're down to is really a bare minimum that we'll
have with or without GS2.

> That flag does _not_ get duplicated in the mech name.

No, I know, but for my purposes between the mech name and the fact that
the server can try to validate the HMAC twice it's good enough.  You
ought to let me get away with some simplifications, particularly when
you know I should know better (and I did) :)

Nico
--

---

From: Dave Cridland <[email-masked]>
Date: Sat, 28 Feb 2009 11:20:01 +0000

> should provide at least an integrity sec layer.

I've seen a lot of DIGEST-MD5 implementations. I've seen quite a few  
servers that offer security layers. I can only think of two clients  
that actually use security layers - one of which is mine, and  
probably used only by me, so I'm not sure that counts. This suggests  
to me that security layers - whilst possibly desirable from a  
theoretical standpoint - will be ignored in practise.

I agree that not every implementor will do TLS channel bindings. This  
is enforced mostly by not yet having those defined - if we went for,  
say, the concatenation of the client and Server finished messages in  
that order, I can implement within the next ten minutes - I actually  
have this code standing by.

Dave.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 28 Feb 2009 12:51:50 +0100

Nicolas Williams writes:
> Chris said that he wants channel binding and no sec layers, but later 
> it was pointed out that not every implementor is ready to do channel 
> binding to TLS at this time, so I *think* we have consensus that 
> SCRAM should provide at least an integrity sec layer.

SASL security layers haven't succeeded. I don't know why. If you know 
the reasons why, and they don't apply to SCRAM (as implemented by 
randoms, not by ietf-sasl regulars), then fine. Otherwise it's just a 
dead feature.

Arnt

---

From: Russ Allbery <[email-masked]>
Date: Sat, 28 Feb 2009 12:07:04 -0800

> randoms, not by ietf-sasl regulars), then fine. Otherwise it's just a

OpenLDAP clients implement SASL security layers, but that isn't an
end-user client with a UI so it probably doesn't count for what you're
trying to measure.  Even the e-mail clients that implement GSSAPI
authentication inside SASL almost universally don't make use of the
negotiated security layer, which has caused us all sorts of heartburn.

I suspect the reason why is that it requires hooking the authentication
protocol into the network transport calls for the rest of the application,
which is significantly more complex than just having a set of pluggable
authentication modules that you can fire and forget.

TLS of course also requires the same thing, but unfortunately clients
don't seem to implement SASL security layers at the same time that they
implement TLS.  (Which is very unfortunate, since both require touching
the same code and it's fairly easy to do both at the same time, provided
that you can work out the internal API to hook into your authentication
providers.)

In practice, the world seems to be converging on TLS for all transport
security regardless of how one authenticates.  I think this is very
unfortunate given that TLS is rather heavy, requires things like channel
bindings that most programmers don't understand, requires maintaining a
separate public key infrastructure, and is slower and more complicated
than just negotiating a security layer as part of the authentication
process, but I'm not sure any of us are going to be able to reverse the
trend.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 28 Feb 2009 13:27:54 -0600

On Sat, Feb 28, 2009 at 11:20:01AM +0000, Dave Cridland wrote:
> >SCRAM

I have an LDAP application that uses SASL/GSS-API with security layers
all the time.

But sure, I second Jeff's call for a consensus on security layers.  If
we agree we don't want them, then several bits of the GS2 headers go
away.

> is enforced mostly by not yet having those defined - if we went for,  

Actually, they are defined!  Just not in an RFC, but in an IANA
registry:

http://www.iana.org/assignments/channel-binding-types/
http://www.iana.org/assignments/channel-binding-types/tls-server-end-point
http://www.iana.org/assignments/channel-binding-types/tls-unique
http://www.iana.org/assignments/channel-binding-types/tls-unique-for-telnet

> have this code standing by.

See above.

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 28 Feb 2009 13:38:36 -0600

> randoms, not by ietf-sasl regulars), then fine. Otherwise it's just a 

Never minding the fact that I use them...  This is what SCRAM/GS2 would
look like without sec layer support in GS2:

      C: Request authentication exchange (not a GS2 message, but a SASL
one)                                                        
      S: Empty Challenge                                                                                                            
      C: T  n=Chris Newman,r=ClientNonce                                                                               
         ^  ----------------------------
         |     SCRAM message
	 |
	 GS2 field compressing the RFC2743 header; constant for SCRAM

            SCRAM-CB T <actual TLS channel binding, if any>
            ^^^^^^^^ ^
            |        |
            |        A copy of the header in front of SCRAM                                                                    
            |                                                                                                                       
            |                                                                                                                       
            Mech name, effectively constant, provided by the app and
            likely taken from server's SASL mech list.

      S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
         -------------------------------------------
            SCRAM message                                                                                                   

That means:

 - A single constant is used as a header to just one SCRAM message.

 - The mechanism name and a constant is used as a header to the channel
   binding data.

 - We still have two mechanism names: the server advertises only one of
   them, indicating whether the server supports channel binding.

   This and putting the mechname used into the channel binding is NOT an
   artifact of GS2 -- a pure SASL SCRAM would still need this.

The channel binding flag is gone -- the server can try to validate the
client's HMAC both, with and without channel binding data (but always
with the GS2 channel binding header).

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 28 Feb 2009 14:21:08 -0600

> process, but I'm not sure any of us are going to be able to reverse the

For an app programmer channel binding is actually simple: ask TLS for it
and give it to SASL.  Two function calls.  Passing the channel binding
to SASL can be done via a function call the app would have to do
anyways, so one function call.  The channel binding is an opaque octet
string requiring no interpretation by the app.

For a SCRAM implementor channel binding is also simple: add an
application-provided string as an input to one of the HMACs.

For TLS implementors it's also simple.  See the TLS channel binding
types registered at IANA.

I like where this is going.  Everyone seems to be saying "to hell with
sec layers" -- that simplifies GS2 enormously since it removes max
buffer and sec layer negotiation and leaves just that one RFC2743 header
compression constant.  The channel binding negotiation bits stay and
are needed whether or not GS2 is kept, so GS2 is really now just a
single boolean constant added to SCRAM.

Nico
--

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 28 Feb 2009 21:25:52 +0000

>in SCRAM (is it a bug in Chris' I-D that SCRAM doesn't have these?).
No, it is not a bug. A SASL mechanism may choose not to provide any 
security layer. But if it does, it must allow negotiation of the max 
buffer size.

>channel binding.
Right.

>We don't necessarily want negotiable max buffer.
>
I think that would be a mistake. This feature is important, as it allows 
the client to control its memory usage.

>gets duplicated in the mech name I think I can just remove that flag.
Sure.

>one more byte into a constant and removes one alternative.
Right.

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 28 Feb 2009 15:38:33 -0600

> security layer. But if it does, it must allow negotiation of the max 

Most who have commented since seem to be saying we don't want SCRAM to
have sec layers -- that we must always do channel binding.

Jeff's right: we need a consensus call on whether or not to bother with
sec layers.

Nico
--

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 28 Feb 2009 23:13:51 +0100

Nicolas Williams writes:
> Jeff's right: we need a consensus call on whether or not to bother 
> with sec layers.

Before that, I'd like to know whether security layers will be DOA. Why 
haven't they gotten more deployment before, and does SCRAM repeat 
whatever the reasons were?

Arnt

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 28 Feb 2009 16:27:41 -0600

> whatever the reasons were?

Russ Allbery explained one reason: using security layers means passing
all I/O through SASL functions, and that's just obnoxious, particularly
when it has to be done again for TLS, thus some app developers don't
seem to bother.

This has nothing to do with mechanism design mistakes.

I know of several apps that use SASL/GSSAPI sec layers just fine.  But
it's not examples of such apps that we need, we need examples of apps
that don't support sec layers.

Nico
-- 

Date: Sat, 28 Feb 2009 16:27:41 -0600
From: Nicolas Williams <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked], Dave Cridland <[email-masked]>, [email-masked]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Sender: [email-masked]

> whatever the reasons were?

Russ Allbery explained one reason: using security layers means passing
all I/O through SASL functions, and that's just obnoxious, particularly
when it has to be done again for TLS, thus some app developers don't
seem to bother.

This has nothing to do with mechanism design mistakes.

I know of several apps that use SASL/GSSAPI sec layers just fine.  But
it's not examples of such apps that we need, we need examples of apps
that don't support sec layers.

Nico
-- 

Date: Sat, 28 Feb 2009 23:13:51 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Cc: Alexey Melnikov <[email-masked]>, [email-masked], Dave Cridland <[email-masked]>, [email-masked]
Sender: [email-masked]

Arnt

Date: Sat, 28 Feb 2009 15:38:33 -0600
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked], Dave Cridland <[email-masked]>, [email-masked], Arnt Gulbrandsen <[email-masked]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Sender: [email-masked]

Nico
-- 

Date: Sat, 28 Feb 2009 21:25:52 +0000
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: [email-masked], Dave Cridland <[email-masked]>, [email-masked], Arnt Gulbrandsen <[email-masked]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Sender: [email-masked]

Right.

Sure.

Right.

Date: Sat, 28 Feb 2009 20:39:21 +0000
From: Alexey Melnikov <[email-masked]>
To: Paul Romero <[email-masked]>
CC: [email-masked]
Subject: Re: LOGIN mechanism: Standards Status
Sender: [email-masked]

Paul Romero wrote:

>Hi Folks:
Hi Paul,

>Does anybody have information about the standards status
>and use of the LOGIN mechanism relative to RFC 2554
>or 4954 ?
>  
>
There is no RFC documenting the LOGIN mechanism. There was a draft some 
time ago, but it has expired.

<http://www.melnikov.ca/mel/devel/SASL_ClientRef.html> gives a list of 
some clients using it.

Date: Sat, 28 Feb 2009 14:21:08 -0600
From: Nicolas Williams <[email-masked]>
To: Russ Allbery <[email-masked]>
Cc: [email-masked]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Sender: [email-masked]

Nico
-- 

Date: Sat, 28 Feb 2009 14:13:18 -0600
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Subject: Re: TLS channel bindings specification exists
Sender: [email-masked]

I should note that there are two TLS channel bindings specs that can
apply in a SASL situation.  Which begs the question: which one to use.

The TLS end-point channel binding has the property that it can be used
with TLS concentrators without modifying them.  But then, TLS end-point
channel binding is not always available.  Therefore the TLS end-point
channel binding should be preferred and thus used whenever it's
available.

Date: Sat, 28 Feb 2009 12:13:59 -0800
From: Paul Romero <[email-masked]>
Organization: RCOM Communications Software
To: [email-masked]
Subject: LOGIN mechanism: Standards Status
Sender: [email-masked]

Hi Folks:

Does anybody have information about the standards status
and use of the LOGIN mechanism relative to RFC 2554
or 4954 ?

Best Regards,

Paul R.

--
Paul Romero

RCOM Communications Software

Phone/Fax: (510)339-2628
E-Mail: [email-masked]

To: [email-masked]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Sat, 28 Feb 2009 12:07:04 -0800
Sender: [email-masked]

Date: Sat, 28 Feb 2009 13:38:36 -0600
From: Nicolas Williams <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], Jeffrey Hutzelman <[email-masked]>, Dave Cridland <[email-masked]>, [email-masked]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Sender: [email-masked]

That means:

Nico
-- 

Date: Sat, 28 Feb 2009 13:27:54 -0600
From: Nicolas Williams <[email-masked]>
To: Dave Cridland <[email-masked]>
Cc: [email-masked], [email-masked], Arnt Gulbrandsen <[email-masked]>, Jeffrey Hutzelman <[email-masked]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Sender: [email-masked]

See above.

Date: Sat, 28 Feb 2009 13:42:40 -0600
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Subject: TLS channel bindings specification exists
Sender: [email-masked]

A while back someone asked and I said it wasn't done.  That was a
complete and total brainfart.  I should know better since I reviewed the
specifications that exist:

Nico
-- 

Date: Sat, 28 Feb 2009 12:51:50 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Cc: [email-masked], Jeffrey Hutzelman <[email-masked]>, Dave Cridland <[email-masked]>, [email-masked]
Sender: [email-masked]

Arnt

Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Date: Sat, 28 Feb 2009 11:20:01 +0000
From: Dave Cridland <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, Jeffrey Hutzelman <[email-masked]>
Sender: [email-masked]

Dave.

Date: Fri, 27 Feb 2009 22:24:10 -0600
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: [email-masked], Dave Cridland <[email-masked]>, [email-masked], Arnt Gulbrandsen <[email-masked]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Sender: [email-masked]

Nico
-- 

Date: Fri, 27 Feb 2009 22:13:18 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>, [email-masked]
cc: Dave Cridland <[email-masked]>, [email-masked], Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Sender: [email-masked]

Unless...

C: <SASL request-auth>
S: <empty challenge>

Where...

-- Jeff

Date: Fri, 27 Feb 2009 18:03:57 -0600
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Cc: Dave Cridland <[email-masked]>, [email-masked], Arnt Gulbrandsen <[email-masked]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Sender: [email-masked]

We're left with this:

Nico
-- 

Date: Fri, 27 Feb 2009 15:34:14 -0800 (PST)
From: [email-masked]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
To: Nicolas Williams <[email-masked]>
Cc: [email-masked], Dave Cridland <[email-masked]>, [email-masked], Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

				Ned

Date: Fri, 27 Feb 2009 16:34:15 +0000
From: Alexey Melnikov <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
CC: [email-masked]
Subject: Re: A dignified burial for CRAM-MD5
Sender: [email-masked]

Lyndon Nerenberg wrote:

>
> Folks, it has been nearly a decade since the first move towards 
> re-stating CRAM-MD5 as a SASL mechanism. It's obvious now that this 
> will never happen.
>
> It's also obvious that CRAM-MD5 has entrenched itself to the point 
> where it's not going to go away any time soon (or late for that matter).
>
> The global base of interoperable deployments says we don't need to 
> issue a formal update to the specification. Frankly, anything that 
> fits inside two pages of text and works this well deserves to be left 
> well enough alone.
>
> Since the SASL WG can't come to an agreement about the status of 
> CRAM-MD5 -- other than it's adamantly opposed to its moving forward on 
> the standards track -- I think it's time for the WG to drop CRAM-MD5 
> from the work list. It's currently not a formal SASL mechanism, so 
> abandonment by the WG is a valid solution.
>
> This would leave RFC2195 in its present state, validating the existing 
> CRAM-MD5 deployments. Beside that, I'm proposing to put together a new 
> Informational RFC that documents the WGs concerns about the mechanism, 
> and addresses the interoperability issues. (Kurt's draft has done much 
> of this work already.)

This works for me.

Date: Fri, 27 Feb 2009 08:27:32 -0800
From: Paul Romero <[email-masked]>
Organization: RCOM Communications Software
To: Tony Finch <[email-masked]>
CC: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: TLS Requirement in SMTP RFC4954 and SASL
Sender: [email-masked]

Hi Tony:

CRAM-MD5 only specifies that  passwords/secrets are to be used
as plaintext and not how they are stored.

Best Regards,

Paul R.

Tony Finch wrote:

> On Thu, 26 Feb 2009, Paul Romero wrote:
> >
> > It isn't obvious to me why PLAIN over TLS would be more prevalent than
> > CRAM-MD5.
>
> CRAM-MD5 requires plaintext passwords on the server but PLAIN does not.
> (i.e. PLAIN is compatible with Unix password files.)
>
> Tony.
> --
> f.anthony.n.finch  <[email-masked]>  http://dotat.at/
> GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
> MODERATE OR GOOD.

--
Paul Romero

RCOM Communications Software

Phone/Fax: (510)339-2628
E-Mail: [email-masked]

Date: Fri, 27 Feb 2009 16:16:49 +0000
From: Tony Finch <[email-masked]>
To: Paul Romero <[email-masked]>
cc: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: TLS Requirement in SMTP RFC4954 and SASL
Sender: [email-masked]

On Thu, 26 Feb 2009, Paul Romero wrote:
>
> It isn't obvious to me why PLAIN over TLS would be more prevalent than
> CRAM-MD5.

CRAM-MD5 requires plaintext passwords on the server but PLAIN does not.
(i.e. PLAIN is compatible with Unix password files.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

Date: Fri, 27 Feb 2009 07:44:46 -0800
From: Paul Romero <[email-masked]>
Organization: RCOM Communications Software
To: Kurt Zeilenga <[email-masked]>
CC: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: TLS Requirement in SMTP RFC4954 and SASL
Sender: [email-masked]

Hi Kurt:

CRAM-MD5  is designed to prevent disclosure of authentication
data, and not privacy, delivery authentication, or identify
confirmation.
Most of those other issues can be handled by robust end to end
encryption of  E-Mail content. In most cases identity falsification
occurs due to the E-Mail originator being sloppy about protecting
his or her authentication data rather than a CRAM-MD5 failure.

Best Regards,

Paul R.

Kurt Zeilenga wrote:

> On Feb 26, 2009, at 9:28 PM, Paul Romero wrote:
>
> > I have observed that a lot of servers still use CRAM-MD5 which
> > seems OK when the E-Mail program is not used within a browser.
>
> If you don't mind your SMTP/IMAP/POP/... sessions being eavesdropped
> upon or highjacked.
>
> -- Kurt

--
Paul Romero

RCOM Communications Software

Phone/Fax: (510)339-2628
E-Mail: [email-masked]

Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Paul Romero <[email-masked]>
Subject: Re: TLS Requirement in SMTP RFC4954 and SASL
Date: Fri, 27 Feb 2009 05:00:27 -0800
Sender: [email-masked]

On Feb 26, 2009, at 9:28 PM, Paul Romero wrote:

> I have observed that a lot of servers still use CRAM-MD5 which
> seems OK when the E-Mail program is not used within a browser.

If you don't mind your SMTP/IMAP/POP/... sessions being eavesdropped  
upon or highjacked.

-- Kurt

Date: Fri, 27 Feb 2009 09:57:45 +0000
From: Alexey Melnikov <[email-masked]>
To: Paul Romero <[email-masked]>
CC: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: TLS Requirement in SMTP RFC4954 and SASL
Sender: [email-masked]

Paul Romero wrote:

>Hi Jeffry:
>
>I will look at RFC 3365 as you suggested.  However,
>I have observed that a lot of servers still use CRAM-MD5 which
>seems OK when the E-Mail program is not used within a browser.
>Disturbingly, especially in the case of an MS Outlook server,
>sometimes PLAIN and LOGIN authentication without TLS are
>the only choices offered.  (i.e. Bit off topic.)  It isn't obvious
>to me why PLAIN over TLS would be more prevalent than
>CRAM-MD5.
>  
>
Hi Paul,
A mandatory-to-implement authentication mechanism doesn't necessarily 
mean that it is prevalent, but it means that the specified 
authentication mechanism is considered to be more secure/better/etc. by 
the IETF community.

Alexey

P.S. I can rant about MS Outlook compliance with various email related 
standards, but I should probably do this off-list.

>Best Regards,
>
>Paul R.
>
>
>Jeffrey Hutzelman wrote:
>  
>
>>--On Thursday, February 26, 2009 08:13:48 AM -0800 Paul Romero
>><[email-masked]> wrote:
>>    
>>
>>>Hi Simon:
>>>
>>>I would like your interpretation of the section of  RFC 4954
>>>which applies to  using  PLAIN authentication over TLS.
>>>Section 4 contains the following statement on this subject:
>>>
>>>"To ensure interoperability, client and server implementations of
>>>this extension MUST implement the [PLAIN] SASL mechanism
>>>running over [TLS] [SMTP-TLS]."
>>>
>>>Does this mean that supporting both TLS and PLAIN is
>>>an absolute requirement for a client, or that a client can
>>>only use PLAIN authentication if it supports and agrees
>>>to using TLS ?
>>>      
>>>
>>It means what it says.  If a client implements RFC4954, it must be able to
>>do PLAIN over TLS; otherwise, it is nonconformant.  This requirement is
>>necessary to insure interoperability, because some servers will not support
>>anything other than PLAIN over TLS.
>>    
>>
>>>I suppose a lot of people have asked this question.
>>>      
>>>
>>Not on the ietf-sasl list, they haven't.  Of course, the question is really
>>only indirectly related to SASL, so it's possible people have asked on
>>other lists.
>>    
>>
>>>It is of
>>>concern to me because small SMTP clients in embedded
>>>environments often do not have sufficient resources to support TLS.
>>>A strict interpretation of the section 4 language means support
>>>for TLS is mandatory for all clients.
>>>      
>>>
>>That is the correct interpretation; TLS is mandatory for all
>>implementattions of RFC4954.  See section 7 of RFC3365 for a partial
>>explanation of why.
>>
>>It should be noted that nothing said by Simon, myself, or anyone else on
>>this list should be interpreted as an official position of the IETF.  The
>>positions of the IETF and its working groups are determined by rough
>>consensus as determined by the appropriate leadership.  RFC4954 and RFC3365
>>are examples of products of IETF consensus.
>>
>>-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
>>   Carnegie Mellon University - Pittsburgh, PA
>>    
>>

Date: Thu, 26 Feb 2009 21:28:30 -0800
From: Paul Romero <[email-masked]>
Organization: RCOM Communications Software
To: Jeffrey Hutzelman <[email-masked]>
CC: [email-masked]
Subject: Re: TLS Requirement in SMTP RFC4954 and SASL
Sender: [email-masked]

Hi Jeffry:

I will look at RFC 3365 as you suggested.  However,
I have observed that a lot of servers still use CRAM-MD5 which
seems OK when the E-Mail program is not used within a browser.
Disturbingly, especially in the case of an MS Outlook server,
sometimes PLAIN and LOGIN authentication without TLS are
the only choices offered.  (i.e. Bit off topic.)  It isn't obvious
to me why PLAIN over TLS would be more prevalent than
CRAM-MD5.

Best Regards,

Paul R.

Jeffrey Hutzelman wrote:

> --On Thursday, February 26, 2009 08:13:48 AM -0800 Paul Romero
> <[email-masked]> wrote:
>
> >
> > Hi Simon:
> >
> > I would like your interpretation of the section of  RFC 4954
> > which applies to  using  PLAIN authentication over TLS.
> > Section 4 contains the following statement on this subject:
> >
> > "To ensure interoperability, client and server implementations of
> > this extension MUST implement the [PLAIN] SASL mechanism
> > running over [TLS] [SMTP-TLS]."
> >
> > Does this mean that supporting both TLS and PLAIN is
> > an absolute requirement for a client, or that a client can
> > only use PLAIN authentication if it supports and agrees
> > to using TLS ?
>
> It means what it says.  If a client implements RFC4954, it must be able to
> do PLAIN over TLS; otherwise, it is nonconformant.  This requirement is
> necessary to insure interoperability, because some servers will not support
> anything other than PLAIN over TLS.
>
> > I suppose a lot of people have asked this question.
>
> Not on the ietf-sasl list, they haven't.  Of course, the question is really
> only indirectly related to SASL, so it's possible people have asked on
> other lists.
>
> > It is of
> > concern to me because small SMTP clients in embedded
> > environments often do not have sufficient resources to support TLS.
> > A strict interpretation of the section 4 language means support
> > for TLS is mandatory for all clients.
>
> That is the correct interpretation; TLS is mandatory for all
> implementattions of RFC4954.  See section 7 of RFC3365 for a partial
> explanation of why.
>
> It should be noted that nothing said by Simon, myself, or anyone else on
> this list should be interpreted as an official position of the IETF.  The
> positions of the IETF and its working groups are determined by rough
> consensus as determined by the appropriate leadership.  RFC4954 and RFC3365
> are examples of products of IETF consensus.
>
> -- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
>    Carnegie Mellon University - Pittsburgh, PA

--
Paul Romero

RCOM Communications Software

Phone/Fax: (510)339-2628
E-Mail: [email-masked]

Date: Thu, 26 Feb 2009 23:29:07 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Paul Romero <[email-masked]>, Simon Josefsson <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: TLS Requirement in SMTP RFC4954 and SASL
Sender: [email-masked]

--On Thursday, February 26, 2009 08:13:48 AM -0800 Paul Romero 
<[email-masked]> wrote:

>
> Hi Simon:
>
> I would like your interpretation of the section of  RFC 4954
> which applies to  using  PLAIN authentication over TLS.
> Section 4 contains the following statement on this subject:
>
> "To ensure interoperability, client and server implementations of
> this extension MUST implement the [PLAIN] SASL mechanism
> running over [TLS] [SMTP-TLS]."
>
> Does this mean that supporting both TLS and PLAIN is
> an absolute requirement for a client, or that a client can
> only use PLAIN authentication if it supports and agrees
> to using TLS ?

It means what it says.  If a client implements RFC4954, it must be able to 
do PLAIN over TLS; otherwise, it is nonconformant.  This requirement is 
necessary to insure interoperability, because some servers will not support 
anything other than PLAIN over TLS.

> I suppose a lot of people have asked this question.

Not on the ietf-sasl list, they haven't.  Of course, the question is really 
only indirectly related to SASL, so it's possible people have asked on 
other lists.

> It is of
> concern to me because small SMTP clients in embedded
> environments often do not have sufficient resources to support TLS.
> A strict interpretation of the section 4 language means support
> for TLS is mandatory for all clients.

That is the correct interpretation; TLS is mandatory for all 
implementattions of RFC4954.  See section 7 of RFC3365 for a partial 
explanation of why.

It should be noted that nothing said by Simon, myself, or anyone else on 
this list should be interpreted as an official position of the IETF.  The 
positions of the IETF and its working groups are determined by rough 
consensus as determined by the appropriate leadership.  RFC4954 and RFC3365 
are examples of products of IETF consensus.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Carnegie Mellon University - Pittsburgh, PA

Date: Thu, 26 Feb 2009 13:31:57 -0600
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Cc: Dave Cridland <[email-masked]>, [email-masked], Arnt Gulbrandsen <[email-masked]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Sender: [email-masked]

The GS2 headers contain:

c) the mechanism name;

Nico
-- 

Date: Thu, 26 Feb 2009 10:54:54 -0800 (PST)
From: [email-masked]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
To: Nicolas Williams <[email-masked]>
Cc: [email-masked], Dave Cridland <[email-masked]>, [email-masked], Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

				Ned

Date: Thu, 26 Feb 2009 08:13:48 -0800
From: Paul Romero <[email-masked]>
Organization: RCOM Communications Software
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: TLS Requirement in SMTP RFC4954 and SASL
Sender: [email-masked]

Hi Simon:

I would like your interpretation of the section of  RFC 4954
which applies to  using  PLAIN authentication over TLS.
Section 4 contains the following statement on this subject:

"To ensure interoperability, client and server implementations of
this extension MUST implement the [PLAIN] SASL mechanism
running over [TLS] [SMTP-TLS]."

Does this mean that supporting both TLS and PLAIN is
an absolute requirement for a client, or that a client can
only use PLAIN authentication if it supports and agrees
to using TLS ?

I suppose a lot of people have asked this question. It is of
concern to me because small SMTP clients in embedded
environments often do not have sufficient resources to support TLS.
A strict interpretation of the section 4 language means support
for TLS is mandatory for all clients.

Best Regards,

Paul R.

Simon Josefsson wrote:

> Paul Romero <[email-masked]> writes:
>
> > Hi Simon:
> >
> > What you wrote is consistent with what I have read
> > in the SASL group E-Mail and postings. I am not
> > sure my question about SASL RFCs was 100% clear.
> > The important part of the question is, what percentage
> > of SASL implementations follow the latest version of
> > the SASL RFC ?   Is that what you understood from
> > my previous E-Mail ?
>
> Hi again.  Ah, I didn't catch that: however the latest RFCs are
> backwards compatible, and I am not aware of any change introduced that
> would generate problems.  So I believe these new RFCs are just to update
> the specification documentation itself, not to change anything in
> implementation.
>
> Regards,
> Simon
>
> > Best Regards,
> >
> > Paul  R.
> >
> > Simon Josefsson wrote:
> >
> >> Paul Romero <[email-masked]> writes:
> >>
> >> > Hi Simon:
> >> >
> >> > I  would like your observations about the use of  DIGEST-MD5
> >> > in the commercial world within the SASL context.  Do you
> >> > think it is frequently used and gaining greater acceptance ?
> >> > Also, what percentage of commercial implementations do
> >> > you think conform the RFC 4616 and 4954 SASL ?
> >>
> >> Hi Paul.  PLAIN (RFC 4616) and smtp-auth (RFC 4954) are widely
> >> implemented and deployed, and I believe all major implementations are
> >> conforming to the standard.
> >>
> >> For DIGEST-MD5, the situation is a bit different though.  DIGEST-MD5 is
> >> not as widely implemented as for example CRAM-MD5 (see RFC 2195) and
> >> interop testing of various DIGEST-MD5 implementations have demonstrated
> >> many problems.  Briefly, the security layer features of DIGEST-MD5 do
> >> not interoperate well among existing implementations.  Thus, you would
> >> typically only use it for the authentication step.  DIGEST-MD5 is
> >> relatively common, though, but I believe practically all implementations
> >> that support DIGEST-MD5 also supports CRAM-MD5 unless there a local
> >> administrator has made a policy decision to disable CRAM-MD5.
> >>
> >> Within the SASL WG in the IETF, we are trying to develop a replacement
> >> for DIGEST-MD5 called SCRAM.  The protocol is not stable yet, and there
> >> are no implementations of it, however I do think it is the future.
> >>
> >> I would recommend you to support PLAIN and CRAM-MD5 and don't spend too
> >> much time on DIGEST-MD5 if you can avoid it.
> >>
> >> Hope this helps,
> >> /Simon
> >
> > --
> > Paul Romero
> >
> > RCOM Communications Software
> >
> > Phone/Fax: (510)339-2628
> > E-Mail: [email-masked]

--
Paul Romero

RCOM Communications Software

Phone/Fax: (510)339-2628
E-Mail: [email-masked]

Date: Tue, 24 Feb 2009 18:09:53 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Paul Romero <[email-masked]>
Subject: Re: SASL Requirements Specification
Cc: [email-masked]
Sender: [email-masked]

Paul Romero writes:
> Is there some document similar to a PICS  that states SASL conformance 
> requirements ?

No single document, I'm afraid.

> I am particularly interested in this question relative RFCs  4954 and
> 4422 which cover using SASL for SMTP authentication.

4954 says what you MUST do and what you also SHOULD do. When you read 
the MUSTs, you'll also come to MUSTs and SHOULDs in other documents, 
notably 4422 and 4616. Which documets are relevant is clear from the 
MUSTs and SHOULDs in 4954; they're all listed in the section 'normative 
references' in 4954.

  When you've finished recursively adding MUSTs and SHOULDs from the 
other documents, you have the conformance requirements.

Arnt

Date: Tue, 24 Feb 2009 08:30:56 -0800
From: Paul Romero <[email-masked]>
Organization: RCOM Communications Software
To: [email-masked]
Subject: SASL Requirements Specification
Sender: [email-masked]

Dear Group:

Is there some document similar to a PICS  that states
SASL conformance requirements ?  I am particularly
interested in this question relative RFCs  4954 and
4422 which cover using SASL for SMTP authentication.

Best Regards,

Paul Romero

--
Paul Romero

RCOM Communications Software

Phone/Fax: (510)339-2628
E-Mail: [email-masked]

Date: Mon, 23 Feb 2009 11:45:29 -0800 (PST)
From: [email-masked]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
To: Nicolas Williams <[email-masked]>
Cc: Dave Cridland <[email-masked]>, [email-masked], Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

				Ned

Date: Mon, 23 Feb 2009 16:02:52 -0600
From: Nicolas Williams <[email-masked]>
To: Dave Cridland <[email-masked]>
Cc: [email-masked], Arnt Gulbrandsen <[email-masked]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Sender: [email-masked]

Nico
-- 

Date: Mon, 23 Feb 2009 15:54:53 -0600
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Sender: [email-masked]

The updated ABNF, then:

; Basic types

Date: Mon, 23 Feb 2009 15:21:33 -0600
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Cc: Dave Cridland <[email-masked]>, [email-masked], Arnt Gulbrandsen <[email-masked]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Sender: [email-masked]

      S: R 0x00001000 ni;
         ^ ^^^^^^^^^^ ^^^
	 |     |      |

Comments?

Nico
-- 

Date: Mon, 23 Feb 2009 15:02:17 -0600
From: Nicolas Williams <[email-masked]>
To: Dave Cridland <[email-masked]>
Cc: [email-masked], Arnt Gulbrandsen <[email-masked]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Sender: [email-masked]

Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Date: Mon, 23 Feb 2009 19:56:15 +0000
From: Dave Cridland <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

Dave.

Date: Mon, 23 Feb 2009 12:50:55 -0600
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Sender: [email-masked]

 - ABNF

; Basic types

      S: R 0x00001000 ni
         ^ ^^^^^^^^^^ ^^
	 |     |      |

Comments?

Nico
-- 

Date: Mon, 23 Feb 2009 11:20:20 -0600
From: Nicolas Williams <[email-masked]>
To: Dave Cridland <[email-masked]>
Cc: [email-masked], Arnt Gulbrandsen <[email-masked]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Sender: [email-masked]

Nico
-- 

Date: Mon, 23 Feb 2009 10:51:24 -0600
From: Nicolas Williams <[email-masked]>
To: Dave Cridland <[email-masked]>
Cc: [email-masked], Arnt Gulbrandsen <[email-masked]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Sender: [email-masked]

Nico
-- 

Subject: Re: [Fwd: I-D Action:draft-newman-auth-scram-10.txt]
From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= <[email-masked]>
Cc: SASL WG <[email-masked]>, [email-masked]
Date: Mon, 23 Feb 2009 08:59:44 -0800
To: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

>>>     This is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF   
>>> and
>>>     with dkLen == output length of HMAC() == output length of H().
>>
>> If it is PBKDF2 is should say so and not be fuzzy.
>
> If somebody can verify that independently, then I will change the  
> text ;-).

Just write that it uses PBKDF2 with HMAC and output keysize = sizeof(H 
(), put the description in an non normative appendix.

It looks like PBKDF2 to me.

>> When I see Hi(str, salt), I get confused every time, i is an input
>> parameter, but is still part of the function name ?
>
> Yea. It Should be <Something>(str, salt, i)
>
>> Why is ClientProof  the result of ClientKey XOR ClientSignature ?
>> That  does that accomplish ?
>
> The server is able to calculate ClientSignature. From the ClientProof
> and that it can recover ClientKey, apply hash function once to get
> StoredKey and can verify that the client really knows the StoredKey
> (i.e. it knows the password).

If the client can calculate ClientSignature = HMAC(H(H(PBKDF2 
(password, salt, i))), AuthMessage),
I would not be worried about it not knowing the password, why do you  
need the extra step ?

Chris, this was in -00 of the draft, why did you do it this way ?

Right now the client and server key differences is:

ClientKey = H(SaltedPassword)
ServerKey = HMAC(SaltedPassword, salt)

Why are the derived by two different methods ? (why not XKey = HMAC 
(SaltedKey, "X key")

Love

Date: Mon, 23 Feb 2009 11:03:55 +0000
From: Alexey Melnikov <[email-masked]>
To: =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: [Fwd: I-D Action:draft-newman-auth-scram-10.txt]
Sender: [email-masked]

Love H=F6rnquist =C5strand wrote:

> 22 feb 2009 kl. 02:47 skrev Alexey Melnikov:
>
>> This contains some minor fixes discovered by Dave Cridland and myself
>> while implementing the spec (actually 2 separate implementations, =20
>> one in
>> C and one in Python), in particular an error in ABNF production name
>
> The draft says:
>
> >      This is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF  and
> >      with dkLen =3D=3D output length of HMAC() =3D=3D output length of H=
().
>
> If it is PBKDF2 is should say so and not be fuzzy.

If somebody can verify that independently, then I will change the text ;-).

> When I see Hi(str, salt), I get confused every time, i is an input =20
> parameter, but is still part of the function name ?

Yea. It Should be <Something>(str, salt, i)

> Why is ClientProof  the result of ClientKey XOR ClientSignature ?=20
> That  does that accomplish ?

The server is able to calculate ClientSignature. From the ClientProof=20
and that it can recover ClientKey, apply hash function once to get=20
StoredKey and can verify that the client really knows the StoredKey=20
(i.e. it knows the password).

Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Date: Mon, 23 Feb 2009 10:40:05 +0000
From: Dave Cridland <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

Dave.

Subject: Re: [Fwd: I-D Action:draft-newman-auth-scram-10.txt]
From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= <[email-masked]>
Cc: SASL WG <[email-masked]>
Date: Sun, 22 Feb 2009 16:59:27 -0800
To: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

22 feb 2009 kl. 02:47 skrev Alexey Melnikov:

> This contains some minor fixes discovered by Dave Cridland and myself
> while implementing the spec (actually 2 separate implementations,  
> one in
> C and one in Python), in particular an error in ABNF production name

The draft says:

 >      This is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF  
and
 >      with dkLen == output length of HMAC() == output length of H().

If it is PBKDF2 is should say so and not be fuzzy.

When I see Hi(str, salt), I get confused every time, i is an input  
parameter, but is still part of the function name ?

Why is ClientProof  the result of ClientKey XOR ClientSignature ? That  
does that accomplish ?

Love

Date: Sun, 22 Feb 2009 15:15:23 -0600
From: Nicolas Williams <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: SASL WG <[email-masked]>, Dave Cridland <[email-masked]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Sender: [email-masked]

Date: Sun, 22 Feb 2009 21:30:37 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: SASL WG <[email-masked]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Cc: Nicolas Williams <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Arnt

Date: Sun, 22 Feb 2009 10:47:30 +0000
From: Alexey Melnikov <[email-masked]>
To: SASL WG <[email-masked]>
Subject: [Fwd: I-D Action:draft-newman-auth-scram-10.txt]
Sender: [email-masked]

--------------000504070106020507050202
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

This contains some minor fixes discovered by Dave Cridland and myself 
while implementing the spec (actually 2 separate implementations, one in 
C and one in Python), in particular an error in ABNF production name.

--------------000504070106020507050202
Content-Type: message/rfc822;
 name="I-D Action:draft-newman-auth-scram-10.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="I-D Action:draft-newman-auth-scram-10.txt"

From: [email-masked]
To: [email-masked]
Subject: I-D Action:draft-newman-auth-scram-10.txt 
Date: Sun, 22 Feb 2009 02:45:01 -0800 (PST)
Reply-To: [email-masked]
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Salted Challenge Response (SCRAM) SASL Mechanism
	Author(s)       : A. Menon-Sen, et al.
	Filename        : draft-newman-auth-scram-10.txt
	Pages           : 18
	Date            : 2009-02-22

The secure authentication mechanism most widely deployed and used by
 Internet application protocols is the transmission of clear-text
 passwords over a channel protected by Transport Layer Security
 (TLS).  There are some significant security concerns with that
 mechanism, which could be addressed by the use of a challenge
 response authentication mechanism protected by TLS. Unfortunately,
 the challenge response mechanisms presently on the standards track
 all fail to meet requirements necessary for widespread deployment,
 and have had success only in limited use.

 This specification describes a family of authentication mechanisms
 called the Salted Challenge Response Authentication Mechanism
 (SCRAM), which addresses the security concerns and meets the
 deployability requirements. When used in combination with TLS or an
 equivalent security layer, a mechanism from this family could
 improve the status-quo for application protocol authentication and
 provide a suitable choice for a mandatory-to-implement mechanism for
 future application protocol standards.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-newman-auth-scram-10.txt

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

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

--NextPart
Content-Type: Message/External-body;
	name="draft-newman-auth-scram-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--NextPart--

--------------000504070106020507050202--

Date: Sat, 21 Feb 2009 14:23:33 -0600
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Sender: [email-masked]

Nico
-- 

Date: Sat, 21 Feb 2009 12:40:22 -0600
From: Nicolas Williams <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Sender: [email-masked]

Nico
-- 

Date: Sat, 21 Feb 2009 15:45:16 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Sender: [email-masked]

Arnt

Date: Fri, 20 Feb 2009 18:06:47 -0600
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Subject: New GS2 design -- much simplified, and simplified SCRAM
Sender: [email-masked]

Brief outline:

Cheers,

Nico
-- 

Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Fri, 20 Feb 2009 10:17:35 +0000
From: Dave Cridland <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>, Chris Newman <[email-masked]>
Sender: [email-masked]

On Thu Feb 19 16:02:18 2009, [email-masked] wrote:
> The real risk is that an overly complex mechanism will not deploy,  
> or if it
> does deploy, will fail to interoperate. We're coming to the party  
> very, very
> late with this, and even if we end up with as simple a mechanism as  
> we possibly
> can there's still a significant risk this whole thing is going to  
> go exactly
> nowhere.

I'd go so far as to say that actual complexity isn't as important for  
the purposes of deployment as perceived complexity. This ceased to be  
a technical issue some time ago (although there are minor technical  
issues). This is really just a marketing issue, and one that's  
important to address if we want deployment.

Unfortunately, I suspect most of this boils down to the name.

>> If I understand Nico's proposal on 2/17 correctly, it could  
>> simplify the
>> difference between auth-scram-09 and auth-scram-gs2 to just a blob  
>> at the
>> beginning of the first client message.  If it's possible to do  
>> that, then I
>> would support doing so.
> 
> Frankly, this is what I was expecting to see in the current set of  
> drafts - the
> idea of reducing GS2 to an opaque blob has been mentioned many  
> times in the
> past. What I found instead was a significantly more complex  
> alternative.

I'd question whether the average developer is going to go as far as  
finding and reading the specification if the mechanism name is itself  
encrypted. This might sound flippant, and frankly it's hard not to  
make it sound that way, but it's a serious point - deployment isn't  
only about technical merit.

In any case, the key attraction for many operators isn't going to be  
that GSS-API and SASL share the mechanism, but that PLAIN and SCRAM  
can share a secure authentication database. If there's another  
mechanism, GSS-API based, that also shares this backend database,  
that'll no doubt please people who're offering GSS-API services  
alongside SASL services, but I honestly can't see that having wire  
compatibility is all that important by comparison.

Sure, it's a "nice if you can get it", but it ranks far, far below  
the shared authentication backend, which itself means that  
SCRAM-capable services can be deployed right now.

Right now, operators have to choose between storing plaintext  
passwords or require transmitting them, and when forced to choose,  
they appear to go for the latter. With SCRAM, they can deploy a  
SCRAM-style authentication database right now - it's probably very  
close to what they're already using in /etc/shadow or their  
hashed-passwords DSA - they can use it for PLAIN for existing  
clients, and offer SCRAM, and client developers will see SCRAM  
advertised, and implement it because it's simple enough.

So, my conclusion from this is actually very positive - we can have a  
native SASL SCRAM-HMAC-* family, a backend-compatible GSS-API SCRAM  
family, a document describing how to make PLAIN (and XEP-0078, IMAP  
LOGIN, X.509 Simple Authentication, POP3 USER/PASS, FTP, /bin/login  
etc) authenticate against the same backend, and actually have real  
deployment in services now.

On the other hand, if we choose a solution that appears more complex,  
I'm concerned that the result will be that we never get the momentum.

Dave.

Date: Fri, 20 Feb 2009 10:17:02 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: Chris Newman <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> But then I think GSS-API implementors would need to see the other 
>> half of the ABNF...
>
> That's acceptable. Optimising for the common case implies that unusual 
> cases don't have to be optimal.

If you suggesting something like moving the full ABNF to Appendix (and 
keeping the expanded one in the main body of the document), then this 
can be done.

Date: Fri, 20 Feb 2009 11:07:59 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Cc: Chris Newman <[email-masked]>, SASL WG <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> But then I think GSS-API implementors would need to see the other half 
> of the ABNF...

That's acceptable. Optimising for the common case implies that unusual 
cases don't have to be optimal.

Arnt

Date: Thu, 19 Feb 2009 22:17:30 +0000
From: Alexey Melnikov <[email-masked]>
To: Chris Newman <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

Chris Newman wrote:

> The present formulation of auth-scram-gs2-00 is significantly more 
> complex than auth-scram-09 (ABNF is roughly twice the size).

I will just quickly comment on this: the ABNF is twice the size in order 
to keep GS2 bits separate from SCRAM bits. I could have expanded it for 
SASL implementors. But then I think GSS-API implementors would need to 
see the other half of the ABNF...

Date: Thu, 19 Feb 2009 18:01:03 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

[email-masked] writes:
> I'm cautiously on board if it can be simplified to the point of being 
> a fixed prefix "blob" per your description below. Anything short of 
> that is still unacceptable IMO.

I'll cautiously +1 that.

> The real risk is that an overly complex mechanism will not deploy, or 
> if it does deploy, will fail to interoperate. We're coming to the 
> party very, very late with this, and even if we end up with as simple 
> a mechanism as we possibly can there's still a significant risk this 
> whole thing is going to go exactly nowhere.

Amen. And even just adding theoretically harmless things such as a 
binary blob or an OID can be risky if it makes people think "oh, it'll 
be horrid like SNMP" instead of looking closer.

Arnt

Date: Thu, 19 Feb 2009 08:02:18 -0800 (PST)
From: [email-masked]
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
To: Chris Newman <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Sender: [email-masked]

> I have evaluated both specifications in detail and reviewed the list
> traffic.

> Brief conclusions:

> Given a choice between these two approaches I oppose auth-scram-gs2-00.txt
> and support auth-scram-09.txt.

> However, I believe the WG should evaluate the proposal Nico made on 2/17.
> The crux of that proposal is to change GS2 to remove support for SASL
> security layers and remove use of the GSS_Wrap function (which adds the
> unnecessary hash operation).  Doing so is likely to simplify auth-scram-gs2
> to the point where I would be comfortable with that approach.

I'm cautiously on board if it can be simplified to the point of being a fixed
prefix "blob" per your description below. Anything short of that is still
unacceptable IMO.

> Technical basis for my position:

> I recognize some benefit from having a GSSAPI implementation of SCRAM
> visible through a GS2 SASL mechanism interoperate with a pure SASL SCRAM
> implementation.  However, if there were separate GSSAPI SCRAM and SASL
> SCRAM mechanisms, I believe implementers would make them interoperate when
> it was important to do so, just as some SASL implementers have supported
> non-standard SASL mechanisms like LOGIN, GSS-SPNEGO, and NTLM.  So I
> consider that benefit to be "modest".

> The present formulation of auth-scram-gs2-00 is significantly more complex
> than auth-scram-09 (ABNF is roughly twice the size).  This additional
> complexity provides no _functionality_ improvements over scram-08 but
> requires additional hash-function computation and verification, extra
> binary encoding, and additional escaping.  The additional hash-function
> computation, in particular, has a non-obvious function and the mechanism
> would appear to work fine in most cases (succeeding with valid password,
> failing with invalid password) if an implementer simply chose not to verify
> the additional hash.  That creates a new opportunity for a security
> vulnerability in auth-scram-gs2 that does not exist in auth-scram.  That's
> over and above the additional security vulnerably risk from the necessarily
> larger code quantity.  So I consider the interop benefit to be outweighed
> by the security risk.

The real risk is that an overly complex mechanism will not deploy, or if it
does deploy, will fail to interoperate. We're coming to the party very, very
late with this, and even if we end up with as simple a mechanism as we possibly
can there's still a significant risk this whole thing is going to go exactly
nowhere.

> Further, I consider the need to have SCRAM supplant CRAM and DIGEST a
> higher priority than making SCRAM compatible with GS2.  The overall
> additional complexity of auth-scram-gs2-00 puts that primary goal in
> significant jeopardy to achieve what I consider a secondary goal.  That
> tradeoff is not acceptable to me.

> If I understand Nico's proposal on 2/17 correctly, it could simplify the
> difference between auth-scram-09 and auth-scram-gs2 to just a blob at the
> beginning of the first client message.  If it's possible to do that, then I
> would support doing so.

Frankly, this is what I was expecting to see in the current set of drafts - the
idea of reducing GS2 to an opaque blob has been mentioned many times in the
past. What I found instead was a significantly more complex alternative.

				Ned

Date: Thu, 19 Feb 2009 09:50:22 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Nicolas Williams <[email-masked]>, SASL WG <[email-masked]>, [email-masked]
Subject: Re: Or: simplifying GS2 (Re: Poll: pure SCRAM versa SCRAM-as-GS2)
Sender: [email-masked]

--On Thursday, February 19, 2009 12:03:53 PM +0000 Alexey Melnikov 
<[email-masked]> wrote:

> Jeffrey Hutzelman wrote:
>
>> --On Tuesday, February 17, 2009 04:44:16 PM -0600 Nicolas Williams
>>> So what makes GS2 not simple?  The fact that we chose to make the GS2
>>> channel binding semantics different from the GSS-API's: we chose to make
>>> channel binding success/failure affect the negotiation of security
>>> layers.
>>>
>>> If we reconsider that one choice we could simplify GS2 enough that a
>>> single specification of SCRAM-as-a-GSS-API mechanism will satisfy all.
>>
>> Personally, I'm fine with saying that channel binding must succeed if
>> the application provided bindings.
>
> What should happen if the other end can't verify them, because it has no
> API for doing that?

The purist in me says "get a better TLS implementation".

The part of me that backports security fixes to OpenSSL 0.9.7 because 
upgrading would be more pain than I have time for recognizes that that is 
probably still impractical.

> So, I am Ok with the following semantics: if a channel bind is provided
> by one end and can be verified by the other end, then any failure to
> verify it causes authentication failure, but if the other end doesn't
> have the ability to verify channel bindings, then ignoring them is fine.

I would be OK with that, too, provided we're talking about the behavior 
depending on whether or not the application passed channel binding 
information down through SASL.  Thus, the question of whether to use 
channel bindings remains with the application, and individual applications 
can either require that channel bindings be used all the time or allow them 
to be skipped under some circumstances.

Unfortunately, this doesn't actually work in both directions.  A GSS-API 
acceptor can decide whether to pass channel binding information down to the 
mechanism, but it must make that decision before it has any way of knowing 
whether the initiator sent any.  If the initiator provides channel bindings 
but the acceptor does not, then the context might be established 
successfully, depending in part on the mechanism and possibly on the 
particular mechanism implementation.  If the acceptor provides channel 
bindings and the initiator does not, context establishment will fail.

What Nico is trying to do is propose that we simplify GS2 significantly by 
declaring that its channel binding failure semantics are exactly the same 
as those of GSS-API.  This allows GS2 channel bindings to be provided using 
those of the underlying GSS-API mechanism, rather than as a separate GSS 
MIC token which, depending on the mechanism, may require an extra round 
trip.  It simplifies things considerably by making GS2 into a much thinner 
wrapper.

I cannot think of any way to provide the semantics you describe (in which 
channel binding must succeed, but only if both ends provide data) for all 
GS2 mechanisms without retaining the complexity Nico is trying to remove. 
However, I think we _can_ provide that behavior for SCRAM, or for any other 
particular GSS-API mechanism, by specifying that the mechanism verifies 
channel bindings only if data is provided by both ends.  Whether we 
_should_ do that is another question entirely.

Excuse me for a moment while I delve a bit deeper into GSS-API specifics...

It seems to me that we could define a mechanism property which indicates 
that the mechanism handles channel bindings as described above, verifying 
them only when provided by both initiator and acceptor.  SCRAM would have 
this feature, and GS2 would be defined to make use of the feature when it 
is available (as determined by extended mechanism inquiry), and implement 
GS2 channel bindings in terms of GSS MIC tokens when it is not.  This would 
have the effect of keeping GS2+SCRAM simple while allowing GS2+RFC4121 to 
have the desired channel binding semantics even though Kerberos does not.

Possibly, we'd want to invent a new acceptor API, to allow an acceptor to 
indicate whether it wants to use this functionality or not.  I'd prefer to 
avoid this, because it would delay both GS2 and SCRAM, since they would 
notionally actually have to use the new interface (it wouldn't delay 
_implementaton_ of pure-SASL SCRAM, though).

>> Does anyone recall the use case for allowing CB to fail and falling
>> back to a security layer even in the presence of a channel?
>
> I can see a marginal advantage of falling back to a security layer in
> such case, but it might be just simpler to either ignore channel bindings
> and not have a security layer, or to always negotiate a security layer
> irrespective of providing channel bindings.

Yeah, I think the question of whether to negotiate a security layer ought 
to be independent of whether channel bindings succeed.  IMHO the simplest 
way to do this is to declare that neither GS2 nor SCRAM provides security 
layers, and that SASL applications ought to use TLS (or some other 
appropriate channel) and channel bindings.

-- Jeff

Date: Thu, 19 Feb 2009 12:03:53 +0000
From: Alexey Melnikov <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
CC: Nicolas Williams <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Or: simplifying GS2 (Re: Poll: pure SCRAM versa SCRAM-as-GS2)
Sender: [email-masked]

Jeffrey Hutzelman wrote:

> --On Tuesday, February 17, 2009 04:44:16 PM -0600 Nicolas Williams 
>> So what makes GS2 not simple?  The fact that we chose to make the GS2
>> channel binding semantics different from the GSS-API's: we chose to make
>> channel binding success/failure affect the negotiation of security
>> layers.
>>
>> If we reconsider that one choice we could simplify GS2 enough that a
>> single specification of SCRAM-as-a-GSS-API mechanism will satisfy all.
>
> Personally, I'm fine with saying that channel binding must succeed if 
> the application provided bindings.

What should happen if the other end can't verify them, because it has no 
API for doing that?
I think this is going to be a very real problem in short to medium term, 
because TLS APIs suck (or undocumented, which is close to being the same 
thing).

So, I am Ok with the following semantics: if a channel bind is provided 
by one end and can be verified by the other end, then any failure to 
verify it causes authentication failure, but if the other end doesn't 
have the ability to verify channel bindings, then ignoring them is fine.

> Does anyone recall the use case for allowing CB to fail and falling 
> back to a security layer even in the presence of a channel?

I can see a marginal advantage of falling back to a security layer in 
such case, but it might be just simpler to either ignore channel 
bindings and not have a security layer, or to always negotiate a 
security layer irrespective of providing channel bindings.

Date: Thu, 19 Feb 2009 11:49:34 +0000
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: Or: simplifying GS2 (Re: Poll: pure SCRAM versa SCRAM-as-GS2)
Sender: [email-masked]

Nicolas Williams wrote:

>Perhaps we can just simplify GS2 enough that all concerns go away.
>
>The primary differences between the GSS-API and SASL:
>
>a) one is message-oriented (GSS), the other is stream-oriented (SASL);
>
>b) SASL client apps must send the name of the mech being used before
>   using it, while the GSS-API includes the "name" of the selected mech
>   in the first authentication message;
>
This might be a minor detail, but if understand correctly, GSS-API is 
using OIDs for naming, while SASL typically doesn't.

>c) SASL authentication message exchanges negotiate what security layers
>   will be used and maximum message sizes; the GSS-API does no such
>   negotiations;
>
>d) the GSS-API has channel binding, but it's all or nothing, and it's
>   optional; SASL has never had channel binding.
>
>e) terminology :)
>
>(a) is easy to address in a SASL/GSS bridge.
>(b) is easy to address in a SASL/GSS bridge.
>
I am not entirely sure what you call "bridge" in this case, but I tend 
to agree with your conclusion ;-).

>(c) is easy to addres by replacing security layers with channel binding
>    to TLS,
>
As a side note: we shouldn't be requiring TLS to be the only channel 
binding, even though we can recommend it.

>which has the added advantage of simplifying mechanisms and
>    making (a) not matter.
>  
>
Agreed.
I think draft-newman-auth-scram-gs2-00.txt already made the same choice.

>(d) matters only if we want channel binding in SASL, and I think we long
>    ago agreed we did, and if we re-open that question I believe we'll
>    again conclude that we want it.
>  
>
Agreed.

>(e) we can ignore :)
I think this is mostly an editorial issue, which might require quite a 
bit of work.
But I agree it should be ignored for now.

>So what makes GS2 not simple?  The fact that we chose to make the GS2
>channel binding semantics different from the GSS-API's: we chose to make
>channel binding success/failure affect the negotiation of security
>layers.
>
>If we reconsider that one choice we could simplify GS2 enough that a
>single specification of SCRAM-as-a-GSS-API mechanism will satisfy all.
>
I agree that would make GS2 simpler, but I am not convinced that that 
would be enough to make SCRAM-as-GS2 satisfy Chris Newman's requirement 
on simplicity. But anyway, I am willing to participate and see what the 
result would be.

I think the extra complexity lies is the need to have authorization 
identity separate from the rest of SCRAM data (because it is transported 
by GS2 itself), this requires an extra hash for protecting it. The same 
applies to the channel binding data, but your proposal above addresses 
this to some extend.

Date: Wed, 18 Feb 2009 20:35:36 -0800 (PST)
From: Lyndon Nerenberg <[email-masked]>
To: [email-masked]
Subject: A dignified burial for CRAM-MD5
Organization: The Frobozz Magic Homing Pigeon Company
Sender: [email-masked]

Folks, it has been nearly a decade since the first move towards re-stating 
CRAM-MD5 as a SASL mechanism. It's obvious now that this will never 
happen.

It's also obvious that CRAM-MD5 has entrenched itself to the point where 
it's not going to go away any time soon (or late for that matter).

The global base of interoperable deployments says we don't need to 
issue a formal update to the specification. Frankly, anything that fits 
inside two pages of text and works this well deserves to be left well 
enough alone.

Since the SASL WG can't come to an agreement about the status of CRAM-MD5 
-- other than it's adamantly opposed to its moving forward on the 
standards track -- I think it's time for the WG to drop CRAM-MD5 from the 
work list. It's currently not a formal SASL mechanism, so abandonment by 
the WG is a valid solution.

This would leave RFC2195 in its present state, validating the existing 
CRAM-MD5 deployments. Beside that, I'm proposing to put together a new 
Informational RFC that documents the WGs concerns about the mechanism, and 
addresses the interoperability issues. (Kurt's draft has done much of this 
work already.)

--lyndon

Date: Wed, 18 Feb 2009 16:26:19 -0800
From: Chris Newman <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
To: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Sender: [email-masked]

I have evaluated both specifications in detail and reviewed the list 
traffic.

Brief conclusions:

Given a choice between these two approaches I oppose auth-scram-gs2-00.txt 
and support auth-scram-09.txt.

However, I believe the WG should evaluate the proposal Nico made on 2/17. 
The crux of that proposal is to change GS2 to remove support for SASL 
security layers and remove use of the GSS_Wrap function (which adds the 
unnecessary hash operation).  Doing so is likely to simplify auth-scram-gs2 
to the point where I would be comfortable with that approach.

Technical basis for my position:

I recognize some benefit from having a GSSAPI implementation of SCRAM 
visible through a GS2 SASL mechanism interoperate with a pure SASL SCRAM 
implementation.  However, if there were separate GSSAPI SCRAM and SASL 
SCRAM mechanisms, I believe implementers would make them interoperate when 
it was important to do so, just as some SASL implementers have supported 
non-standard SASL mechanisms like LOGIN, GSS-SPNEGO, and NTLM.  So I 
consider that benefit to be "modest".

The present formulation of auth-scram-gs2-00 is significantly more complex 
than auth-scram-09 (ABNF is roughly twice the size).  This additional 
complexity provides no _functionality_ improvements over scram-08 but 
requires additional hash-function computation and verification, extra 
binary encoding, and additional escaping.  The additional hash-function 
computation, in particular, has a non-obvious function and the mechanism 
would appear to work fine in most cases (succeeding with valid password, 
failing with invalid password) if an implementer simply chose not to verify 
the additional hash.  That creates a new opportunity for a security 
vulnerability in auth-scram-gs2 that does not exist in auth-scram.  That's 
over and above the additional security vulnerably risk from the necessarily 
larger code quantity.  So I consider the interop benefit to be outweighed 
by the security risk.

Further, I consider the need to have SCRAM supplant CRAM and DIGEST a 
higher priority than making SCRAM compatible with GS2.  The overall 
additional complexity of auth-scram-gs2-00 puts that primary goal in 
significant jeopardy to achieve what I consider a secondary goal.  That 
tradeoff is not acceptable to me.

If I understand Nico's proposal on 2/17 correctly, it could simplify the 
difference between auth-scram-09 and auth-scram-gs2 to just a blob at the 
beginning of the first client message.  If it's possible to do that, then I 
would support doing so.

		- Chris

--On February 5, 2009 21:14:04 +0000 Alexey Melnikov 
<[email-masked]> wrote:

>
> Folks,
> I would like to solicit feedback from people regarding the choice between
> 2 SCRAM versions:
>  http://tools.ietf.org/id/draft-newman-auth-scram-08.txt
> and
>  http://tools.ietf.org/id/draft-newman-auth-scram-gs2-00.txt
>
> You can use the following URL to see changes between them:
> http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-newman
> -auth-scram-08.txt&url2=http://tools.ietf.org/id/draft-newman-auth-scram-
> gs2-00.txt
>
> Please send your opinion on which version you prefer (and a short
> explanation of why) to the mailing list, or say if you need more
> information.
>
> I would like to get all answers before February 19th, please.

Date: Wed, 18 Feb 2009 16:17:52 -0600
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Kurt Zeilenga <[email-masked]>, Alexey Melnikov <[email-masked]>, Hallvard B Furuseth <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Or: simplifying GS2 (Re: Poll: pure SCRAM versa SCRAM-as-GS2)
Sender: [email-masked]

On Wed, Feb 18, 2009 at 05:17:19PM -0500, Jeffrey Hutzelman wrote:
> --On Tuesday, February 17, 2009 04:44:16 PM -0600 Nicolas Williams 
> >(c) is easy to addres by replacing security layers with channel binding
> >    to TLS, which has the added advantage of simplifying mechanisms and
> >    making (a) not matter.
> 
> I'm certainly willing to do this.

Me too, as is Chris Newman (I checked with him off-line).

> 
> >So what makes GS2 not simple?  The fact that we chose to make the GS2
> >channel binding semantics different from the GSS-API's: we chose to make
> >channel binding success/failure affect the negotiation of security
> >layers.
> >
> >If we reconsider that one choice we could simplify GS2 enough that a
> >single specification of SCRAM-as-a-GSS-API mechanism will satisfy all.
> 
> Personally, I'm fine with saying that channel binding must succeed if the 
> application provided bindings.  Does anyone recall the use case for 
> allowing CB to fail and falling back to a security layer even in the 
> presence of a channel?

I don't recall, but it'd sure simplify everything.

Nico
-- 

Date: Wed, 18 Feb 2009 22:32:43 +0000
From: Alexey Melnikov <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
CC: Hallvard B Furuseth <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

Jeffrey Hutzelman wrote:

> --On Monday, February 16, 2009 07:33:27 PM +0000 Alexey Melnikov 
> <[email-masked]> wrote:
>
>> Hallvard B Furuseth wrote:
>>
>>> Kurt Zeilenga writes:
>>>
>>> One reality check: I have no idea what kind of SASL implementations are
>>> out there.  Are there implementations that do not support GS2/GSS?
>>
>> I can't only talk for one implementation: CMU SASL doesn't provide
>> GSS-API interface, it is a pure SASL implementation.
>
> Huh?  Cyrus SASL definitely does support the "GSSAPI" mechanism; it is 
> implemented in terms of the GSS-API (that is, it is not a "pure SASL" 
> implementation in the sense we've been talking about for SCRAM).
>
> What it is not is an implementation of Kerberos or the GSS-API.

This is exactly what I said: Cyrus SASL consumes GSS-API, but doesn't 
provide one.

Date: Wed, 18 Feb 2009 17:17:19 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>, Kurt Zeilenga <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, Hallvard B Furuseth <[email-masked]>, SASL WG <[email-masked]>, [email-masked]
Subject: Re: Or: simplifying GS2 (Re: Poll: pure SCRAM versa SCRAM-as-GS2)
Sender: [email-masked]

--On Tuesday, February 17, 2009 04:44:16 PM -0600 Nicolas Williams 
<[email-masked]> wrote:

> (c) is easy to addres by replacing security layers with channel binding
>     to TLS, which has the added advantage of simplifying mechanisms and
>     making (a) not matter.

I'm certainly willing to do this.

> So what makes GS2 not simple?  The fact that we chose to make the GS2
> channel binding semantics different from the GSS-API's: we chose to make
> channel binding success/failure affect the negotiation of security
> layers.
>
> If we reconsider that one choice we could simplify GS2 enough that a
> single specification of SCRAM-as-a-GSS-API mechanism will satisfy all.

Personally, I'm fine with saying that channel binding must succeed if the 
application provided bindings.  Does anyone recall the use case for 
allowing CB to fail and falling back to a security layer even in the 
presence of a channel?

-- Jeff

Date: Wed, 18 Feb 2009 17:00:44 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Hallvard B Furuseth <[email-masked]>
cc: SASL WG <[email-masked]>, [email-masked]
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

--On Monday, February 16, 2009 07:33:27 PM +0000 Alexey Melnikov 
<[email-masked]> wrote:

>
> Hallvard B Furuseth wrote:
>
>> Kurt Zeilenga writes:
>>
>>
>> One reality check: I have no idea what kind of SASL implementations are
>> out there.  Are there implementations that do not support GS2/GSS?
>>
> I can't only talk for one implementation: CMU SASL doesn't provide
> GSS-API interface, it is a pure SASL implementation.

Huh?  Cyrus SASL definitely does support the "GSSAPI" mechanism; it is 
implemented in terms of the GSS-API (that is, it is not a "pure SASL" 
implementation in the sense we've been talking about for SCRAM).

What it is not is an implementation of Kerberos or the GSS-API.

-- Jeff

Date: Wed, 18 Feb 2009 16:27:35 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>, Simon Josefsson <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>, [email-masked]
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

--On Thursday, February 12, 2009 08:22:45 AM -0600 Nicolas Williams 
<[email-masked]> wrote:

>
> On Thu, Feb 12, 2009 at 11:23:37AM +0100, Simon Josefsson wrote:
>> Nicolas Williams <[email-masked]> writes:
>> > I don't see the point.  If we drop SCRAM-as-GS2 then GS2 will be useful
>> > only for the krb5 mech, and will likely never be used again: the
>> > precedent will be clear that no one will care to build mechanisms for
>> > one framework and then have then automatically available for the other,
>> > thus it will never be done for any other mechanisms.
>>
>> I'm less convinced of that.  I want to see a password-based GSS-API
>> mechanism, which would be possible to use in SASL via GS2, so there will
>> be at least one.  I agree pure-SASL-SCRAM would set a precedent, but I
>> don't think it will prevent future work towards merging the GSS-API and
>> SASL frameworks.
>
> Why have multiple equivalent password-based mechanisms for SASL?
>
> No, if SCRAM-as-not-GS2 happens then it'd be a safe bet that GS2 will
> only ever be used for Kerberos V.

I don't think that's true.  The certainly will be a SCRAM-like GSS 
mechanism.  Such a mechanism will work with GS2, and I'm sure there will be 
people who will deploy it, if only because they want to consistently use 
GSS-SCRAM everywhere they can.  I also expect that GS2 will be used with 
PKU2U, as there currently is no public key SASL mechanism.

I don't think the unwillingness of the SASL community to develop dual-stack 
mechanisms for which SASL-foo and GS2+GSS-foo interoperate means that we 
should be unwilling to develop GSS-API mechanisms and use them with GS2.

-- Jeff

Date: Wed, 18 Feb 2009 16:23:35 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>, [email-masked]
cc: [email-masked]
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

Forgive me if this has already been addressed in the intervening weeks, but 
you seem to be laboring under some rather serious misconceptions here, and 
it is important that they be straightened out...

--On Sunday, February 08, 2009 05:17:25 PM -0800 Lyndon Nerenberg 
<[email-masked]> wrote:

> It seems to me that the SASL WG is hell bent upon adding as much
> complexity as they can to everything they touch. Good security demands
> the absolute greatest amount of simplicity as can be attained while
> fulfilling the desired level of protection. This endless stacking of
> layer upon layer of protocol API serves only to add complexity to
> something that needs to be as simple and understandable as possible. If a
> human cannot parse and understand the protocol specification, there isn't
> a hope in hell they will be able to write a secure implementation.

Misconception #1: There is endless stacking of protocol API's.

We are not designing protocol API's; we're designing protocols.  The design 
of SASL and its mechanisms does not dictate a particular API or a 
particular architecture.  It does not dictate that an implementation have 
the same layers of abstraction that the protocol does, and there are 
apparently any number of single-application, single-mechanism SASL 
implementations.

Misconception #2: Layering adds complexity and makes things harder to 
understand and harder to implement correctly.

On the contrary, layering is what makes it possible to understand and 
implement this stuff reasonably _at all_.  Imagine what the world would be 
like if your email application had to implement not only the email 
protocol, but also authentication, crypto, reliable transport, discovery of 
the server address, route selection, and preparation and transmission of 
packets onto the wire.  Don't laugh; things actually used to work that way.

More directly relevant, layering and abstraction make it _easier_, not 
harder, to understand and analyze the security properties of the protocol, 
by allowing each layer to be understood in terms of the properties provided 
by the layer below, rather than in terms of the primitive operations.

> I don't think GS2 even belongs inside the SASL framework. They both try
> to solve the same problem, therefore it's pointless (and redundent) for
> GS2 to exist inside SASL to begin with. The two should exist
> side-by-side, letting the application protocol developers make the
> tradeoff between code complexity and desired security.

Misconception #3: GS2 and SASL try to solve the same problem.

This is just flat-out not true.  GSS-API and SASL solve similar (arguably 
isomorphic) problems.  GS2 solves the problem of allowing GSS-API 
mechanisms to be used in SASL.  This allows application protocol developers 
and implementors to simply use SASL, while allowing users to take advantage 
of existing and future GSS-API mechanisms.  There is no extra complexity 
for application protocol developers or implementors, or even for SASL 
framework developers, because the abstraction means that all SASL 
mechanisms can be used in the same way.

> As for SCRAM vs. GS2-SCRAM, since the two cannot speak to each other on
> the wire they are by definition distinct and seperate protocols, and
> therefore demand distinct and seperate specficications. That much of the
> text might overlap doesn't change this fact. I realize it takes more work
> to write two seperate documents, but the onus upon this WG is to write
> specifications that above all else address the needs of the people who
> have to implement this stuff. Mixing two protocols in a single document
> is just slapping these people in the face.

Misconception #4: SCRAM implemented as a pure SASL mechanism does not 
interoperate with SCRAM implemented as a GSS-API mechanism and used with 
GS2.

Again, completely untrue.  The entire point is that they _do_ interoperate. 
This is accomplished by having a single document which specifies both a 
SASL mechanism and a GSS-API mechanism, with the property that when the 
GSS-API mechanism is used with GS2, it interoperates with the SASL 
mechanism.

This is _really_ important.

It means that implementors who just want to add a SASL mechanism to their 
framework, or who want to implement a single-mechanism application, can do 
so, and need know nothing about GS2 or GSS-API or the "complexity" thereof.

It also means that if I have an existing appplication which uses an 
existing SASL framework, and I have a GS2 plugin for that framework, then I 
can use any GSS-API mechanism I have lying around.  If the mechanism I 
choose to use is SCRAM, it will interoperate with the single-mechanism 
application described above.

Now, that second method may seem like a lot of complexity to you, and it 
would be if you were writing an application that was going to be completely 
unable to use any mechansim other than SCRAM.  But what it does is allow 
you to write an application that uses SCRAM or any other SASL mechanism or 
any other GSS-API mechanism, all while doing _less_ work than you would do 
in writing the single-mechanism application.  This is because the SASL, 
GS2, GSS-API, SCRAM, and other mechanism implementations can all be done by 
different people and are all reusable, as is the application.

Now, there may remain one point of confusion.

Alexey pointed at two documents describing two versions of the SCRAM 
protocol.  The protocols described by the two documents do _not_ 
interoperate, which is OK, because we're only adopting one of them.  The 
_plan_ is not to define a pure SASL mechanism based on one document and a 
GSS-API mechanism based on the other, or a pure SASL mechansim based on one 
document and a SASL mechanism based on the other plus GS2.

The plan is to _either_

(1) Define _only_ a pure SASL mechanism based on the first document, and 
tell people who want a secure, password-based mechanism for non-SASL 
GSS-API applications like NFS that they are SOL because the IETF doesn't 
care about their needs, _or_

(2) Define _both_ a pure SASL mechanism _and_ a GSS-API mechanism, both 
based on the second document, such that SCRAM will be available for both 
SASL applications and non-SASL GSS-API applications, and the GSS-API 
mechanism combined with GS2 will interoperate with the pure SASL mechanism.

Note that if this WG chooses option (1), it will almost certainly result in 
the submission of an individual document describing an GSS-API mechanism 
which is based on SCRAM and which can be used with GS2 (because _any_ 
GSS-API mechanism can be used with GS2), but which when used with GS2 will 
_not_ interoperate with the pure-SASL mechanism defined in this WG.  One 
effect of this is that, in environments where both the SASL and GSS-API 
mechanisms are present, users will have a choice of using SASl-SCRAM or 
GS2+GSS-SCRAM, and the two will not interoperate.

-- Jeff

Subject: SCRAM-HMAC-<<hash>> vs GS2-<<whatever>>
Date: Wed, 18 Feb 2009 14:06:37 +0000
From: Dave Cridland <[email-masked]>
To: <[email-masked]>
Cc: Kurt Zeilenga <[email-masked]>, Alexey Melnikov <[email-masked]>
Sender: [email-masked]

I'm not subscribed to the list, please copy me in on replies.

As someone who's spent a considerable time lately working with client  
developers of both MUAs and more recently XMPP, I'd like to describe  
what happens in those communities, particularly for XMPP.

XMPP's MTI SASL mechanism is currently DIGEST-MD5. This has to  
change. Operators and developers alike want a mechanism that doesn't  
store passwords in plaintext and doesn't send them in the clear  
either. SCRAM fits the bill very nicely, and is also relatively  
simple to code. Most client developers, especially, write their SASL  
mechanisms themselves - no libraries used - so a mechanism which is  
relatively straightforward to code in a number of common languages is  
important to us.

The GS2-<<whatever>> variant isn't much harder - although I suspect  
it is marginally more complex after reviewing them both. However, I  
feel strongly that although from a technical perspective there's  
little difference, the naming and use of GS2 will have a significant  
impact on deployment. In particular:

1) The simple fact it's using GSSAPI is enough to put many people off.

2) The name, by not being recognisable, would, I suspect, tend to  
mean that client developers don't notice the deployment, and won't  
follow up to see what the mechanism is. A SCRAM-HMAC-* name would,  
after all, be noticed much more easily in protocol logs, etc.

3) A SCRAM-HMAC-* name allows for new hash support to be obvious, and  
moreover allows for some implementations to switch in new hashes much  
more easily, by simple switching based on the name. GS2-<<whatever>>  
doesn't allow a developer to find out what hashes are supported very  
easily - indeed, the encrypted name means a brute-force attack is  
required.

None of this argues against there being a SCRAM-compatible GSSAPI  
mechanism, of course, but it does argue that a pure-SASL mechanism is  
useful to make available, and in some respects is actually going to  
be more secure, if only due to increased deployment and hash agility  
that's acted upon.

Dave.

Date: Tue, 17 Feb 2009 16:44:16 -0600
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, Hallvard B Furuseth <[email-masked]>, SASL WG <[email-masked]>
Subject: Or: simplifying GS2 (Re: Poll: pure SCRAM versa SCRAM-as-GS2)
Sender: [email-masked]

Perhaps we can just simplify GS2 enough that all concerns go away.

The primary differences between the GSS-API and SASL:

a) one is message-oriented (GSS), the other is stream-oriented (SASL);

b) SASL client apps must send the name of the mech being used before
   using it, while the GSS-API includes the "name" of the selected mech
   in the first authentication message;

c) SASL authentication message exchanges negotiate what security layers
   will be used and maximum message sizes; the GSS-API does no such
   negotiations;

d) the GSS-API has channel binding, but it's all or nothing, and it's
   optional; SASL has never had channel binding.

e) terminology :)

(a) is easy to address in a SASL/GSS bridge.
(b) is easy to address in a SASL/GSS bridge.
(c) is easy to addres by replacing security layers with channel binding
    to TLS, which has the added advantage of simplifying mechanisms and
    making (a) not matter.
(d) matters only if we want channel binding in SASL, and I think we long
    ago agreed we did, and if we re-open that question I believe we'll
    again conclude that we want it.
(e) we can ignore :)

So what makes GS2 not simple?  The fact that we chose to make the GS2
channel binding semantics different from the GSS-API's: we chose to make
channel binding success/failure affect the negotiation of security
layers.

If we reconsider that one choice we could simplify GS2 enough that a
single specification of SCRAM-as-a-GSS-API mechanism will satisfy all.

Nico
-- 

Date: Tue, 17 Feb 2009 15:54:36 -0600
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, Hallvard B Furuseth <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

On Tue, Feb 17, 2009 at 01:22:49PM -0800, Kurt Zeilenga wrote:
> >The only alternatives are:
> >
> >a) no GS2 (or limited to specific GSS mechanisms which will never be
> >  available as pure SASL, non-GS2 mechs);
> >b) no more pure SASL, non-GS2 mechs;
> >c) doubly-specified SASL mechs (once as pure SASL spec of a GS2 mech,
> >  the other as a pure GSS mech).
> >
> >All of these options suck.
> 
> Though I might not necessarily agree with your reasons, I can agree  
> that the above options do suck.  That's why I haven't suggested  
> anything of the kind, and do oppose making GS2-SASL definitive in  
> shape or form.

Note that (b) is effectively what the GS2 crowd (Simon, Sam, myself,
...) are proposing, though applied to SCRAM only.

Also, (a) will lead to multiple specs and implementations of what should
be pretty much the same mechanism: once for GSS, once for SASL.
Different mechs using similar messages and the same credentials.  The
difference between (a) and (c) is that (c) leads to multiple specs but
not multiple implementations.  (b) is the least sucky option... unless
you count RFC pages.

There are no good answers to this poll.

Nico
-- 

Date: Tue, 17 Feb 2009 22:37:34 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Subject: Re: SASL interop event (was Re: Poll: pure SCRAM versa SCRAM-as-GS2)
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Sender: [email-masked]

Kurt Zeilenga writes:
> During at least one of the LDAP interop events, we specifically tested 
>  SASL/DIGEST-MD5 interoperability.  It didn't go well.

Not surprised. I helped write two digest-md5 implementations and they 
don't always interoperate. This is not something I'm proud of.

That experience heightened my general suspicion of unnecessary 
complexity, so I don't think this posting is off-topic.

Arnt

Cc: Alexey Melnikov <[email-masked]>, Hallvard B Furuseth <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Tue, 17 Feb 2009 13:22:49 -0800
Sender: [email-masked]

On Feb 17, 2009, at 11:51 AM, Nicolas Williams wrote:

>
> On Tue, Feb 17, 2009 at 11:19:49AM -0800, Kurt Zeilenga wrote:
>>> We all agree that we want a SASL and a GSS-API mechanism that is
>>> password based and can share credential forms.
>>>
>>> The issue is: one mechanism, or two.
>>
>> Well, personally, I think there will be a GSS-API SCRAM mechanism
>> regardless of what this WG does, and hence a SASL-GS2-SCRAM mechanism
>> will become available, and specified on the standards track.

I have a feeling there will also be a simple SCRAM-based SASL  
mechanism regardless as well, but not necessarily documented on the  
Standards Track.

>> The question to me is whether we
>>
>> a:
>>   only document how to implement that mechanism directly (without
>> implementing GS2, GSS-API, and the GSS-API SCRAM mechanism).
>> b:
>>   only document an native SASL/SCRAM mechanism
>> c:
>>   do both
>>
>> I'm currently leaning towards c, though I'm trying to keep an open
>> mind towards b.
>
> (c) sounds like a recipe for: extra work and non-interop.

In (c), my assumption would be that SASL/SCRAM and SASL/GS2-SCRAM are  
two separate mechanisms, each with their own name. I would only claim  
they are based on the same technology, not that they were the same  
mechanism.  This would allow at least some reuse of some expertise,  
and possible certain code elements.

>>> I believe that this progression can result in correct  
>>> specifications:
>>> first specify the reduced, pure SASL version of SCRAM-as-GS2, then
>>> specify the pure GSS-API mechanism.
>>
>> We have what some believe is a "reduced, pure SASL version of
>> SCRAM-as- GS2", it seems time for "the pure GSS-API mechanism"
>> specification.
>
> I can't do it in time for the upcomming meeting.  Sorry.

Understand.

> And I don't think it should be a requirement, and I don't think  
> you're in a position
> to make it a requirement.

I was making a suggestion, not a requirement.

>
>
>>> I do, because I believe that the GSS version of the spec won't
>>> necessarily help establish that the pure SASL version of SCRAM-as-
>>> GS2 is correct.  See above.
>>
>> I don't see why a SASL mechanism RFC should be definitive over a GSS-
>> API mechanism for use, in say, NFS.  The GSS-API SCRAM specification
>
> Nobody said that.

Have never claimed any said that, I guess I won't dispute your  
statement.

I'm just stating an argument as why I think the GSS-API SCRAM  
specification needs to be definitive over the GS2-SCRAM specification.

> The pure GSS spec will have to be done.

That I don't doubt.

> You want it now, and I'm saying it needn't be a requirement right now.

I agree with both of these statements.  But I still hold my opinion  
regard what I can rely on in absence of a GSS-API SCRAM specification.

> Moreover, you won't get it (unless Simon or Sam step up and do it).

Oh well.

>> ought to be definitive.  The GS2-SCRAM ought to be an Informational
>> RFC describing an alternative implementation approach.
>
> That is the crux.  The pure SASL crowd scoffs at having to understand

> the GSS-API in order to implement SCRAM, thus the pure SASL
> specification of SCRAM-as-GS2 had better be Normative.

For GS2-SASL, I certainly have no problem with it being Informational.
But then I want a separate SASL/SCRAM mechanism.

> The pure GSS-API
> version will have to be as well, which imported via GS2 effectively
> results in two Normative specifications of the same mechanism.  That
> sounds like a recipe for trouble.

I do agree that this is a recipe for trouble.

> The only alternatives are:
>
> a) no GS2 (or limited to specific GSS mechanisms which will never be
>   available as pure SASL, non-GS2 mechs);
> b) no more pure SASL, non-GS2 mechs;
> c) doubly-specified SASL mechs (once as pure SASL spec of a GS2 mech,
>   the other as a pure GSS mech).
>
> All of these options suck.

Though I might not necessarily agree with your reasons, I can agree  
that the above options do suck.  That's why I haven't suggested  
anything of the kind, and do oppose making GS2-SASL definitive in  
shape or form.

-- Kurt

Date: Tue, 17 Feb 2009 14:02:18 -0600
From: Nicolas Williams <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
Cc: Kurt Zeilenga <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

On Tue, Feb 17, 2009 at 08:55:40PM +0100, Hallvard B Furuseth wrote:
> >    thus we can't expect them to review for wire compatibility of the
> >    two specs;
> 
> Indeed.  A brief page count says SCRAM-GS2 nearly doubles the amount of
> Scram background material, and multiplies the to-read pile by 7+ for a
> non-GSS person who knows the rest and just needed to read SCRAM itself.
> Depending on where you cut off what to count, anyway.
> 
>   Pages Documents
>    18   scram
>   150   sasl + saslprep + stringprep sans chartables
>         + hmac + sha-1 + channel bindings + base64 + utf-8
>   137   gs2 + gss-api + 2 more scram pages

GS2 has a lot of informative pages describing actual wire flows to help
the reader.  The point: page count is not a definitive measure of
complexity, not remotely.  You should also add to your page count all
the pages of API documentation you need to read in order to implement
SASL on your target platform.  And so on.  We all have to deal with
complexity.  Here we have some trade-offs with regards to complexity;
please see my reply to Kurt just a few minutes ago for details.

Nico
-- 

From: Hallvard B Furuseth <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Kurt Zeilenga <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Tue, 17 Feb 2009 21:08:26 +0100
Sender: [email-masked]

I wrote:
> Even if the HMAC is only a half-baked security layer, presumably it's
> better than nothing for apps that just take what they can get from the
> easily available mechanism(s).  If so, on unprotected connections
> SCRAM-GS2 looked weaker than SCRAM because it moved authzid out of the
> hash.
>
> Unless "gs2-to-be-protected" in the grammar is indeed intended to be
> protected.  But now you are talking as if maybe security layers need not
> be specified.

Uh, just to clarify: Obviously it's not critical to remove of a bit of
half-bakedness, if that's what it is.  Just a point to consider.  Now
that I'm trying to get my scram review notes into shape, there is a bit
of half-bakedness in several of the feature claims the SCRAM draft is
making.  I'll get these notes out the door Real Soon Now.

-- 
Hallvard

Date: Tue, 17 Feb 2009 13:51:46 -0600
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, Hallvard B Furuseth <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

On Tue, Feb 17, 2009 at 11:19:49AM -0800, Kurt Zeilenga wrote:
> >We all agree that we want a SASL and a GSS-API mechanism that is
> >password based and can share credential forms.
> >
> >The issue is: one mechanism, or two.
> 
> Well, personally, I think there will be a GSS-API SCRAM mechanism  
> regardless of what this WG does, and hence a SASL-GS2-SCRAM mechanism  
> will become available, and specified on the standards track.

All the more reason not to pursue a pure SASL, non-GS2 SCRAM.  Oterhwise
we might have situations like: client A that does only pure SASL,
non-GS2 SCRAM failing to use SCRAM with servers that support only the
GSS-API SCRAM mechanism through GS2.

> The question to me is whether we
> 
> a:
>    only document how to implement that mechanism directly (without  
> implementing GS2, GSS-API, and the GSS-API SCRAM mechanism).
> b:
>    only document an native SASL/SCRAM mechanism
> c:
>    do both
> 
> I'm currently leaning towards c, though I'm trying to keep an open  
> mind towards b.

(c) sounds like a recipe for: extra work and non-interop.

> >I believe that this progression can result in correct specifications:
> >first specify the reduced, pure SASL version of SCRAM-as-GS2, then
> >specify the pure GSS-API mechanism.
> 
> We have what some believe is a "reduced, pure SASL version of
> SCRAM-as- GS2", it seems time for "the pure GSS-API mechanism"
> specification.

I can't do it in time for the upcomming meeting.  Sorry.  And I don't
think it should be a requirement, and I don't think you're in a position
to make it a requirement.

> >I do, because I believe that the GSS version of the spec won't
> >necessarily help establish that the pure SASL version of SCRAM-as-
> >GS2 is correct.  See above.
> 
> I don't see why a SASL mechanism RFC should be definitive over a GSS- 
> API mechanism for use, in say, NFS.  The GSS-API SCRAM specification  

Nobody said that.  The pure GSS spec will have to be done.  You want it
now, and I'm saying it needn't be a requirement right now.  Moreover,
you won't get it (unless Simon or Sam step up and do it).

> ought to be definitive.  The GS2-SCRAM ought to be an Informational  
> RFC describing an alternative implementation approach.

That is the crux.  The pure SASL crowd scoffs at having to understand
the GSS-API in order to implement SCRAM, thus the pure SASL
specification of SCRAM-as-GS2 had better be Normative.  The pure GSS-API
version will have to be as well, which imported via GS2 effectively
results in two Normative specifications of the same mechanism.  That
sounds like a recipe for trouble.  The only alternatives are:

a) no GS2 (or limited to specific GSS mechanisms which will never be
   available as pure SASL, non-GS2 mechs);
b) no more pure SASL, non-GS2 mechs;
c) doubly-specified SASL mechs (once as pure SASL spec of a GS2 mech,
   the other as a pure GSS mech).

All of these options suck.  (a) sucks because it means extra
implementation work for those of us who have SASL and GSS-API stacks
(that's every OS vendor/distro maintainer out there).  (b) sucks for the
pure SASL crowd because it means learning the GSS-API and acquiring a
GSS-API stack.  (c) sucks, but only if we make a mistake.

Nico
-- 

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 17 Feb 2009 20:55:40 +0100
To: Nicolas Williams <[email-masked]>
Cc: Kurt Zeilenga <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

Nicolas Williams writes:
> Are you asserting that support for SCRAM w/o TLS is required?  If so,
> and if we have use such cases we wish to address, then yes, we'd need to
> specify the security layers in order to be complete.
> 
> But a) no one has made such an assertion,

I hope I misunderstand you.  Why would SCRAM require TLS?  Personally
I had not made the opposite assertion because it did not occur to me.

Apps have varying security requirements.  There are enough cases where
even plaintext passwords and no TLS is considered adequate.  I didn't
think SCRAM was only for apps far on the other side on the scale.

And now I remember why I tried to ask if HMAC(<StoredKey/ServerKey>,
AuthMessage) also doubles as an integrity protection layer:

Even if the HMAC is only a half-baked security layer, presumably it's
better than nothing for apps that just take what they can get from the
easily available mechanism(s).  If so, on unprotected connections
SCRAM-GS2 looked weaker than SCRAM because it moved authzid out of the
hash.

Unless "gs2-to-be-protected" in the grammar is indeed intended to be
protected.  But now you are talking as if maybe security layers need not
be specified.

> I'd rather we go with a pure SASL description of SCRAM as GS2 and let
> the GS2 proponents worry about ensuring that the result can be described
> as a GSS-API mechanism used through GS2.  There are several reasons for
> this:
> 
>  - pure SASL reviewers/implementors seem to have no patience for
>    anything related to the GSS-API,

Speaking for myself, I don't mind anything related to the GSS-API
or derived from it.  Why would I, when I don't know it?  However:

>    thus we can't expect them to review for wire compatibility of the
>    two specs;

Indeed.  A brief page count says SCRAM-GS2 nearly doubles the amount of
Scram background material, and multiplies the to-read pile by 7+ for a
non-GSS person who knows the rest and just needed to read SCRAM itself.
Depending on where you cut off what to count, anyway.

  Pages Documents
   18   scram
  150   sasl + saslprep + stringprep sans chartables
        + hmac + sha-1 + channel bindings + base64 + utf-8
  137   gs2 + gss-api + 2 more scram pages

-- 
Hallvard

Cc: Alexey Melnikov <[email-masked]>, Hallvard B Furuseth <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Tue, 17 Feb 2009 11:19:49 -0800
Sender: [email-masked]

On Feb 17, 2009, at 10:14 AM, Nicolas Williams wrote:

>
> On Tue, Feb 17, 2009 at 10:01:11AM -0800, Kurt Zeilenga wrote:
>> On Feb 17, 2009, at 9:19 AM, Nicolas Williams wrote:
>>> Are you asserting that support for SCRAM w/o TLS is required?
>>
>> Well, TLS had little to do with my above statement of incompleteness.
>
> It has everything to do with the one completeness issue that you have.
>
> Otherwise I don't see how your comment about completeness is  
> relevant to
> this discussion.
>
>> The above statement of incompleteness was more to do with
>> specification completeness, such as necessary to evaluate wire
>> compatibility, than feature completeness (such as inclusion of the  
>> GS2-
>> SASL security layer).
>
> I've addressed this.

Regrettable not to my personal satisfaction.

>
>
>> But I have noted that I would considered SASL/GS2-SCRAM w/o TLS as
>> being feature incomplete.   I don't think SASL/SCRAM w/o TLS as being
>> feature incomplete.
>
> I can't parse this.

s/TLS/security layer/g in the above paragraph.

That is,

I think it fine for SASL/SCRAM not to offer security layers.
I think SASL/GS2-SCRAM without support for GS2 security layers as  
being feature incomplete.

>
>
>> This is because I see GS2 mechanisms offering a more robust feature
>> set than what some non-GS2 mechanisms might offer, and I see SASL/
>> SCRAM as offering a simple mechanism.
>
> Ignoring the GSS->SASL bridging aspect of GS2 the primary difference
> between GS2 and non-GS2 SASL mechs is this:
>
>    GS2 mechanisms support channel binding and negotiation of security
>    layers that is conditional on channel binding.
>
> That's it.
>
>> I obviously don't see this as an X vs. Y choice.  I rather have a
>> simple SASL/SCRAM native mechanism and a robust SASL/GS2-SCRAM than a
>> single mechanism which is neither simple nor robust.
>
> We all agree that we want a SASL and a GSS-API mechanism that is
> password based and can share credential forms.
>
> The issue is: one mechanism, or two.

Well, personally, I think there will be a GSS-API SCRAM mechanism  
regardless of what this WG does, and hence a SASL-GS2-SCRAM mechanism  
will become available, and specified on the standards track.

The question to me is whether we

a:
    only document how to implement that mechanism directly (without  
implementing GS2, GSS-API, and the GSS-API SCRAM mechanism).
b:
    only document an native SASL/SCRAM mechanism
c:
    do both

I'm currently leaning towards c, though I'm trying to keep an open  
mind towards b.

>
>
>>> If so,
>>> and if we have use such cases we wish to address, then yes, we'd
>>> need to
>>> specify the security layers in order to be complete.
>>
>> Same uses cases that GS2 security layers serve.
>
> Again, are you asserting that security layers are a requirement?

I think GS2-SCRAM ought to detail how to implement all features of the  
GS2/GSS-API/SCRAM mechanism. Where not feasible, GS2-SCRAM could  
instead discuss why it's not feature complete and the implications of  
this.

So, requirement is too strong of a word.  I see such feature  
completeness of GS2-SCRAM as a SHOULD not a MUST.

>>> Are you asking about completeness, or correctness? (or both?)
>>
>> Well, in my previous response was referring to completeness of
>> specifications in order to better ensure correctness of those
>> specifications.
>
> I believe that this progression can result in correct specifications:
> first specify the reduced, pure SASL version of SCRAM-as-GS2, then
> specify the pure GSS-API mechanism.

We have what some believe is a "reduced, pure SASL version of SCRAM-as- 
GS2",
it seems time for "the pure GSS-API mechanism" specification.

> The reason I believe this is that short of actual interop testing of
> implementations of each type we'll need to manually review the pure  
> SASL
> version of SCRAM-as-GS2 for compatibility with GS2 and with GSS-API
> semantics.

I would certainly agree that short of interoperability testing of  
implementations of both approaches the question of wire compatibility  
is in doubt.   Which is one of the reasons I favor two mechanisms  
names over one mechanism name.  I rather deal with two names for the  
same thing than one name for two close but significantly different  
things.

> Having the pure GSS version of SCRAM is not necessarily
> going to help in that manual review (I say this as a GSS-API expert).
>
>>> I'd rather we go with a pure SASL description of SCRAM as GS2 and  
>>> let
>>> the GS2 proponents worry about ensuring that the result can be
>>> described
>>> as a GSS-API mechanism used through GS2.
>>
>> From an initial engineering point of view, I think it was reasonable
>> to design GS2-SCRAM before GSS-API SCRAM.
>>
>> But as a specification progression point of view, I don't see it
>> reasonable to progress/publish GS2-SCRAM prior to the progression/
>> publication of SASL/GS2 and GSS-API SCRAM.
>
> I do, because I believe that the GSS version of the spec won't
> necessarily help establish that the pure SASL version of SCRAM-as- 
> GS2 is
> correct.  See above.

I don't see why a SASL mechanism RFC should be definitive over a GSS- 
API mechanism for use, in say, NFS.  The GSS-API SCRAM specification  
ought to be definitive.  The GS2-SCRAM ought to be an Informational  
RFC describing an alternative implementation approach.

>
>
>>> There are several reasons for
>>> this:
>>>
>>> - pure SASL reviewers/implementors seem to have no patience for
>>> anything related to the GSS-API, thus we can't expect them to review
>>> for wire compatibility of the two specs;
>>
>> Yes, but I find it hard to rely on GS2 / GSS-API experts claims  
>> when I
>> know they don't yet have a GSS-API SCRAM specification to review.
>
> We don't need it.

While I respect your personal opinion in this area, your statement  
here doesn't change my personal opinion as stated above.

Cc: Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>, Hallvard B Furuseth <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Tue, 17 Feb 2009 10:23:33 -0800
Sender: [email-masked]

On Feb 17, 2009, at 10:01 AM, Kurt Zeilenga wrote:

> I obviously don't see this as an X vs. Y choice.

I also rather have two names for what is the same bits on the wire  
than one name for two different sets on the wire.

I guess I'm bit pessimistic about our abilities to ensure two separate  
specifications, for two separate implementation approaches, will yield  
wire compatibility over the life time of the specifications (including  
subsequent revisions, extensions, etc.).

-- Kurt

Date: Tue, 17 Feb 2009 12:14:29 -0600
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, Hallvard B Furuseth <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

On Tue, Feb 17, 2009 at 10:01:11AM -0800, Kurt Zeilenga wrote:
> On Feb 17, 2009, at 9:19 AM, Nicolas Williams wrote:
> >Are you asserting that support for SCRAM w/o TLS is required?
> 
> Well, TLS had little to do with my above statement of incompleteness.   

It has everything to do with the one completeness issue that you have.

Otherwise I don't see how your comment about completeness is relevant to
this discussion.

> The above statement of incompleteness was more to do with  
> specification completeness, such as necessary to evaluate wire  
> compatibility, than feature completeness (such as inclusion of the GS2- 
> SASL security layer).

I've addressed this.

> But I have noted that I would considered SASL/GS2-SCRAM w/o TLS as  
> being feature incomplete.   I don't think SASL/SCRAM w/o TLS as being  
> feature incomplete.

I can't parse this.

> This is because I see GS2 mechanisms offering a more robust feature  
> set than what some non-GS2 mechanisms might offer, and I see SASL/ 
> SCRAM as offering a simple mechanism.

Ignoring the GSS->SASL bridging aspect of GS2 the primary difference
between GS2 and non-GS2 SASL mechs is this:

    GS2 mechanisms support channel binding and negotiation of security
    layers that is conditional on channel binding.

That's it.

> I obviously don't see this as an X vs. Y choice.  I rather have a  
> simple SASL/SCRAM native mechanism and a robust SASL/GS2-SCRAM than a  
> single mechanism which is neither simple nor robust.

We all agree that we want a SASL and a GSS-API mechanism that is
password based and can share credential forms.

The issue is: one mechanism, or two.

> >If so,
> >and if we have use such cases we wish to address, then yes, we'd  
> >need to
> >specify the security layers in order to be complete.
> 
> Same uses cases that GS2 security layers serve.

Again, are you asserting that security layers are a requirement?

> >Are you asking about completeness, or correctness? (or both?)
> 
> Well, in my previous response was referring to completeness of  
> specifications in order to better ensure correctness of those  
> specifications.

I believe that this progression can result in correct specifications:
first specify the reduced, pure SASL version of SCRAM-as-GS2, then
specify the pure GSS-API mechanism.

The reason I believe this is that short of actual interop testing of
implementations of each type we'll need to manually review the pure SASL
version of SCRAM-as-GS2 for compatibility with GS2 and with GSS-API
semantics.  Having the pure GSS version of SCRAM is not necessarily
going to help in that manual review (I say this as a GSS-API expert).

> >I'd rather we go with a pure SASL description of SCRAM as GS2 and let
> >the GS2 proponents worry about ensuring that the result can be  
> >described
> >as a GSS-API mechanism used through GS2.
> 
> From an initial engineering point of view, I think it was reasonable  
> to design GS2-SCRAM before GSS-API SCRAM.
> 
> But as a specification progression point of view, I don't see it  
> reasonable to progress/publish GS2-SCRAM prior to the progression/ 
> publication of SASL/GS2 and GSS-API SCRAM.

I do, because I believe that the GSS version of the spec won't
necessarily help establish that the pure SASL version of SCRAM-as-GS2 is
correct.  See above.

> >There are several reasons for
> >this:
> >
> >- pure SASL reviewers/implementors seem to have no patience for
> >  anything related to the GSS-API, thus we can't expect them to review
> >  for wire compatibility of the two specs;
> 
> Yes, but I find it hard to rely on GS2 / GSS-API experts claims when I  
> know they don't yet have a GSS-API SCRAM specification to review.

We don't need it.  We need the pure SASL spec of SCRAM-as-GS2 and we can
work from that.

Short of actual interop testing you'll have to trust what reviewers say.

> >- there are GSS-API features that are not relevant to SASL/GS2 that we
> >  can leave out from the pure SASL description of SCRAM but should
> >  consider leaving in the pure GSS description of SCRAM.
> 
> Well, I think the GS2-SCRAM should at least discuss why it doesn't  
> detail how to implement certain features of the mechanism.  However, I  
> would favor a GS2-SCRAM that was more feature complete over one that  
> was less and am quite likely to argue for inclusion of certain  
> features (such as support for GS2 security layers) in GS-SASL.

I would too, but I don't believe that's necessary.

Nico
-- 

Date: Tue, 17 Feb 2009 11:14:11 -0700
From: Peter Saint-Andre <[email-masked]>
To: [email-masked]
CC: SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms080105050102060503050403
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

IMHO Ned's perspective is broadly congruent with experience in the XMPP
community.

[email-masked] wrote:
> 
>> On Feb 16, 2009, at 9:26 AM, Hallvard B Furuseth wrote:
> 
>> > One reality check: I have no idea what kind of SASL implementations
>> > are
>> > out there.  Are there implementations that do not support GS2/GSS?
> 
>> Yes.  For instance, it's fairly common to implement a basic SASL
>> implementation when one only requires simple SASL mechanisms (e.g.,
>> EXTERNAL, PLAIN, CRAM-MD5).
> 
> Over the years we've done several separate implementations of SASL, both
> server
> and client, supporting a variety of SASL mechanisms: EXTERNAL, PLAIN,
> LOGIN,
> CRAM-MD5, DIGEST-MD5, etc. But none of them have ever supported GS2/GSS,
> either
> through our own code or through interfacing with public libraries.
> 
> Frankly, unless the quality of the publicly available code for GS2/GSS has
> improved by at least an order of magnitude since the last time I looked
> at it,
> there's no chance we'll ever support GS2/GSS directly through publicly
> available code. Putting that code in the middle of a complex, multithreaded
> client or server seems like a sure-fire recipe for disaster. If we
> absolutely
> had to have support for this we'd do it by talking to a separate, single
> threaded authentication server process using some sort of simple protocol.
> 
> As for writing our own, the last time I looked into this I'm afraid I
> could not
> make head nor tails of the specifications. Now, this was some time ago
> and the
> specifications may have improved since then. Or alternately, it could be
> due to
> my own stupidity, but as a point of comparison I'm someone who was able
> to code
> a full implementation of X.400-1988 and the specifications for that were
> IMO
> plenty clear enough to implement from.
> 
>> [I've done this myself a couple of
>> times.]  I would hope that SCRAM would have similar complexity to CRAM-
>> MD5, and hence implementable quite independently of so-called "SASL
>> libraries" and GS2 and GSS-API frameworks.
> 
> Indeed. Not having to use a library is a pretty significant win in a lot of
> cases. That's another reason why I'm strongly in favor of keeping the
> complexity in SCRAM to an absolute minimum.
> 
>                 Ned
> 

--------------ms080105050102060503050403
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms080105050102060503050403--

Cc: Alexey Melnikov <[email-masked]>, Hallvard B Furuseth <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Tue, 17 Feb 2009 10:01:11 -0800
Sender: [email-masked]

On Feb 17, 2009, at 9:19 AM, Nicolas Williams wrote:

>
> On Tue, Feb 17, 2009 at 09:07:12AM -0800, Kurt Zeilenga wrote:
>> On Feb 17, 2009, at 8:42 AM, Nicolas Williams wrote:
>>> On Mon, Feb 16, 2009 at 02:09:24PM -0800, Kurt Zeilenga wrote:
>>>> On Feb 16, 2009, at 1:32 PM, Nicolas Williams wrote:
>>>>> I think SASL + TLS is the common case, thus to fail to describe
>>>>> SCRAM
>>>>> SASL sec layers in the SCRAM-GS2-as-pure-SASL doc is a reasonable
>>>>> position to take so as to simplify that document.  Thus anyone  
>>>>> who'd
>>>>> want to implement SCRAM sec layers would have to read the GS2 and
>>>>> SCRAM-as-GSS-API-mech documents.
>>>>
>>>> I think it would be good to have a GSSAPI-SCRAM I-D soon (before
>>>> IETF#74).
>>>
>>> It'd be good, yes, but, does that have anything to do with this  
>>> poll?
>>
>> Because the completeness of the GS2-SCRAM I-D is questionable to some
>> without a GSS-API SCRAM specification.
>
> Are you asserting that support for SCRAM w/o TLS is required?

Well, TLS had little to do with my above statement of incompleteness.   
The above statement of incompleteness was more to do with  
specification completeness, such as necessary to evaluate wire  
compatibility, than feature completeness (such as inclusion of the GS2- 
SASL security layer).

But I have noted that I would considered SASL/GS2-SCRAM w/o TLS as  
being feature incomplete.   I don't think SASL/SCRAM w/o TLS as being  
feature incomplete.

This is because I see GS2 mechanisms offering a more robust feature  
set than what some non-GS2 mechanisms might offer, and I see SASL/ 
SCRAM as offering a simple mechanism.

I obviously don't see this as an X vs. Y choice.  I rather have a  
simple SASL/SCRAM native mechanism and a robust SASL/GS2-SCRAM than a  
single mechanism which is neither simple nor robust.

> If so,
> and if we have use such cases we wish to address, then yes, we'd  
> need to
> specify the security layers in order to be complete.

Same uses cases that GS2 security layers serve.

>> That is, having a GSS-API SCRAM specification will allow for  
>> reviewers
>> to consider the question of whether GS2-SASL is wire compatible or
>> not, as opposed to simply relying on claims that it will be.
>
> Are you asking about completeness, or correctness? (or both?)

Well, in my previous response was referring to completeness of  
specifications in order to better ensure correctness of those  
specifications.

But with TLS, I refer to completeness of feature sets.

>> It may also tease out other issues, such as which specification is
>> definitive.
>
> I'd rather we go with a pure SASL description of SCRAM as GS2 and let
> the GS2 proponents worry about ensuring that the result can be  
> described
> as a GSS-API mechanism used through GS2.

 From an initial engineering point of view, I think it was reasonable  
to design GS2-SCRAM before GSS-API SCRAM.

But as a specification progression point of view, I don't see it  
reasonable to progress/publish GS2-SCRAM prior to the progression/ 
publication of SASL/GS2 and GSS-API SCRAM.

> There are several reasons for
> this:
>
> - pure SASL reviewers/implementors seem to have no patience for
>   anything related to the GSS-API, thus we can't expect them to review
>   for wire compatibility of the two specs;

Yes, but I find it hard to rely on GS2 / GSS-API experts claims when I  
know they don't yet have a GSS-API SCRAM specification to review.

> - there are GSS-API features that are not relevant to SASL/GS2 that we
>   can leave out from the pure SASL description of SCRAM but should
>   consider leaving in the pure GSS description of SCRAM.

Well, I think the GS2-SCRAM should at least discuss why it doesn't  
detail how to implement certain features of the mechanism.  However, I  
would favor a GS2-SCRAM that was more feature complete over one that  
was less and am quite likely to argue for inclusion of certain  
features (such as support for GS2 security layers) in GS-SASL.

-- Kurt

Cc: Alexey Melnikov <[email-masked]>, Hallvard B Furuseth <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Tue, 17 Feb 2009 09:37:54 -0800
Sender: [email-masked]

On Feb 17, 2009, at 8:42 AM, Nicolas Williams wrote:

>
> On Mon, Feb 16, 2009 at 02:09:24PM -0800, Kurt Zeilenga wrote:
>> On Feb 16, 2009, at 1:32 PM, Nicolas Williams wrote:
>>> I think SASL + TLS is the common case, thus to fail to describe  
>>> SCRAM
>>> SASL sec layers in the SCRAM-GS2-as-pure-SASL doc is a reasonable
>>> position to take so as to simplify that document.  Thus anyone who'd
>>> want to implement SCRAM sec layers would have to read the GS2 and
>>> SCRAM-as-GSS-API-mech documents.
>>
>> I think it would be good to have a GSSAPI-SCRAM I-D soon (before
>> IETF#74).
>
> It'd be good, yes, but, does that have anything to do with this poll?

Aside from my previous comment (in which I was speaking as an  
individual), I'd like to make one comment here with my chair hat on.

One of my concerns with this straw poll is its finality, or lack  
thereof, in the face of incomplete documents.  Regardless of which I-D  
we choose (or both), if we later decide (for whatever reason) to  
significant change that I-D (or the other), it would be reasonable to  
allow re-opening of the question of this straw poll.  My nudging for  
the above (as well as other completeness issues) is, in part, an  
attempt to reduce the likelihood of subsequent significant change in  
this I-D.

-- Kurt

Date: Tue, 17 Feb 2009 11:19:35 -0600
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, Hallvard B Furuseth <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

On Tue, Feb 17, 2009 at 09:07:12AM -0800, Kurt Zeilenga wrote:
> On Feb 17, 2009, at 8:42 AM, Nicolas Williams wrote:
> >On Mon, Feb 16, 2009 at 02:09:24PM -0800, Kurt Zeilenga wrote:
> >>On Feb 16, 2009, at 1:32 PM, Nicolas Williams wrote:
> >>>I think SASL + TLS is the common case, thus to fail to describe  
> >>>SCRAM
> >>>SASL sec layers in the SCRAM-GS2-as-pure-SASL doc is a reasonable
> >>>position to take so as to simplify that document.  Thus anyone who'd
> >>>want to implement SCRAM sec layers would have to read the GS2 and
> >>>SCRAM-as-GSS-API-mech documents.
> >>
> >>I think it would be good to have a GSSAPI-SCRAM I-D soon (before
> >>IETF#74).
> >
> >It'd be good, yes, but, does that have anything to do with this poll?
> 
> Because the completeness of the GS2-SCRAM I-D is questionable to some  
> without a GSS-API SCRAM specification.

Are you asserting that support for SCRAM w/o TLS is required?  If so,
and if we have use such cases we wish to address, then yes, we'd need to
specify the security layers in order to be complete.

But a) no one has made such an assertion, b) even then that does not
necessarily require that we have a document defining SCRAM-as-a-GSS-API-
mechanism immediately.

> That is, having a GSS-API SCRAM specification will allow for reviewers  
> to consider the question of whether GS2-SASL is wire compatible or  
> not, as opposed to simply relying on claims that it will be.

Are you asking about completeness, or correctness? (or both?)

> It may also tease out other issues, such as which specification is  
> definitive.

I'd rather we go with a pure SASL description of SCRAM as GS2 and let
the GS2 proponents worry about ensuring that the result can be described
as a GSS-API mechanism used through GS2.  There are several reasons for
this:

 - pure SASL reviewers/implementors seem to have no patience for
   anything related to the GSS-API, thus we can't expect them to review
   for wire compatibility of the two specs;

 - there are GSS-API features that are not relevant to SASL/GS2 that we
   can leave out from the pure SASL description of SCRAM but should
   consider leaving in the pure GSS description of SCRAM.

Nico
-- 

Date: Tue, 17 Feb 2009 17:17:55 +0000
From: Alexey Melnikov <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
CC: Nicolas Williams <[email-masked]>, Hallvard B Furuseth <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

Kurt Zeilenga wrote:

> On Feb 17, 2009, at 8:42 AM, Nicolas Williams wrote:
>
>> On Mon, Feb 16, 2009 at 02:09:24PM -0800, Kurt Zeilenga wrote:
>>
>>> On Feb 16, 2009, at 1:32 PM, Nicolas Williams wrote:
>>>
>>>> I think SASL + TLS is the common case, thus to fail to describe  SCRAM
>>>> SASL sec layers in the SCRAM-GS2-as-pure-SASL doc is a reasonable
>>>> position to take so as to simplify that document.  Thus anyone who'd
>>>> want to implement SCRAM sec layers would have to read the GS2 and
>>>> SCRAM-as-GSS-API-mech documents.
>>>
>>> I think it would be good to have a GSSAPI-SCRAM I-D soon (before
>>> IETF#74).
>>
>> It'd be good, yes, but, does that have anything to do with this poll?
>
> Because the completeness of the GS2-SCRAM I-D is questionable to some  
> without a GSS-API SCRAM specification.

This would need doing once we make a choice, but I don't think this is a 
prerequisite for making it.

> That is, having a GSS-API SCRAM specification will allow for 
> reviewers  to consider the question of whether GS2-SASL is wire 
> compatible or  not, as opposed to simply relying on claims that it 
> will be.

Just trust us :-).

> It may also tease out other issues, such as which specification is  
> definitive.

Date: Tue, 17 Feb 2009 17:16:35 +0000
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: Kurt Zeilenga <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: SASL interop event  (was Re: Poll: pure SCRAM versa SCRAM-as-GS2)
Sender: [email-masked]

Hallvard B Furuseth wrote:

>Kurt Zeilenga writes:
>  
>
>>During at least one of the LDAP interop events, we specifically tested  
>>SASL/DIGEST-MD5 interoperability.  It didn't go well.
>>    
>>
>Whee.  Details!  What problems where identified?  Which mistakes are we
>repeating now?
>  
>
Most of this should be in my draft "Digest to historic".

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 17 Feb 2009 18:13:13 +0100
To: Kurt Zeilenga <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: SASL interop event  (was Re: Poll: pure SCRAM versa SCRAM-as-GS2)
Sender: [email-masked]

Kurt Zeilenga writes:
> During at least one of the LDAP interop events, we specifically tested  
> SASL/DIGEST-MD5 interoperability.  It didn't go well.

Whee.  Details!  What problems where identified?  Which mistakes are we
repeating now?

-- 
Hallvard

Cc: Alexey Melnikov <[email-masked]>, Hallvard B Furuseth <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Tue, 17 Feb 2009 09:07:12 -0800
Sender: [email-masked]

On Feb 17, 2009, at 8:42 AM, Nicolas Williams wrote:

> On Mon, Feb 16, 2009 at 02:09:24PM -0800, Kurt Zeilenga wrote:
>> On Feb 16, 2009, at 1:32 PM, Nicolas Williams wrote:
>>> I think SASL + TLS is the common case, thus to fail to describe  
>>> SCRAM
>>> SASL sec layers in the SCRAM-GS2-as-pure-SASL doc is a reasonable
>>> position to take so as to simplify that document.  Thus anyone who'd
>>> want to implement SCRAM sec layers would have to read the GS2 and
>>> SCRAM-as-GSS-API-mech documents.
>>
>> I think it would be good to have a GSSAPI-SCRAM I-D soon (before
>> IETF#74).
>
> It'd be good, yes, but, does that have anything to do with this poll?

Because the completeness of the GS2-SCRAM I-D is questionable to some  
without a GSS-API SCRAM specification.

That is, having a GSS-API SCRAM specification will allow for reviewers  
to consider the question of whether GS2-SASL is wire compatible or  
not, as opposed to simply relying on claims that it will be.

It may also tease out other issues, such as which specification is  
definitive.

-- Kurt

Date: Tue, 17 Feb 2009 10:06:49 -0700
From: Peter Saint-Andre <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
CC: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: SASL interop event          (was Re: Poll: pure SCRAM versa SCRAM-as-GS2)
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms020601090808020904060103
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Kurt Zeilenga wrote:
> 
> On Feb 17, 2009, at 2:40 AM, Alexey Melnikov wrote:
> 
>> Arnt Gulbrandsen wrote:
>>
>>> Alexey
>>> (http://tools.ietf.org/html/draft-ietf-sasl-digest-to-historic) made
>>> me think there are _many_ digest-md5 implementations out there. Fifty
>>> or a hundred seem a more reasonable estimates than ten. If the number
>>> were ten or twenty, it would have been practical to gather a good
>>> fraction of the implentors for an interop event.
> 
> During at least one of the LDAP interop events, we specifically tested
> SASL/DIGEST-MD5 interoperability.  It didn't go well.

We have experienced significant inteorperability problems regarding
SASL/DIGEST-MD5 on the XMPP network, too.

Peter

--------------ms020601090808020904060103
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms020601090808020904060103--

Date: Tue, 17 Feb 2009 10:42:24 -0600
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, Hallvard B Furuseth <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

On Mon, Feb 16, 2009 at 02:09:24PM -0800, Kurt Zeilenga wrote:
> On Feb 16, 2009, at 1:32 PM, Nicolas Williams wrote:
> >I think SASL + TLS is the common case, thus to fail to describe SCRAM
> >SASL sec layers in the SCRAM-GS2-as-pure-SASL doc is a reasonable
> >position to take so as to simplify that document.  Thus anyone who'd
> >want to implement SCRAM sec layers would have to read the GS2 and
> >SCRAM-as-GSS-API-mech documents.
> 
> I think it would be good to have a GSSAPI-SCRAM I-D soon (before  
> IETF#74).

It'd be good, yes, but, does that have anything to do with this poll?

Cc: Arnt Gulbrandsen <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: SASL interop event  (was Re: Poll: pure SCRAM versa SCRAM-as-GS2)
Date: Tue, 17 Feb 2009 08:51:01 -0800
Sender: [email-masked]

On Feb 17, 2009, at 2:40 AM, Alexey Melnikov wrote:

>
> Arnt Gulbrandsen wrote:
>
>> Alexey (http://tools.ietf.org/html/draft-ietf-sasl-digest-to- 
>> historic) made me think there are _many_ digest-md5 implementations  
>> out there. Fifty or a hundred seem a more reasonable estimates than  
>> ten. If the number were ten or twenty, it would have been practical  
>> to gather a good fraction of the implentors for an interop event.

During at least one of the LDAP interop events, we specifically tested  
SASL/DIGEST-MD5 interoperability.  It didn't go well.

-- Kurt

Cc: SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Tue, 17 Feb 2009 08:41:40 -0800
Sender: [email-masked]

The chairs plan on making some evaluation of this question within the  
next few days.

If you haven't commented already, please now state your opinion.

-- Kurt

On Feb 5, 2009, at 1:14 PM, Alexey Melnikov wrote:

>
> Folks,
> I would like to solicit feedback from people regarding the choice  
> between 2 SCRAM versions:
> http://tools.ietf.org/id/draft-newman-auth-scram-08.txt
> and
> http://tools.ietf.org/id/draft-newman-auth-scram-gs2-00.txt
>
> You can use the following URL to see changes between them:
> http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-newman-auth-scram-08.txt&url2=http://tools.ietf.org/id/draft-newman-auth-scram-gs2-00.txt
>
> Please send your opinion on which version you prefer (and a short  
> explanation of why) to the mailing list, or say if you need more  
> information.
>
> I would like to get all answers before February 19th, please.
>
> Regards,
> Alexey
>

Date: Tue, 17 Feb 2009 10:40:00 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: SASL interop event (was Re: Poll: pure SCRAM versa SCRAM-as-GS2)
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Alexey (http://tools.ietf.org/html/draft-ietf-sasl-digest-to-historic) 
> made me think there are _many_ digest-md5 implementations out there. 
> Fifty or a hundred seem a more reasonable estimates than ten. If the 
> number were ten or twenty, it would have been practical to gather a 
> good fraction of the implentors for an interop event.
>
> The number of SASL implementations can't be any smaller.

I think implementors of major open source SASL libraries are subscribed 
to this mailing list.
Getting a hold of other implementors might not be trivial - many of them 
don't participate in this mailing list and are not known to me personally.

Date: Tue, 17 Feb 2009 10:36:07 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

Alexey (http://tools.ietf.org/html/draft-ietf-sasl-digest-to-historic) 
made me think there are _many_ digest-md5 implementations out there. 
Fifty or a hundred seem a more reasonable estimates than ten. If the 
number were ten or twenty, it would have been practical to gather a 
good fraction of the implentors for an interop event.

The number of SASL implementations can't be any smaller.

Arnt

Date: Mon, 16 Feb 2009 17:14:54 -0800 (PST)
From: [email-masked]
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
To: Kurt Zeilenga <[email-masked]>
Cc: Hallvard B Furuseth <[email-masked]>, Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Sender: [email-masked]

> On Feb 16, 2009, at 9:26 AM, Hallvard B Furuseth wrote:

> > One reality check: I have no idea what kind of SASL implementations
> > are
> > out there.  Are there implementations that do not support GS2/GSS?

> Yes.  For instance, it's fairly common to implement a basic SASL
> implementation when one only requires simple SASL mechanisms (e.g.,
> EXTERNAL, PLAIN, CRAM-MD5).

Over the years we've done several separate implementations of SASL, both server
and client, supporting a variety of SASL mechanisms: EXTERNAL, PLAIN, LOGIN,
CRAM-MD5, DIGEST-MD5, etc. But none of them have ever supported GS2/GSS, either
through our own code or through interfacing with public libraries.

Frankly, unless the quality of the publicly available code for GS2/GSS has
improved by at least an order of magnitude since the last time I looked at it,
there's no chance we'll ever support GS2/GSS directly through publicly
available code. Putting that code in the middle of a complex, multithreaded
client or server seems like a sure-fire recipe for disaster. If we absolutely
had to have support for this we'd do it by talking to a separate, single
threaded authentication server process using some sort of simple protocol.

As for writing our own, the last time I looked into this I'm afraid I could not
make head nor tails of the specifications. Now, this was some time ago and the
specifications may have improved since then. Or alternately, it could be due to
my own stupidity, but as a point of comparison I'm someone who was able to code
a full implementation of X.400-1988 and the specifications for that were IMO
plenty clear enough to implement from.

> [I've done this myself a couple of
> times.]  I would hope that SCRAM would have similar complexity to CRAM-
> MD5, and hence implementable quite independently of so-called "SASL
> libraries" and GS2 and GSS-API frameworks.

Indeed. Not having to use a library is a pretty significant win in a lot of
cases. That's another reason why I'm strongly in favor of keeping the
complexity in SCRAM to an absolute minimum.

				Ned

Cc: Alexey Melnikov <[email-masked]>, Hallvard B Furuseth <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Mon, 16 Feb 2009 14:09:24 -0800
Sender: [email-masked]

On Feb 16, 2009, at 1:32 PM, Nicolas Williams wrote:

> I think SASL + TLS is the common case, thus to fail to describe SCRAM
> SASL sec layers in the SCRAM-GS2-as-pure-SASL doc is a reasonable
> position to take so as to simplify that document.  Thus anyone who'd
> want to implement SCRAM sec layers would have to read the GS2 and
> SCRAM-as-GSS-API-mech documents.

I think it would be good to have a GSSAPI-SCRAM I-D soon (before  
IETF#74).

-- Kurt

Cc: Alexey Melnikov <[email-masked]>, Hallvard B Furuseth <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Mon, 16 Feb 2009 14:02:54 -0800
Sender: [email-masked]

On Feb 16, 2009, at 1:32 PM, Nicolas Williams wrote:

>
> On Mon, Feb 16, 2009 at 12:59:44PM -0800, Kurt Zeilenga wrote:
>> On Feb 16, 2009, at 11:59 AM, Alexey Melnikov wrote:
>>> Kurt Zeilenga wrote:
>>>> More precisely I think, the GS2-SCRAM I-D doesn't discuss how to
>>>> implement (without implementing GS2+GSSAPI+SCRAM) the GS2 security
>>>> layer for the GSS-API SCRAM mechanism.
>>>
>>> No, it is quite explicit about that: GS2 security layer is
>>> negotiated off.
>
> When channel binding succeeds.
>
>> My point is that SASL-GS2-GSS-SCRAM would be capable of supporting
>> SASL security layers but the GS2-SCRAM I-D fails to detail how to
>> implement them.
>>
>> My view GS2-SCRAM I-D as being incomplete.   It should either detail
>> how to offer the GS2+GSSAPI+SCRAM layers, or it should detail why it
>> doesn't.
>
> I'm not sure.
>
> I think SASL + TLS is the common case, thus to fail to describe SCRAM
> SASL sec layers in the SCRAM-GS2-as-pure-SASL doc is a reasonable
> position to take so as to simplify that document.  Thus anyone who'd
> want to implement SCRAM sec layers would have to read the GS2 and
> SCRAM-as-GSS-API-mech documents.

The GS2-SCRAM I-D currently has this note:
     <<For simplicity, this family of mechanism does not presently  
include negotiation of a security layer. It is intended to be used  
with an external security layer such as that provided by TLS or SSH.>>
which is seems incorrect to me.  The GS2 family of mechanisms do  
support negotiation of a (SASL) layer, and that includes when the GSS- 
API SCRAM mechanism is in use via GS2.  This I-D should, if it's not  
going to provide a description of how to implement those layers  
without G2 and GSS-API, should say something like:
     While the GS2 family of mechanisms, including when used with the  
GSS-API SCRAM mechanism, do offer SASL security layers, this document  
does not discuss how to implement them.
Then a rationale for making this choice should be offered, possibly in  
the Security Considerations section of the I-D.
-- Kurt

Date: Mon, 16 Feb 2009 15:32:41 -0600
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, Hallvard B Furuseth <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

On Mon, Feb 16, 2009 at 12:59:44PM -0800, Kurt Zeilenga wrote:
> On Feb 16, 2009, at 11:59 AM, Alexey Melnikov wrote:
> >Kurt Zeilenga wrote:
> >>More precisely I think, the GS2-SCRAM I-D doesn't discuss how to   
> >>implement (without implementing GS2+GSSAPI+SCRAM) the GS2 security   
> >>layer for the GSS-API SCRAM mechanism.
> >
> >No, it is quite explicit about that: GS2 security layer is  
> >negotiated off.

When channel binding succeeds.

> My point is that SASL-GS2-GSS-SCRAM would be capable of supporting  
> SASL security layers but the GS2-SCRAM I-D fails to detail how to  
> implement them.
> 
> My view GS2-SCRAM I-D as being incomplete.   It should either detail  
> how to offer the GS2+GSSAPI+SCRAM layers, or it should detail why it  
> doesn't.

I'm not sure.

I think SASL + TLS is the common case, thus to fail to describe SCRAM
SASL sec layers in the SCRAM-GS2-as-pure-SASL doc is a reasonable
position to take so as to simplify that document.  Thus anyone who'd
want to implement SCRAM sec layers would have to read the GS2 and
SCRAM-as-GSS-API-mech documents.

Nico
-- 

Cc: Hallvard B Furuseth <[email-masked]>, Nicolas Williams <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Mon, 16 Feb 2009 12:59:44 -0800
Sender: [email-masked]

On Feb 16, 2009, at 11:59 AM, Alexey Melnikov wrote:

>
> Kurt Zeilenga wrote:
>
>> On Feb 16, 2009, at 11:42 AM, Alexey Melnikov wrote:
>>
>>>> Or if it's too weak to be called that, should it be
>>>> strengthened so it can be considered one?  The hashed  
>>>> AuthMessage  in the
>>>> ServerSignature would be the messages from the entire exchange,  
>>>> not  just
>>>> up to the final client message.
>>>
>>> Neither version of SCRAM provide any SASL security layer at the   
>>> moment.
>>
>> More precisely I think, the GS2-SCRAM I-D doesn't discuss how to   
>> implement (without implementing GS2+GSSAPI+SCRAM) the GS2 security   
>> layer for the GSS-API SCRAM mechanism.
>
> No, it is quite explicit about that: GS2 security layer is  
> negotiated off.

My point is that SASL-GS2-GSS-SCRAM would be capable of supporting  
SASL security layers but the GS2-SCRAM I-D fails to detail how to  
implement them.

My view GS2-SCRAM I-D as being incomplete.   It should either detail  
how to offer the GS2+GSSAPI+SCRAM layers, or it should detail why it  
doesn't.

-- Kurt

Date: Mon, 16 Feb 2009 19:59:18 +0000
From: Alexey Melnikov <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
CC: Hallvard B Furuseth <[email-masked]>, Nicolas Williams <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

Kurt Zeilenga wrote:

> On Feb 16, 2009, at 11:42 AM, Alexey Melnikov wrote:
>
>>> Or if it's too weak to be called that, should it be
>>> strengthened so it can be considered one?  The hashed AuthMessage  
>>> in the
>>> ServerSignature would be the messages from the entire exchange, not  
>>> just
>>> up to the final client message.
>>
>> Neither version of SCRAM provide any SASL security layer at the  moment.
>
> More precisely I think, the GS2-SCRAM I-D doesn't discuss how to  
> implement (without implementing GS2+GSSAPI+SCRAM) the GS2 security  
> layer for the GSS-API SCRAM mechanism.

No, it is quite explicit about that: GS2 security layer is negotiated off.

Cc: Hallvard B Furuseth <[email-masked]>, Nicolas Williams <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Mon, 16 Feb 2009 11:57:55 -0800
Sender: [email-masked]

On Feb 16, 2009, at 11:42 AM, Alexey Melnikov wrote:

>>
>> Or if it's too weak to be called that, should it be
>> strengthened so it can be considered one?  The hashed AuthMessage  
>> in the
>> ServerSignature would be the messages from the entire exchange, not  
>> just
>> up to the final client message.
>>
> Neither version of SCRAM provide any SASL security layer at the  
> moment.

More precisely I think, the GS2-SCRAM I-D doesn't discuss how to  
implement (without implementing GS2+GSSAPI+SCRAM) the GS2 security  
layer for the GSS-API SCRAM mechanism.

-- Kurt

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 16 Feb 2009 20:48:01 +0100
To: Alexey Melnikov <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, Kurt Zeilenga <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

Alexey Melnikov writes:
>Hallvard B Furuseth wrote:
>> Is the HMAC(<StoredKey/ServerKey>, AuthMessage) in SCRAM an integrity
>> protection layer?

I should have asked, did it double as a security layer.  Anyway,

> No:
>(...)
> Actually no, I moved auhorization identity and channel binding out of 
> AuthMessage, because they are transported by the GS2 itself. They are a 
> part of the stuff signed with GSS_Wrap.

Duh, of course.  Part of the undescribed gs2 semantics I'd just been
talking about.  Never mind.

-- 
Hallvard

Date: Mon, 16 Feb 2009 19:42:17 +0000
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: Nicolas Williams <[email-masked]>, Kurt Zeilenga <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

Hallvard B Furuseth wrote:

>Nicolas Williams writes:
>  
>
>>Given that SASL-GS2 security layers would be optional, but also that the
>>basis for an integrity protection layer being part of the SCRAM
>>internals for channel binding, IMO:
>>
>> - the spec should describe the integrity protection security layer
>> - the spec need not describe a privacy protection (encryption) security
>>   layer, which can then be provided by a separate I-D.
>>    
>>
>Is the HMAC(<StoredKey/ServerKey>, AuthMessage) in SCRAM an integrity
>protection layer?
>
No:

    ClientSignature := HMAC(StoredKey, AuthMessage)
    ServerSignature := HMAC(ServerKey, AuthMessage)

They are used by the client/server side to confirm that they know 
password (or some information derived from it) and to make sure that the 
AuthMessage wasn't tempered with.

>Or if it's too weak to be called that, should it be
>strengthened so it can be considered one?  The hashed AuthMessage in the
>ServerSignature would be the messages from the entire exchange, not just
>up to the final client message.
>  
>
Neither version of SCRAM provide any SASL security layer at the moment.

>SCRAM-GS2 moved channel bindings and authzid out of AuthMessage,
>presumably due to this text in GS2-10:
>  
>
Actually no, I moved auhorization identity and channel binding out of 
AuthMessage, because they are transported by the GS2 itself. They are a 
part of the stuff signed with GSS_Wrap.

>>10.  Non-integrity capable GSS-API mechanisms
>>
>>  Channel bindings and security layers MUST NOT be negotiated when the
>>  GSS-API mechanism do not support integrity.  It should also be
>>  understood that the authorization identity is not integrity
>>  protected.
>>    
>>
>Which makes me curious - does GSS-API not allow for a mechanism which
>supports channel bindings but not its own integrity protection layer?
>
>Or is it just that GSS-API expects more of integrity protection than
>SASL does, so one can't necessarily call a SASL protection layer a
>GSS-API protection layer?  I notice this GS2 section mentions
>"per-message" integrity protection in some but not all places, for
>example.
>  
>

Date: Mon, 16 Feb 2009 19:33:27 +0000
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

Hallvard B Furuseth wrote:

>Kurt Zeilenga writes:
>  
>
>One reality check: I have no idea what kind of SASL implementations are
>out there.  Are there implementations that do not support GS2/GSS?
>
I can't only talk for one implementation: CMU SASL doesn't provide 
GSS-API interface, it is a pure SASL implementation.

>Or is the technical complexity a storm in a teacup because implementations
>will have GS2 for the sake of Kerberos?
>  
>

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 16 Feb 2009 19:49:56 +0100
To: Nicolas Williams <[email-masked]>
Cc: Kurt Zeilenga <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

Nicolas Williams writes:
> Given that SASL-GS2 security layers would be optional, but also that the
> basis for an integrity protection layer being part of the SCRAM
> internals for channel binding, IMO:
> 
>  - the spec should describe the integrity protection security layer
>  - the spec need not describe a privacy protection (encryption) security
>    layer, which can then be provided by a separate I-D.

Is the HMAC(<StoredKey/ServerKey>, AuthMessage) in SCRAM an integrity
protection layer?  Or if it's too weak to be called that, should it be
strengthened so it can be considered one?  The hashed AuthMessage in the
ServerSignature would be the messages from the entire exchange, not just
up to the final client message.

SCRAM-GS2 moved channel bindings and authzid out of AuthMessage,
presumably due to this text in GS2-10:

> 10.  Non-integrity capable GSS-API mechanisms
>
>   Channel bindings and security layers MUST NOT be negotiated when the
>   GSS-API mechanism do not support integrity.  It should also be
>   understood that the authorization identity is not integrity
>   protected.

Which makes me curious - does GSS-API not allow for a mechanism which
supports channel bindings but not its own integrity protection layer?

Or is it just that GSS-API expects more of integrity protection than
SASL does, so one can't necessarily call a SASL protection layer a
GSS-API protection layer?  I notice this GS2 section mentions
"per-message" integrity protection in some but not all places, for
example.

-- 
Hallvard

Cc: Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Mon, 16 Feb 2009 10:01:38 -0800
Sender: [email-masked]

On Feb 16, 2009, at 9:26 AM, Hallvard B Furuseth wrote:

> One reality check: I have no idea what kind of SASL implementations  
> are
> out there.  Are there implementations that do not support GS2/GSS?

Yes.  For instance, it's fairly common to implement a basic SASL  
implementation when one only requires simple SASL mechanisms (e.g.,  
EXTERNAL, PLAIN, CRAM-MD5).  [I've done this myself a couple of  
times.]  I would hope that SCRAM would have similar complexity to CRAM- 
MD5, and hence implementable quite independently of so-called "SASL  
libraries" and GS2 and GSS-API frameworks.

-- Kurt

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 16 Feb 2009 18:26:43 +0100
To: Kurt Zeilenga <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

Kurt Zeilenga writes:
> Draft-newman-auth-scram-gs2-00.txt contains a normative reference to
> draft-ietf-sasl-gs2-10.txt.  This implies an implementor must read and
> understand draft-ietf-sasl-gs2-10.txt, as well as elements of its
> normative references, in order to implement the protocol.  (I doubt
> this normative reference can be downgraded.)

Yes, looks like it.  That's the main problem for a non-GSS person like
me.  There might be only a small amount of GS2 semanics which needs to
be implemented, but if so it looks like I'd still have to read and
understand GS2 and GSS-API to figure that out.  OK, so I've begun to
read up on GS2 anyway, but still...

For SCRAM-GS2 to be pure-SASL friendly, what one needs to understand
about the GS2 part needs to be collected in one place.  Either in
SCRAM-GS2 or in a section of GS2, so SCRAM-GS2 can refer to just that
section.  Then the complexity argument about SCRAM-GS2 is reduced to its
technical complexity, which I don't know yet.

I would oppose a SCRAM-GS2 document which didn't do that.  OTOH it's
fine by me if the current draft is just a draft for a draft which will,
to have a poll about among those who know what the final document set
would look like.

BTW, if the GS2 folk write up that and present it for a new poll or
whatever, I'm not suggesting to put a lot of work into getting the
details right at first try.  After all comments here suggest it may
well be rejected anyway.

Regarding where to put the GS2 part, I'm staying with my original
comments.  Maybe I had picked up a bit more about GS2 than I realized.
GS2 seems to me the natural place for the normative part, maybe copied
to a SCRAM-GS2 informative section.  Of course it would be a bit better
to know what it would look like before saying that:-)

Actually complexity might be an argument _for_ placing it in GS2.
Otherwise future mechanisms that try to bridge pure SASL and GS2 must
copy or re-do that work from SCRAM.  The trick would be to make it loose
enough that it's not another layer SCRAM will exist inside, but just
some stuff SCRAM makes use of like it makes use of Base64 and HMAC.

Since SCRAM-GS2 effectively will have 2 specs which are supposed to
interoprate, I suggest to stick to the old IETF "2 implementations" rule
on this one.  Set up one pure-SASL and one GSS-API version of SCRAM-GS2
and let us see them interoperate.  If the author of the pure-SASL mech
doesn't know GS2, so much the better.

One reality check: I have no idea what kind of SASL implementations are
out there.  Are there implementations that do not support GS2/GSS?  Or
is the technical complexity a storm in a teacup because implementations
will have GS2 for the sake of Kerberos?

-- 
Hallvard

Date: Sun, 15 Feb 2009 16:24:38 -0600
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Paul Leach <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

On Sun, Feb 15, 2009 at 09:01:19PM +0000, Alexey Melnikov wrote:
> Paul Leach wrote:
> 
> >BTW: has anyone thought about use of SCRAM with HTTP?
> > 
> >
> Yes, but not in details. The protocol should be easily extensible to HTTP.

You may have missed the point that Paul was, I think, trying to make.

Given HTTP/Negotiate (and the new version of it) a GSS-API mechanism
would fit right in in HTTP.  Thus SCRAM-as-GS2 is ideal for HTTP, but
SCRAM-as-not-GS2 is not as that would require either adapting it to
HTTP, to the GSS-API, or extending HTTP to support SASL.

The re-use aspect of SCRAM-as-GS2 is not a silly whim, or idealism -- it
will really help those of us who implement both, GSS-API application
protocols, such as DNS (see GSS-TSIG), CIFS/SMB, NFS, SSHv2, FTP, HTTP,
and so on, and SASL apps, such as LDAP, IMAP, SMTP, etcetera.

Nico
-- 

Date: Sun, 15 Feb 2009 21:01:19 +0000
From: Alexey Melnikov <[email-masked]>
To: Paul Leach <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

Paul Leach wrote:

>BTW: has anyone thought about use of SCRAM with HTTP?
>  
>
Yes, but not in details. The protocol should be easily extensible to HTTP.

Date: Sun, 15 Feb 2009 17:11:50 +0000
From: Alexey Melnikov <[email-masked]>
To: SASL WG <[email-masked]>
Subject: [Fwd: I-D Action:draft-newman-auth-scram-09.txt]
Sender: [email-masked]

--------------030907080205080004000202
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I've updated the pure-SCRAM document to match more closely the GS2 
variant. In particular I fixed ABNF for channel-binding and moved SASL 
authorization identity to the second message from the client.

--------------030907080205080004000202
Content-Type: message/rfc822;
 name="I-D Action:draft-newman-auth-scram-09.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="I-D Action:draft-newman-auth-scram-09.txt"

From: [email-masked]
To: [email-masked]
Subject: I-D Action:draft-newman-auth-scram-09.txt 
Date: Sun, 15 Feb 2009 06:15:01 -0800 (PST)
Reply-To: [email-masked]
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Salted Challenge Response (SCRAM) SASL Mechanism
	Author(s)       : A. Menon-Sen, et al.
	Filename        : draft-newman-auth-scram-09.txt
	Pages           : 18
	Date            : 2009-02-15

The secure authentication mechanism most widely deployed and used by
 Internet application protocols is the transmission of clear-text
 passwords over a channel protected by Transport Layer Security
 (TLS).  There are some significant security concerns with that
 mechanism, which could be addressed by the use of a challenge
 response authentication mechanism protected by TLS. Unfortunately,
 the challenge response mechanisms presently on the standards track
 all fail to meet requirements necessary for widespread deployment,
 and have had success only in limited use.

 This specification describes a family of authentication mechanisms
 called the Salted Challenge Response Authentication Mechanism
 (SCRAM), which addresses the security concerns and meets the
 deployability requirements. When used in combination with TLS or an
 equivalent security layer, a mechanism from this family could
 improve the status-quo for application protocol authentication and
 provide a suitable choice for a mandatory-to-implement mechanism for
 future application protocol standards.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-newman-auth-scram-09.txt

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

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

--NextPart
Content-Type: Message/External-body;
	name="draft-newman-auth-scram-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--NextPart--

--------------030907080205080004000202--

Date: Sun, 15 Feb 2009 13:34:21 +0000
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: [email-masked]
Subject: Re: ABNF for the three cases of SCRAM as GS2
Sender: [email-masked]

Hallvard B Furuseth wrote:

>Alexey Melnikov wrote:
>  
>
>>Hallvard B Furuseth wrote:
>>
>>>Also, how does an iteration count of more than 1 help on a site where
>>>passwords are stored in several forms anyway, maybe including salted MD5
>>>for Unix crypt()?  (Maybe that's for Appendix B or C, I don't know.)
>>>      
>>>
>>My understanding is that one can read values from hashed password files
>>and use them to implement server side SCRAM.
>>There is no requirement that SCRAM specific hash be stored in such files.
>>    
>>
>That sounds strange, unless you are talking about a weakness which can
>be attacked.
>
>The password-file secret would be
>  salt, Hash(salt || password)
>while even with iteration count 0, SCRAM SaltedPassword is
>  Hash((password XOR opad) || Hash((password XOR ipad) || salt || INT(1)))
>
You are right.
I've checked earlier versions of both SCRAM and HEXA and neither of them 
mentioned use in Unix hashed password databases.
So this was just my wishful thinking.

>In any case, if there is a mapping MD5 crypt -> SCRAM crypt, that just
>makes the iteration count less useful as far as I can see.
>  
>

From: Paul Leach <[email-masked]>
To: Nicolas Williams <[email-masked]>, Simon Josefsson <[email-masked]>
CC: Arnt Gulbrandsen <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Date: Thu, 12 Feb 2009 21:39:10 -0800
Subject: RE: Poll: pure SCRAM versa SCRAM-as-GS2
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

I've only been lurking here, and can't claim to understand everything very =
deeply, but I can state pretty positively that if SCRAM becomes the mandato=
ry-to-implement auth mechanism for a bunch of protocols, then we're very mu=
ch prefer to implement it via the GS2 route, and not have to do it twice.

BTW: has anyone thought about use of SCRAM with HTTP?

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 13 Feb 2009 00:29:26 +0100
To: Nicolas Williams <[email-masked]>
Cc: Kurt Zeilenga <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

Nicolas Williams writes:
>On Tue, Feb 10, 2009 at 10:17:35PM +0100, Hallvard B Furuseth wrote:
>(...snip...)
>
>> Is there a summary somewhere of why things are done this way?
> There is above.  If the I-Ds don't capture this, they probably should.

Thank you, nice summary.  Yes, the I-Ds should definitely capture this.

-- 
Hallvard

Date: Thu, 12 Feb 2009 09:03:13 -0600
From: Nicolas Williams <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>, Simon Josefsson <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

On Thu, Feb 12, 2009 at 04:00:33PM +0100, Arnt Gulbrandsen wrote:
> Nicolas Williams writes:
> >We're trying to avoid having to implement SCRAM for SASL and SCRAM for 
> >GSS-API, but rather, implement one or the other, but not both.
> 
> Oh... and the big problem is that people clearly want one of those, but 
> noone seems to want the other very much, so what's the point?

The point is to make it so you, a pure SASL implementor, can implement a
pure-SASL SCRAM that happens to interop with the SCRAM implemented by a
SASL/GS2 implementor as a GSS-API mechanism.

Date: Thu, 12 Feb 2009 16:00:33 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>, Simon Josefsson <[email-masked]>
Sender: [email-masked]

Nicolas Williams writes:
> We're trying to avoid having to implement SCRAM for SASL and SCRAM for 
> GSS-API, but rather, implement one or the other, but not both.

Oh... and the big problem is that people clearly want one of those, but 
noone seems to want the other very much, so what's the point?

Arnt

Date: Thu, 12 Feb 2009 08:22:45 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Arnt Gulbrandsen <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

On Thu, Feb 12, 2009 at 11:23:37AM +0100, Simon Josefsson wrote:
> Nicolas Williams <[email-masked]> writes:
> > I don't see the point.  If we drop SCRAM-as-GS2 then GS2 will be useful
> > only for the krb5 mech, and will likely never be used again: the
> > precedent will be clear that no one will care to build mechanisms for
> > one framework and then have then automatically available for the other,
> > thus it will never be done for any other mechanisms.
> 
> I'm less convinced of that.  I want to see a password-based GSS-API
> mechanism, which would be possible to use in SASL via GS2, so there will
> be at least one.  I agree pure-SASL-SCRAM would set a precedent, but I
> don't think it will prevent future work towards merging the GSS-API and
> SASL frameworks.

Why have multiple equivalent password-based mechanisms for SASL?

No, if SCRAM-as-not-GS2 happens then it'd be a safe bet that GS2 will
only ever be used for Kerberos V.

Date: Thu, 12 Feb 2009 08:20:43 -0600
From: Nicolas Williams <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>, Simon Josefsson <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

On Thu, Feb 12, 2009 at 02:03:29PM +0100, Arnt Gulbrandsen wrote:
> Nicolas Williams writes:
> >If we drop SCRAM-as-GS2 then GS2 will be useful only for the krb5 
> >mech, and will likely never be used again: the precedent will be 
> >clear that no one will care to build mechanisms for one framework and 
> >then have then automatically available for the other, thus it will 
> >never be done for any other mechanisms.
> 
> Now I understand what you mean: You want to use SCRAM to get the kinks 
> out of GS2 and make sure that GS2 works in practice, right?

No, that's not it.  We're trying to avoid having to implement SCRAM for
SASL and SCRAM for GSS-API, but rather, implement one or the other, but
not both.

If you're a SASL implementor whose SASL implementation has no GS1 (the
original "GSSAPI" SASL mech in RFC2222) then you'd implement SCRAM as a
pure SASL mech, which would interop with any implementation of SCRAM as
a GSS-API mechanism used in SASL via GS2.

Nico
-- 

Date: Thu, 12 Feb 2009 14:03:29 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>, Simon Josefsson <[email-masked]>
Sender: [email-masked]

Nicolas Williams writes:
> If we drop SCRAM-as-GS2 then GS2 will be useful only for the krb5 
> mech, and will likely never be used again: the precedent will be 
> clear that no one will care to build mechanisms for one framework and 
> then have then automatically available for the other, thus it will 
> never be done for any other mechanisms.

Now I understand what you mean: You want to use SCRAM to get the kinks 
out of GS2 and make sure that GS2 works in practice, right?

I don't think SCRAM is a great driver for GS2, then. GS2 wants something 
that is needed on both sides of the fence, and will be scrutinised and 
used on both sides. SCRAM's needed very much more on the SASL side.

But I'll spend some time on SCRAM-GS2. Even if it doesn't help SCRAM it 
can help you, and now I'm not afraid of a quagmire thread any more.

Arnt

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Arnt Gulbrandsen <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 12 Feb 2009 11:23:37 +0100
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Wed, Feb 11, 2009 at 01:55:49PM +0100, Simon Josefsson wrote:
>> > I do hope GS2 has a purpose in life other than to support SCRAM, though.
>> 
>> Definitely.  My main motivation to work on it has been to bridge
>> together SASL and GSS-API.  Another has been to improve Kerberos V5
>> authentication by reducing round-trips.  A third is to add channel
>> binding support, which makes it possible to re-use TLS for security
>> layer with Kerberos V5.
>
> I don't see the point.  If we drop SCRAM-as-GS2 then GS2 will be useful
> only for the krb5 mech, and will likely never be used again: the
> precedent will be clear that no one will care to build mechanisms for
> one framework and then have then automatically available for the other,
> thus it will never be done for any other mechanisms.

I'm less convinced of that.  I want to see a password-based GSS-API
mechanism, which would be possible to use in SASL via GS2, so there will
be at least one.  I agree pure-SASL-SCRAM would set a precedent, but I
don't think it will prevent future work towards merging the GSS-API and
SASL frameworks.

/Simon

Date: Wed, 11 Feb 2009 10:44:41 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Arnt Gulbrandsen <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

On Wed, Feb 11, 2009 at 01:55:49PM +0100, Simon Josefsson wrote:
> > I do hope GS2 has a purpose in life other than to support SCRAM, though.
> 
> Definitely.  My main motivation to work on it has been to bridge
> together SASL and GSS-API.  Another has been to improve Kerberos V5
> authentication by reducing round-trips.  A third is to add channel
> binding support, which makes it possible to re-use TLS for security
> layer with Kerberos V5.

I don't see the point.  If we drop SCRAM-as-GS2 then GS2 will be useful
only for the krb5 mech, and will likely never be used again: the
precedent will be clear that no one will care to build mechanisms for
one framework and then have then automatically available for the other,
thus it will never be done for any other mechanisms.

Cc: Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Simon Josefsson <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Wed, 11 Feb 2009 05:20:33 -0800
Sender: [email-masked]

On Feb 11, 2009, at 4:48 AM, Simon Josefsson wrote:

> Nicolas Williams <[email-masked]> writes:
>
>> On Tue, Feb 10, 2009 at 01:14:06PM -0800, Kurt Zeilenga wrote:
>>> On Feb 10, 2009, at 12:12 PM, Nicolas Williams wrote:
>>>> In so far as security layers are optional, yes, but a) that has no
>>>> relationship to whether the implementation is a pure SASL one or a
>>>> GS2/GSS-API based one, and b) that should have no effect on
>>>> interoperability in the common case where SASL is run over TLS.
>>>
>>> Do you expect SASL-GS2 I-D to be revised to detail how to implement
>>> these security layer?

I should have said GS2-SCRAM I-D here.

That is, I was wondering what the GS2-SCRAM I-D not about GS2 I-D  
itself.

>> Given that SASL-GS2 security layers would be optional, but also  
>> that the
>> basis for an integrity protection layer being part of the SCRAM
>> internals for channel binding, IMO:
>>
>> - the spec should describe the integrity protection security layer
>> - the spec need not describe a privacy protection (encryption)  
>> security
>>   layer, which can then be provided by a separate I-D.
>
> I may be missing something, but the SASL GS2 document describes how  
> SASL
> security layers are implemented via GSS_Wrap/GSS_Unwrap.   
> Optionally, as
> you describe.

Date: Wed, 11 Feb 2009 14:03:48 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Simon Josefsson <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Cc: Alexey Melnikov <[email-masked]>, Nicolas Williams <[email-masked]>, SASL WG <[email-masked]>
Sender: [email-masked]

Simon Josefsson writes:
>>  I do hope GS2 has a purpose in life other than to support SCRAM, though.
>
> Definitely. My main motivation to work on it has been to bridge 
> together SASL and GSS-API. Another has been to improve Kerberos V5 
> authentication by reducing round-trips. A third is to add channel 
> binding support, which makes it possible to re-use TLS for security 
> layer with Kerberos V5.

Glad to hear that.

Arnt

From: Simon Josefsson <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 11 Feb 2009 13:55:49 +0100
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> writes:

> I do hope GS2 has a purpose in life other than to support SCRAM, though.

Definitely.  My main motivation to work on it has been to bridge
together SASL and GSS-API.  Another has been to improve Kerberos V5
authentication by reducing round-trips.  A third is to add channel
binding support, which makes it possible to re-use TLS for security
layer with Kerberos V5.

/Simon

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Hallvard B Furuseth <[email-masked]>, Kurt Zeilenga <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 11 Feb 2009 13:52:15 +0100
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> The background, briefly:
>
>  - there exists SASL, with which you are familiar
>
>  - there also exists the GSS-API, with which you are not
>
>  - the two are very similar
>
>  - yet also different enough that mechanisms for one are usually not
>    available for the other
>
>  - we are annoyed by this
>
>  - we want to fix this
>
>  - enter GS1 (the GSS part of RFC2222), the first attempt to bridge SASL
>    and the GSS-API
>
>     - the differences between the two frameworks, SASL and the GSS-API,
>       are such that the GSS-API is the more general framework, which
>       means it's easier to make GSS mechanisms available to SASL than
>       the reverse
>
>  - GS1 has problems that we'd like to fix
>
>  - enter MD5's breaks
>
>  - we also want a replacement for DIGEST/CRAM-MD5
>
> The proposal, briefly:
>
>  - create a replacement for GS1, which we'll call GS2
>
>  - create a replacement for DIGEST/CRAM-MD5, which we'll call SCRAM
>
>  - make SCRAM a GSS-API mechanism so it can be used in GSS-API apps and,
>    through GS2, SASL apps
>
>  - BUT, because the SASL crowd generally looks askance at the GSS-API
>    and has balked at a pure-GSS-API SCRAM to be used through GS2...
>
>    ...we've also decided to describe SCRAM as a pure SASL mechanism that
>    just happens to match, on the wire, what a GSS-API mechanism used in
>    SASL via GS2 would look like.

Very good summary, I think this clears up many things that may have been
poorly understood so far.

What seems to be missing is a document that describes SCRAM as a GSS-API
mechanism.  I talked with Alexey at FOSDEM and got the nroff source to
SCRAM, so I am working on preparing such a document.  When we have a
concrete document, the pure-SASL crowd can evaluate whether the
perceived complexities with SCRAM-via-GS2 are real or not.

/Simon

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Kurt Zeilenga <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 11 Feb 2009 13:48:15 +0100
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Tue, Feb 10, 2009 at 01:14:06PM -0800, Kurt Zeilenga wrote:
>> On Feb 10, 2009, at 12:12 PM, Nicolas Williams wrote:
>> >In so far as security layers are optional, yes, but a) that has no
>> >relationship to whether the implementation is a pure SASL one or a
>> >GS2/GSS-API based one, and b) that should have no effect on
>> >interoperability in the common case where SASL is run over TLS.
>> 
>> Do you expect SASL-GS2 I-D to be revised to detail how to implement  
>> these security layer?
>
> Given that SASL-GS2 security layers would be optional, but also that the
> basis for an integrity protection layer being part of the SCRAM
> internals for channel binding, IMO:
>
>  - the spec should describe the integrity protection security layer
>  - the spec need not describe a privacy protection (encryption) security
>    layer, which can then be provided by a separate I-D.

I may be missing something, but the SASL GS2 document describes how SASL
security layers are implemented via GSS_Wrap/GSS_Unwrap.  Optionally, as
you describe.

/Simon

Date: Wed, 11 Feb 2009 11:31:01 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Sender: [email-masked]

Nicolas Williams writes:
> No one is saying what the specific problems are, and we in the 
> SCRAM-as-GS2-mech crowd have bent over backwards trying to identify 
> those problems and then change GS2 so as to make those problems go 
> away, but our only reward is "I only want a refinement of 
> DIGEST/CRAM-MD5."

Would you expect otherwise?

Digest-MD5's interoperability problems aren't going away and MD5 is 
growing weaker by the month, so I think it's perfectly natural to want 
a C/D-MD5 replacement and want that strongly.

As far as I could tell by reading the documents, GS2 doesn't _help_ 
SCRAM towards being as widely implemented as C/D-MD5. The question is: 
a) Does it harm? b) Does it harm too much? And you want me (and others) 
to answer c) What specifically harms?.

My answers are: a) Yes, it harms. b) It harms enough that I wasn't sure 
whether the two drafts described the same mechanism (ignoring 
differences in constant strings) and I have a theory that other people 
are about as stupid as I am. One implication of that is that if I can't 
comprehend a document with reasonable effort, then that document is too 
demanding of its readers. If the document is too demanding of its 
readers, then it harms SCRAM too much. So yes.

Given the "yes" to b), spending time on question c) is really a fool's 
errand for me. I'm not interested in GS2 and answering c) properly 
seems like it would take a lot of time, and that after spending that 
time I'd sit there discussing how to harm SCRAM less while still 
harming it. I'd MUCH rather not spend the time, not harm SCRAM at all 
and not get into that discussion.

> What really bugs me is that outside Chris we've had very, very little 
> help in making SCRAM acceptable to the SCRAM-as-pure-SASL-mech crowd. 
> Thus I think Sam, Simon, myself and others have basically spent 
> enormous amounts of time only to have this poll on whether we're now 
> going to throw that out the window.

True.

I do hope GS2 has a purpose in life other than to support SCRAM, though.

FWIW, I did try to open my mouth a couple of years ago. Someone told me 
"I think it can be written well enough" and I had no way to answer 
that. So I shut up and stepped away. I apologise for not trying harder 
to find a third way.

>>  I don't know which things people find difficult and would like to 
>>  find out. Or rather I would not tell my opinion until I hear some 
>>  feedback.
>
> We will never be told.

If could could come up with an argument that GS2 would make SCRAM be 
easier to implement and more widely implemented, I think you would.

Arnt

Date: Tue, 10 Feb 2009 22:29:59 -0600
From: Nicolas Williams <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
Cc: Kurt Zeilenga <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

On Tue, Feb 10, 2009 at 10:17:35PM +0100, Hallvard B Furuseth wrote:
> Nicolas Williams writes:
> > The normative reference is needed because though scram-gs2 is not
> > described as a GSS-API mechanism it needs to conform to GS2, and that
> > is only relevant to GS2 implementors, whereas SCRAM implementors who
> > don't have a GSS-API implementation need not implement GS2.
> 
> Speaking as someone who has not followed the GSS-API discussions,
> that sure confuses me.  I don't understand what this draft is doing,
> so presumably I still wouldn't if I encountered it as an RFC.

OK.

The background, briefly:

 - there exists SASL, with which you are familiar

 - there also exists the GSS-API, with which you are not

 - the two are very similar

 - yet also different enough that mechanisms for one are usually not
   available for the other

 - we are annoyed by this

 - we want to fix this

 - enter GS1 (the GSS part of RFC2222), the first attempt to bridge SASL
   and the GSS-API

    - the differences between the two frameworks, SASL and the GSS-API,
      are such that the GSS-API is the more general framework, which
      means it's easier to make GSS mechanisms available to SASL than
      the reverse

 - GS1 has problems that we'd like to fix

 - enter MD5's breaks

 - we also want a replacement for DIGEST/CRAM-MD5

The proposal, briefly:

 - create a replacement for GS1, which we'll call GS2

 - create a replacement for DIGEST/CRAM-MD5, which we'll call SCRAM

 - make SCRAM a GSS-API mechanism so it can be used in GSS-API apps and,
   through GS2, SASL apps

 - BUT, because the SASL crowd generally looks askance at the GSS-API
   and has balked at a pure-GSS-API SCRAM to be used through GS2...

   ...we've also decided to describe SCRAM as a pure SASL mechanism that
   just happens to match, on the wire, what a GSS-API mechanism used in
   SASL via GS2 would look like.

> Also I haven't caught the motivation for the combined SASL + GSS-API
> draft.  People have mentioned code reuse, I don't know if there is
> anything else.

And specification reuse.

> Is there a summary somewhere of why things are done this way?

There is above.  If the I-Ds don't capture this, they probably should.

Nico
-- 

Date: Tue, 10 Feb 2009 15:22:36 -0600
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

On Tue, Feb 10, 2009 at 01:14:06PM -0800, Kurt Zeilenga wrote:
> On Feb 10, 2009, at 12:12 PM, Nicolas Williams wrote:
> >In so far as security layers are optional, yes, but a) that has no
> >relationship to whether the implementation is a pure SASL one or a
> >GS2/GSS-API based one, and b) that should have no effect on
> >interoperability in the common case where SASL is run over TLS.
> 
> Do you expect SASL-GS2 I-D to be revised to detail how to implement  
> these security layer?

Given that SASL-GS2 security layers would be optional, but also that the
basis for an integrity protection layer being part of the SCRAM
internals for channel binding, IMO:

 - the spec should describe the integrity protection security layer
 - the spec need not describe a privacy protection (encryption) security
   layer, which can then be provided by a separate I-D.

Nico
-- 

Date: Tue, 10 Feb 2009 15:20:20 -0600
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Kurt Zeilenga <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

On Tue, Feb 10, 2009 at 09:06:25PM +0000, Alexey Melnikov wrote:
> Nicolas Williams wrote:
> >Certainly "neither" is not a good answer, because then there'd be no
> >authoritative specification :)
> >
> >However, SCRAM-as-GS2 must stand on its own if pure-SASL implementors
> >are to be happy, yet it needs to conform to GS2 if we are to have
> >interop with SASL/GS2 implementors.
> 
> I agree with both statements.
> 
> >>I would argue that if we further pursue the scram-gs2 approach, I  
> >>would favor the approach suggested by Simon.  That is, SCRAM-GS2 be  
> >>informational.   I would add that SCRAM-GS2 should include text that  
> >>clearly states it is not definitive.
> >
> >I'd be happy with that.
> >
> I would be less happy about that and I don't think a statement like this 
> is going to be helpful, even if it is true.

Indeed, my next paragraph foresaw such a reaction.

Which is why I think that a SCRAM-as-GS2-but-described-normatively-
only-as-pure-SASL approach is the best approach: it puts the burden on
the GS2 implementors to ensure that the SCRAM specification is indeed
interoperable with GS2 and does allow for a SCRAM GSS-API mechanism.

And all without burdening pure-SASL implementors with having to read and
understand GS2 nor the GSS-API.

That is a compromise which I think we in the GS2 camp must be willing to
make in order to get SCRAM-as-GS2.  Otherwise we'd be asking too much of
the pure SASL crowd.

> >But pure SASL implementors might not be, in
> >which case we'll need to make a) the SCRAM specification independent of
> >GS2 yet b) conformant to it.  I have long assumed we'd have to do just
> >that.

Nico
-- 

Cc: Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Tue, 10 Feb 2009 13:25:24 -0800
Sender: [email-masked]

On Feb 10, 2009, at 1:17 PM, Hallvard B Furuseth wrote:

> Will a GSS-API mech be defined retoractively so it fits the SASM mech?
> It seems quite backwards for a GS2-* mech, instead of defining a GSS- 
> API
> mechanism first and SCRAM-GS2 on top of it.

I think it would be unwise to push GS2-SCRAM forward without the  
definitive specification it mimics being complete.

-- Kurt

From: Hallvard B Furuseth <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Kurt Zeilenga <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Tue, 10 Feb 2009 22:23:47 +0100
Sender: [email-masked]

I wrote:
> Some uninformed ramblings follow anyway.  Feel free to interpret this
> as just a list of things that need to be summarized/clarified in the
> GS2-SASL document.  But in the mailinglist too if the poll is also
  ^^^^^^^^
Sorry, GS2-SCRAM document.

> addressed to people like me who haven't followed GS2.

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 10 Feb 2009 22:17:35 +0100
To: Nicolas Williams <[email-masked]>
Cc: Kurt Zeilenga <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

Nicolas Williams writes:
> The normative reference is needed because though scram-gs2 is not
> described as a GSS-API mechanism it needs to conform to GS2, and that
> is only relevant to GS2 implementors, whereas SCRAM implementors who
> don't have a GSS-API implementation need not implement GS2.

Speaking as someone who has not followed the GSS-API discussions,
that sure confuses me.  I don't understand what this draft is doing,
so presumably I still wouldn't if I encountered it as an RFC.

Also I haven't caught the motivation for the combined SASL + GSS-API
draft.  People have mentioned code reuse, I don't know if there is
anything else.

Is there a summary somewhere of why things are done this way?

Some uninformed ramblings follow anyway.  Feel free to interpret this
as just a list of things that need to be summarized/clarified in the
GS2-SASL document.  But in the mailinglist too if the poll is also
addressed to people like me who haven't followed GS2.

This document doesn't define a GSS-API mechanism, so what is it doing?
Will a GSS-API mech be defined retoractively so it fits the SASM mech?
It seems quite backwards for a GS2-* mech, instead of defining a GSS-API
mechanism first and SCRAM-GS2 on top of it.

Nor does it appear to define a valid SASL GS2 mechanism, since it barely
spells out any GS2/GSS-API semantics.  At least, I presume these do have
some semantics which will need to affect a SASL mechanism - but maybe
there is so little of it that it can mostly be reduced to grammar, like
this draft does?  Seems likely enough for producing SCRAM-GS2 messages,
but it'd need to handle incoming messages from a full GSS-API SCRAM too.
If it already does, the draft needs to reassure readers on that.

Also, what happens when GS2 gets updated/obsoleted?  Does SCRAM and
other mechanisms that are defined the same way get left behind?

So all in all it seems strange to put this in the SCRAM spec.  Looks
like a better place would be for the GS2 spec to have a section on how
one could design and implement a SASL GS2 mechanism without bothering
with GSS-API.  With a template mechanism grammar, maybe.  Then SCRAM
could defer to that, and maybe import it as an informative appendix.

Yes, I know that makes the document more complex, but it seems the
proper way to do a GS2-* SCRAM to me.

If we instead are to have separate SASL SCRAM and GSS-API SCRAMs, an
alternative I haven't seen mentioned would be to design SCRAM so that
the GSS-API variant could be coded as if it were an extension to SASL
SCRAM.  These mechs would have different names: "SCRAM" vs "GS2-xxxx".
I don't know if that fits the motivation for trying to join the
documents though.

Anyway, this would first mean to make plain SCRAM as GS2-friendly as
possible.  (Again, it might help for GS2 to have a "how to define a
GS2-friendly SASL mechanism" section.)  It'd need a more flexible
extension mechanism than m=, but that should be simple.  I'll be
getting back to 'm=' later anyway, now that I finally understand it.

-- 
Hallvard

Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Tue, 10 Feb 2009 13:14:06 -0800
Sender: [email-masked]

On Feb 10, 2009, at 12:12 PM, Nicolas Williams wrote:

>
> On Tue, Feb 10, 2009 at 11:48:58AM -0800, Kurt Zeilenga wrote:
>>
>> On Feb 10, 2009, at 9:58 AM, Nicolas Williams wrote:
>>
>>>
>>> On Tue, Feb 10, 2009 at 09:55:31AM -0800, Kurt Zeilenga wrote:
>>>>
>>>> On Feb 10, 2009, at 7:59 AM, Nicolas Williams wrote:
>>>>
>>>>>
>>>>> On Mon, Feb 09, 2009 at 01:09:43PM -0800, Kurt Zeilenga wrote:
>>>>>> I would have assumed one difference between these two  
>>>>>> approaches is
>>>>>> that if SCRAM were implemented as a GSA-API, the GS2- variant  
>>>>>> would
>>>>>> be
>>>>>> capable of providing a SASL security layer.  If that were so,  
>>>>>> this
>>>>>> would lead to a significant interoperability problem as there  
>>>>>> would
>>>>>> be
>>>>>> two classes of support:
>>>>>> 	non-GSS-API implementations: no security layer (use TLS)
>>>>>> 	GSS-API implementations: GS2 security layer
>>>>>
>>>>> Nope.
>>>>
>>>> Then I might consider GS2-SCRAM as incomplete.  Given the goal that
>>>> GSS-API SCRAM be generally usable outside of SASL, it seems
>>>> appropriate for GSS-API SCRAM to support GSS-API wrapping.
>>>
>>> You misunderstood.  SCRAM would have GSS-API per-message tokens, but
>>> they'd be not needed in the common case (when TLS is used, and,
>>> therefore, channel binding is sufficient), thus optional.
>>
>> Will GS2-SCRAM provide a SASL security layer or not?
>
> Yes, but it's optional.  It's expected that the vast majority of the
> time channel binding to TLS will suffice.
>
>> If yes, then I think we'll have two distinct class of  
>> implementations.
>
> In so far as security layers are optional, yes, but a) that has no
> relationship to whether the implementation is a pure SASL one or a
> GS2/GSS-API based one, and b) that should have no effect on
> interoperability in the common case where SASL is run over TLS.

Do you expect SASL-GS2 I-D to be revised to detail how to implement  
these security layer?

-- Kurt

Date: Tue, 10 Feb 2009 21:06:25 +0000
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Kurt Zeilenga <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

Nicolas Williams wrote:

>On Tue, Feb 10, 2009 at 12:17:32PM -0800, Kurt Zeilenga wrote:
>  
>
>>Question regarding the GS2-SCRAM specification.
>>
>>I see no language in draft-newman-auth-scram-gs2-00.txt which says  
>>whether it or the specifications detailing the SASL-GS2, GSS-API, GSS- 
>>API-SCRAM are definitive.
>>
>>Which will be?
>>
>>I don't think 'neither' or 'both' is an appealing (to me) answer here.
>>    
>>
>Certainly "neither" is not a good answer, because then there'd be no
>authoritative specification :)
>
>However, SCRAM-as-GS2 must stand on its own if pure-SASL implementors
>are to be happy, yet it needs to conform to GS2 if we are to have
>interop with SASL/GS2 implementors.
>  
>
I agree with both statements.

>>I would argue that if we further pursue the scram-gs2 approach, I  
>>would favor the approach suggested by Simon.  That is, SCRAM-GS2 be  
>>informational.   I would add that SCRAM-GS2 should include text that  
>>clearly states it is not definitive.
>>    
>>
>I'd be happy with that.
>
I would be less happy about that and I don't think a statement like this 
is going to be helpful, even if it is true.

>But pure SASL implementors might not be, in
>which case we'll need to make a) the SCRAM specification independent of
>GS2 yet b) conformant to it.  I have long assumed we'd have to do just
>that.
>  
>

Date: Tue, 10 Feb 2009 14:35:32 -0600
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

On Tue, Feb 10, 2009 at 12:17:32PM -0800, Kurt Zeilenga wrote:
> Question regarding the GS2-SCRAM specification.
> 
> I see no language in draft-newman-auth-scram-gs2-00.txt which says  
> whether it or the specifications detailing the SASL-GS2, GSS-API, GSS- 
> API-SCRAM are definitive.
> 
> Which will be?
> 
> I don't think 'neither' or 'both' is an appealing (to me) answer here.

Certainly "neither" is not a good answer, because then there'd be no
authoritative specification :)

However, SCRAM-as-GS2 must stand on its own if pure-SASL implementors
are to be happy, yet it needs to conform to GS2 if we are to have
interop with SASL/GS2 implementors.

> I would argue that if we further pursue the scram-gs2 approach, I  
> would favor the approach suggested by Simon.  That is, SCRAM-GS2 be  
> informational.   I would add that SCRAM-GS2 should include text that  
> clearly states it is not definitive.

I'd be happy with that.  But pure SASL implementors might not be, in
which case we'll need to make a) the SCRAM specification independent of
GS2 yet b) conformant to it.  I have long assumed we'd have to do just
that.

Nico
-- 

Date: Tue, 10 Feb 2009 14:12:45 -0600
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

On Tue, Feb 10, 2009 at 11:48:58AM -0800, Kurt Zeilenga wrote:
> 
> On Feb 10, 2009, at 9:58 AM, Nicolas Williams wrote:
> 
> >
> >On Tue, Feb 10, 2009 at 09:55:31AM -0800, Kurt Zeilenga wrote:
> >>
> >>On Feb 10, 2009, at 7:59 AM, Nicolas Williams wrote:
> >>
> >>>
> >>>On Mon, Feb 09, 2009 at 01:09:43PM -0800, Kurt Zeilenga wrote:
> >>>>I would have assumed one difference between these two approaches is
> >>>>that if SCRAM were implemented as a GSA-API, the GS2- variant would
> >>>>be
> >>>>capable of providing a SASL security layer.  If that were so, this
> >>>>would lead to a significant interoperability problem as there would
> >>>>be
> >>>>two classes of support:
> >>>>	non-GSS-API implementations: no security layer (use TLS)
> >>>>	GSS-API implementations: GS2 security layer
> >>>
> >>>Nope.
> >>
> >>Then I might consider GS2-SCRAM as incomplete.  Given the goal that
> >>GSS-API SCRAM be generally usable outside of SASL, it seems
> >>appropriate for GSS-API SCRAM to support GSS-API wrapping.
> >
> >You misunderstood.  SCRAM would have GSS-API per-message tokens, but
> >they'd be not needed in the common case (when TLS is used, and,
> >therefore, channel binding is sufficient), thus optional.
> 
> Will GS2-SCRAM provide a SASL security layer or not?

Yes, but it's optional.  It's expected that the vast majority of the
time channel binding to TLS will suffice.

> If yes, then I think we'll have two distinct class of implementations.

In so far as security layers are optional, yes, but a) that has no
relationship to whether the implementation is a pure SASL one or a
GS2/GSS-API based one, and b) that should have no effect on
interoperability in the common case where SASL is run over TLS.

> If no, I think GS2-SCRAM is incomplete.

It's not incomplete, not in this sense.

Nico
-- 

Cc: SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Tue, 10 Feb 2009 12:17:32 -0800
Sender: [email-masked]

Question regarding the GS2-SCRAM specification.

I see no language in draft-newman-auth-scram-gs2-00.txt which says  
whether it or the specifications detailing the SASL-GS2, GSS-API, GSS- 
API-SCRAM are definitive.

Which will be?

I don't think 'neither' or 'both' is an appealing (to me) answer here.

I would argue that if we further pursue the scram-gs2 approach, I  
would favor the approach suggested by Simon.  That is, SCRAM-GS2 be  
informational.   I would add that SCRAM-GS2 should include text that  
clearly states it is not definitive.

-- Kurt

On Feb 5, 2009, at 1:14 PM, Alexey Melnikov wrote:

>
> Folks,
> I would like to solicit feedback from people regarding the choice  
> between 2 SCRAM versions:
> http://tools.ietf.org/id/draft-newman-auth-scram-08.txt
> and
> http://tools.ietf.org/id/draft-newman-auth-scram-gs2-00.txt
>
> You can use the following URL to see changes between them:
> http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-newman-auth-scram-08.txt&url2=http://tools.ietf.org/id/draft-newman-auth-scram-gs2-00.txt
>
> Please send your opinion on which version you prefer (and a short  
> explanation of why) to the mailing list, or say if you need more  
> information.
>
> I would like to get all answers before February 19th, please.
>
> Regards,
> Alexey
>

Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Tue, 10 Feb 2009 11:48:58 -0800
Sender: [email-masked]

On Feb 10, 2009, at 9:58 AM, Nicolas Williams wrote:

>
> On Tue, Feb 10, 2009 at 09:55:31AM -0800, Kurt Zeilenga wrote:
>>
>> On Feb 10, 2009, at 7:59 AM, Nicolas Williams wrote:
>>
>>>
>>> On Mon, Feb 09, 2009 at 01:09:43PM -0800, Kurt Zeilenga wrote:
>>>> I would have assumed one difference between these two approaches is
>>>> that if SCRAM were implemented as a GSA-API, the GS2- variant would
>>>> be
>>>> capable of providing a SASL security layer.  If that were so, this
>>>> would lead to a significant interoperability problem as there would
>>>> be
>>>> two classes of support:
>>>> 	non-GSS-API implementations: no security layer (use TLS)
>>>> 	GSS-API implementations: GS2 security layer
>>>
>>> Nope.
>>
>> Then I might consider GS2-SCRAM as incomplete.  Given the goal that
>> GSS-API SCRAM be generally usable outside of SASL, it seems
>> appropriate for GSS-API SCRAM to support GSS-API wrapping.
>
> You misunderstood.  SCRAM would have GSS-API per-message tokens, but
> they'd be not needed in the common case (when TLS is used, and,
> therefore, channel binding is sufficient), thus optional.

Will GS2-SCRAM provide a SASL security layer or not?

If yes, then I think we'll have two distinct class of implementations.
If no, I think GS2-SCRAM is incomplete.

-- Kurt

Date: Tue, 10 Feb 2009 12:05:12 -0600
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

On Tue, Feb 10, 2009 at 09:55:31AM -0800, Kurt Zeilenga wrote:
> On Feb 10, 2009, at 7:59 AM, Nicolas Williams wrote:
> >>Regardless of this, I simply don't thing scram-gs2 is "simple"  
> >>enough.
> >
> >Details.  Please provide details.
> 
> Of course, "simple" enough is quite subjective characteristic.   When  
> I first said this it was a gut reaction.  Here are some things which  
> lead me to my characterization of SCRAM-GS2 not being "simple" enough.

The WG has only been dealing with this for, what, two, three years, and
the chair is still going by gut reactions?

> Draft-newman-auth-scram-gs2-00.txt contains a normative reference to  
> draft-ietf-sasl-gs2-10.txt.  This implies an implementor must read and  
> understand draft-ietf-sasl-gs2-10.txt, as well as elements of its  
> normative references, in order to implement the protocol.  (I doubt  
> this normative reference can be downgraded.)

The normative reference is needed because though scram-gs2 is not
described as a GSS-API mechanism it needs to conform to GS2, and that is
only relevant to GS2 implementors, whereas SCRAM implementors who don't
have a GSS-API implementation need not implement GS2.

Thus this is not a real concern.

> The GS2 ABNF is twice as long.

Thank you, this is a relevant detail.  I'm not sure what we can do about
this, but I can take a look and see if there are simplifications we can
do.

> Not written in the GS2 specification, but needed to ensure broad
> adoption, is interoperability between the two classes of
> implementations.  Interoperability between classes of implementations
> is quite difficult to achieve in general, and the best way (I think)
> to avoid such interoperability problems is not to have classes of
> implementation.

SCRAM-as-GS2 is designed to be interoperable whether the implementor
chooses to implement it as a native SASL mechanism or as a GSS-API
mechanism used through GS2.

Nico
-- 

Date: Tue, 10 Feb 2009 11:58:51 -0600
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

On Tue, Feb 10, 2009 at 09:55:31AM -0800, Kurt Zeilenga wrote:
> 
> On Feb 10, 2009, at 7:59 AM, Nicolas Williams wrote:
> 
> >
> >On Mon, Feb 09, 2009 at 01:09:43PM -0800, Kurt Zeilenga wrote:
> >>I would have assumed one difference between these two approaches is
> >>that if SCRAM were implemented as a GSA-API, the GS2- variant would  
> >>be
> >>capable of providing a SASL security layer.  If that were so, this
> >>would lead to a significant interoperability problem as there would  
> >>be
> >>two classes of support:
> >>	non-GSS-API implementations: no security layer (use TLS)
> >>	GSS-API implementations: GS2 security layer
> >
> >Nope.
> 
> Then I might consider GS2-SCRAM as incomplete.  Given the goal that  
> GSS-API SCRAM be generally usable outside of SASL, it seems  
> appropriate for GSS-API SCRAM to support GSS-API wrapping.

You misunderstood.  SCRAM would have GSS-API per-message tokens, but
they'd be not needed in the common case (when TLS is used, and,
therefore, channel binding is sufficient), thus optional.

Nico
-- 

Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Tue, 10 Feb 2009 09:55:31 -0800
Sender: [email-masked]

On Feb 10, 2009, at 7:59 AM, Nicolas Williams wrote:

>
> On Mon, Feb 09, 2009 at 01:09:43PM -0800, Kurt Zeilenga wrote:
>> I would have assumed one difference between these two approaches is
>> that if SCRAM were implemented as a GSA-API, the GS2- variant would  
>> be
>> capable of providing a SASL security layer.  If that were so, this
>> would lead to a significant interoperability problem as there would  
>> be
>> two classes of support:
>> 	non-GSS-API implementations: no security layer (use TLS)
>> 	GSS-API implementations: GS2 security layer
>
> Nope.

Then I might consider GS2-SCRAM as incomplete.  Given the goal that  
GSS-API SCRAM be generally usable outside of SASL, it seems  
appropriate for GSS-API SCRAM to support GSS-API wrapping.

But for native SCRAM, I think it reasonable not to offer a mechanism  
given the implicit goal of keeping it simple (and hence relying solely  
relying TLS).

I see the goals of GS2-SCRAM and the goals of native SCRAM as somewhat  
divergent.

I'm not opposed to having both.  I rather have a simple native SASL/ 
SCRAM and a robust GSS-API SCRAM, then something which is neither.

> The idea was that because all these SASL apps rely on TLS today for
> session security what you'd do is SCRAM-as-GS2 with channel binding to
> TLS (wait for it: "channel binding is too complicated!" even though  
> it's
> just one more input into a hash/hmac that's already there and has to
> be).  Thus: no need for SASL/SCRAM security layers.
>
>> Regardless of this, I simply don't thing scram-gs2 is "simple"  
>> enough.
>
> Details.  Please provide details.

Of course, "simple" enough is quite subjective characteristic.   When  
I first said this it was a gut reaction.  Here are some things which  
lead me to my characterization of SCRAM-GS2 not being "simple" enough.

Draft-newman-auth-scram-gs2-00.txt contains a normative reference to  
draft-ietf-sasl-gs2-10.txt.  This implies an implementor must read and  
understand draft-ietf-sasl-gs2-10.txt, as well as elements of its  
normative references, in order to implement the protocol.  (I doubt  
this normative reference can be downgraded.)

The GS2 ABNF is twice as long.

Not written in the GS2 specification, but needed to ensure broad  
adoption, is interoperability between the two classes of  
implementations.  Interoperability between classes of implementations  
is quite difficult to achieve in general, and the best way (I think)  
to avoid such interoperability problems is not to have classes of  
implementation.

-- Kurt

Date: Tue, 10 Feb 2009 16:16:51 +0000
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Arnt Gulbrandsen <[email-masked]>, Simon Josefsson <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

Nicolas Williams wrote:

>On Sun, Feb 08, 2009 at 09:34:42AM +0100, Alexey Melnikov wrote:
>  
>
>>Arnt Gulbrandsen wrote:
>>    
>>
>>>As an alternative, might I suggest adding entirely separate, but 
>>>intentionally parallel, SCRAMs in GSS-API and SASL? No relationship as 
>>>far as protocol goes, but intentionally similar enough that libraries 
>>>which implement both can refactor the code (parsing etc. excepted).
>>>      
>>>
>>That would be fine with me. While this is not ideal, I think it would be 
>>much easier to agree on this in the WG.
>>    
>>
>This would make GS2 pointless.
>  
>
I wouldn't say it is pointless. The experiment of trying to make SCRAM 
be a GS2 thing is a very useful thing, no matter what the outcome with 
SCRAM would be.

Date: Tue, 10 Feb 2009 09:59:13 -0600
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

On Mon, Feb 09, 2009 at 01:09:43PM -0800, Kurt Zeilenga wrote:
> I would have assumed one difference between these two approaches is  
> that if SCRAM were implemented as a GSA-API, the GS2- variant would be  
> capable of providing a SASL security layer.  If that were so, this  
> would lead to a significant interoperability problem as there would be  
> two classes of support:
> 	non-GSS-API implementations: no security layer (use TLS)
> 	GSS-API implementations: GS2 security layer

Nope.

The idea was that because all these SASL apps rely on TLS today for
session security what you'd do is SCRAM-as-GS2 with channel binding to
TLS (wait for it: "channel binding is too complicated!" even though it's
just one more input into a hash/hmac that's already there and has to
be).  Thus: no need for SASL/SCRAM security layers.

> Regardless of this, I simply don't thing scram-gs2 is "simple" enough.

Details.  Please provide details.

Nico
-- 

Date: Tue, 10 Feb 2009 09:55:40 -0600
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

On Sun, Feb 08, 2009 at 09:26:20AM +0100, Alexey Melnikov wrote:
> Nicolas Williams wrote:
> >BUT, I don't understand this poll.  Why are we having it as opposed a
> >poll as to how to describe SCRAM?  Is it because SCRAM-as-GS2, even
> >described as a pure SASL mech, is too complicated?
> >
> I would say SCRAM-as-GS2 is slightly more complicated. I want to find 
> out what people think about the extra complexity.

No one is saying what the specific problems are, and we in the
SCRAM-as-GS2-mech crowd have bent over backwards trying to identify
those problems and then change GS2 so as to make those problems go away,
but our only reward is "I only want a refinement of DIGEST/CRAM-MD5."

What really bugs me is that outside Chris we've had very, very little
help in making SCRAM acceptable to the SCRAM-as-pure-SASL-mech crowd.
Thus I think Sam, Simon, myself and others have basically spent
enormous amounts of time only to have this poll on whether we're now
going to throw that out the window.

> Of course any input from people such as "if you change X to Y, or drop 
> Z, then the document would become reasonable", would be highly 
> constructive and would be appreciated.

Right, but that's not what's happening.

> >If so, what are the complicating issues that make it a deal breaker for 
> >others?
> 
> I don't know which things people find difficult and would like to find out.
> Or rather I would not tell my opinion until I hear some feedback.

We will never be told.

> >I have the feeling that instead of listing those issues and addressing
> >them we're just giving up.
> >
> I have so many free hours in any given day and I am afraid the two 
> proposals is the best I can do at the moment.
> Unless people will actively try to help me (by either making the choice 
> or by contributing some suggestions/text), I will give up very soon now.

We're not likely to come to an agreement.

I think instead we should all pursue whatever solution we think is
appropriate for our needs as individual I-Ds and see what happens.

Nico
-- 

Date: Tue, 10 Feb 2009 09:46:49 -0600
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Arnt Gulbrandsen <[email-masked]>, Simon Josefsson <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

On Sun, Feb 08, 2009 at 09:34:42AM +0100, Alexey Melnikov wrote:
> Arnt Gulbrandsen wrote:
> 
> >As an alternative, might I suggest adding entirely separate, but 
> >intentionally parallel, SCRAMs in GSS-API and SASL? No relationship as 
> >far as protocol goes, but intentionally similar enough that libraries 
> >which implement both can refactor the code (parsing etc. excepted).
> 
> That would be fine with me. While this is not ideal, I think it would be 
> much easier to agree on this in the WG.

This would make GS2 pointless.

Date: Tue, 10 Feb 2009 09:45:16 -0600
From: Nicolas Williams <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

On Fri, Feb 06, 2009 at 05:49:05PM +0100, Arnt Gulbrandsen wrote:
> Nicolas Williams writes:
> >BUT, I don't understand this poll. Why are we having it as opposed a 
> >poll as to how to describe SCRAM? Is it because SCRAM-as-GS2, even 
> >described as a pure SASL mech, is too complicated?
> 
> I think so.
> 
> >If so, what are the complicating issues that make it a deal breaker 
> >for others?
> 
> I don't care _what_ they are. Let me explain.
> 
> What I want is a replacement for digest-md5 and/or cram-md5, neither 
> more nor less. GS2 is entirely irrelevant to me, EXCEPT:

I have no interest in a refinement to either that cannot be used as a
GSS-API mechanism too.

Nico
-- 

Cc: SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Mon, 9 Feb 2009 13:09:43 -0800
Sender: [email-masked]

I would have assumed one difference between these two approaches is  
that if SCRAM were implemented as a GSA-API, the GS2- variant would be  
capable of providing a SASL security layer.  If that were so, this  
would lead to a significant interoperability problem as there would be  
two classes of support:
	non-GSS-API implementations: no security layer (use TLS)
	GSS-API implementations: GS2 security layer

Regardless of this, I simply don't thing scram-gs2 is "simple" enough.

I favor pursing publication of draft-newman-auth-scram-08.txt over  
draft-newman-auth-scram-gs2-00.txt for the SASL "SCRAM" mechanism.  I  
would not object to separate design/implementation of GSA-API SCRAM  
mechanism as I do think GSS-API needs something like SCRAM.

-- Kurt (chair hat off)

Date: Sun, 8 Feb 2009 17:17:25 -0800 (PST)
From: Lyndon Nerenberg <[email-masked]>
To: [email-masked]
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Organization: The Frobozz Magic Homing Pigeon Company
Sender: [email-masked]

>> 2. If the mechanism and document are significantly complicated by the
>> requirements of GS2, then that's significantly worse.
>
> This sums up my position nicely. SCRAM is coming to the party very late 
> indeed, and because of that there's a pretty good chance it won't 
> deploy. Every bit of additional complexity in the specification 
> increases this chance.

> As such, I'm opposed to the GS2 approach unless it can be made to be as 
> simple or simpler than the direct approach. And from what I can tell 
> from the two specificaation that's not possible.

I'm in complete agreement with Ned on this.

It seems to me that the SASL WG is hell bent upon adding as much 
complexity as they can to everything they touch. Good security demands the 
absolute greatest amount of simplicity as can be attained while fulfilling 
the desired level of protection. This endless stacking of layer upon layer 
of protocol API serves only to add complexity to something that needs to 
be as simple and understandable as possible. If a human cannot parse and 
understand the protocol specification, there isn't a hope in hell they 
will be able to write a secure implementation.

I don't think GS2 even belongs inside the SASL framework. They both try to 
solve the same problem, therefore it's pointless (and redundent) for GS2 
to exist inside SASL to begin with. The two should exist side-by-side, 
letting the application protocol developers make the tradeoff between code 
complexity and desired security.

As for SCRAM vs. GS2-SCRAM, since the two cannot speak to each other on 
the wire they are by definition distinct and seperate protocols, and 
therefore demand distinct and seperate specficications. That much of the 
text might overlap doesn't change this fact. I realize it takes more work 
to write two seperate documents, but the onus upon this WG is to write 
specifications that above all else address the needs of the people who 
have to implement this stuff. Mixing two protocols in a single document is 
just slapping these people in the face.

--lyndon

   I think 3B2 code deserves its own place in hell.  Poring over the
   ESS#5 code, someone found that there were lots of strcmp(p, "f(")
   == 0 checks (I may have gotten the exact string wrong but it's
   close).  It took us a while to figure out why.  Apparently, location
   0 on the 3b had the 3 bytes 'f' '(' '\0', someone noticed that when
   programs blew up they were pointing to "f(", and the worlds most
   amazing kludge for detecting nil pointers was born.
   			-- Dave Presotto

Date: Sun, 08 Feb 2009 09:34:42 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: Simon Josefsson <[email-masked]>, Nicolas Williams <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> As an alternative, might I suggest adding entirely separate, but 
> intentionally parallel, SCRAMs in GSS-API and SASL? No relationship as 
> far as protocol goes, but intentionally similar enough that libraries 
> which implement both can refactor the code (parsing etc. excepted).

That would be fine with me. While this is not ideal, I think it would be 
much easier to agree on this in the WG.

Date: Sun, 08 Feb 2009 09:27:21 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: Nicolas Williams <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> 1. Making one document define SCRAM both in GS2 and pure SASL formats
> bloats the text. I want the document to be simple, so that _everyone_
> who today has a crammd5.c can write a scram.c _as_easily_as_ it was to
> write that crammd5.c. Bloating the document with an alternate
> definition is no help. People _will_ read the other half and _will_
> spend time trying to understand it, if only to decide what part they
> should understand and implement.

I think this can be easily avoided, if the document is structured correctly.

Date: Sun, 08 Feb 2009 09:26:20 +0100
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

Nicolas Williams wrote:

>On Fri, Feb 06, 2009 at 10:31:16AM +0000, Alexey Melnikov wrote:
>  
>
>>Nicolas Williams wrote:
>>    
>>
>>>Are the two versions supposed to be the same protocol, but described
>>>differently?  Or are they different protocols?
>>>      
>>>
>>The two versions are slightly different on the wire - GS2 version 
>>requires different layout, different MIC to protect authorization 
>>identity, etc.
>>    
>>
>If it the same messages can't be reused to fashion a GSS mechanism then
>I'm not interested, so count me as in favor of SCRAM-as-GS2.
>
>BUT, I don't understand this poll.  Why are we having it as opposed a
>poll as to how to describe SCRAM?  Is it because SCRAM-as-GS2, even
>described as a pure SASL mech, is too complicated?
>
I would say SCRAM-as-GS2 is slightly more complicated. I want to find 
out what people think about the extra complexity.

Of course any input from people such as "if you change X to Y, or drop 
Z, then the document would become reasonable", would be highly 
constructive and would be appreciated.

>If so, what are the complicating issues that make it a deal breaker for others?
>  
>
I don't know which things people find difficult and would like to find out.
Or rather I would not tell my opinion until I hear some feedback.

>I have the feeling that instead of listing those issues and addressing
>them we're just giving up.
>
I have so many free hours in any given day and I am afraid the two 
proposals is the best I can do at the moment.
Unless people will actively try to help me (by either making the choice 
or by contributing some suggestions/text), I will give up very soon now.

From: Simon Josefsson <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, Nicolas Williams <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 06 Feb 2009 22:15:51 +0100
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> writes:

> Simon Josefsson writes:
>>> As an alternative, might I suggest adding entirely separate, but
>>> intentionally parallel, SCRAMs in GSS-API and SASL? No relationship
>>> as far as protocol goes, but intentionally similar enough that
>>> libraries which implement both can refactor the code (parsing
>>> etc. excepted).
>>
>> Which SASL mechanism name should be used for these two different protocols?
>
> "SCRAM" for SCRAM. I presume the GSS-API one would be reachable in
> SASL both as "GS2-1FAD1FDAC254" and perhaps as "GSSAPI"+blah.

Ok.  "GSSAPI" is only for Kerberos V5, so I think the GSS-API variant of
SCRAM would only be reachable as GS2-FOOBAR.

>> If the same name is used, the protocol specification better be consistent.
>
> The name would be different. A library's two implementations would be
> able to share the implementation (except syntax generation and
> parsing).
>
> Bt the protocol specification still has to be exactly consistent, so
> the implementation sharing works.

I think this requires that the relevant text needs to be exactly the
same in both documents.  I don't have a problem with that, although it
complicates updating the documents since they will forever be coupled
together.

>> If two different names are used, there will be no interop: SCRAM
>> implemented directly in SASL will not talk to SCRAM implemented in
>> GSS-API, and consequently in SASL via GS2. Even though it is the
>> same protocol beneath. Do you think that is acceptable?
>
> I think so.
>
> If you've implemented GSS-API SCRAM and want to implement SASL, doing
> SASL SCRAM will just be a few straight-line functions (1-4 lines, no
> if/when/while) so I don't think there'll be a significant number of
> SASL implementations that support "GS2-1ADF1FDAC254" without
> supporting "SCRAM".

I wonder whether this will fly through IESG review.  It sounds like a
bad interop situation to me.  However, maybe some careful wording about
this can mitigate it.

Ok, so it seems this approach may at least be considered.  The bigger
question is whether we can get consensus around it.

/Simon

Date: Fri, 6 Feb 2009 22:04:13 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Simon Josefsson <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Cc: Alexey Melnikov <[email-masked]>, Nicolas Williams <[email-masked]>, SASL WG <[email-masked]>
Sender: [email-masked]

Simon Josefsson writes:
>> As an alternative, might I suggest adding entirely separate, but 
>> intentionally parallel, SCRAMs in GSS-API and SASL? No relationship 
>> as far as protocol goes, but intentionally similar enough that 
>> libraries which implement both can refactor the code (parsing etc. 
>> excepted).
>
> Which SASL mechanism name should be used for these two different protocols?

"SCRAM" for SCRAM. I presume the GSS-API one would be reachable in SASL 
both as "GS2-1FAD1FDAC254" and perhaps as "GSSAPI"+blah.

> If the same name is used, the protocol specification better be consistent.

The name would be different. A library's two implementations would be 
able to share the implementation (except syntax generation and 
parsing).

Bt the protocol specification still has to be exactly consistent, so the 
implementation sharing works.

> If two different names are used, there will be no interop: SCRAM 
> implemented directly in SASL will not talk to SCRAM implemented in 
> GSS-API, and consequently in SASL via GS2. Even though it is the same 
> protocol beneath. Do you think that is acceptable?

I think so.

If you've implemented GSS-API SCRAM and want to implement SASL, doing 
SASL SCRAM will just be a few straight-line functions (1-4 lines, no 
if/when/while) so I don't think there'll be a significant number of 
SASL implementations that support "GS2-1ADF1FDAC254" without supporting 
"SCRAM".

Arnt

From: Simon Josefsson <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: [Fwd: I-D Action:draft-newman-auth-scram-gs2-00.txt]
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 06 Feb 2009 21:49:25 +0100
Sender: [email-masked]

Hallvard B Furuseth <[email-masked]> writes:

> Alexey Melnikov writes:
>> This is a preview of how SCRAM as GS2 document might look like. I think 
>> it should have enough details for people to make a decision between 
>> stand-alone SCRAM and SCRAM as GS2 (or to raise questions that should be 
>> sufficient to make such choice.)
>
> I don't understand.  This is a GS2-* mechanism sending text messages,
> but [GS2] section 4.1 says GS2-* messages start with a binary integer.

I believe the idea was that if we get consensus to describe SCRAM as a
GSS-API mechanism, the GS2 wire syntax will need to change so that
SCRAM-under-GS2 will be a text protocol.

If SCRAM will not be defined as a GSS-API mechanism, and thus
implemented in SASL via GS2, I don't see a need to revise the wire
syntax of GS2.  GS2 can then remain a binary protocol.

I haven't updated the GS2 document pending that the discussion around
SCRAM to settle down.  If someone believes that anything could or should
be done about GS2 until SCRAM is resolved, please tell me.

/Simon

From: Simon Josefsson <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, Nicolas Williams <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 06 Feb 2009 21:43:39 +0100
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> writes:

>> If people are allergic to seeing the terms GSS-API in a document
>> about SCRAM, SCRAM could be described two times:
>>
>> A) SCRAM as a SASL mechanism
>>
>> B) SCRAM as a GSS-API mechanism
>
> That's what you keep saying, and I keep being thinking that whatever
> you say, it'll bloat the description of SCRAM in the RFC and/or
> complicate SCRAM, and thereby make it harder for J. Random CRAM
> Implementer to write a SCRAM implementation. Alexey's draft this week
> did not change my mind.
>
> As an alternative, might I suggest adding entirely separate, but
> intentionally parallel, SCRAMs in GSS-API and SASL? No relationship as
> far as protocol goes, but intentionally similar enough that libraries
> which implement both can refactor the code (parsing etc. excepted).

Which SASL mechanism name should be used for these two different
protocols?

If the same name is used, the protocol specification better be
consistent.  The best way to assure that is to only have one
specification.  If there are two specifications, and they do not
describe exactly the same protocol, there will be interop problems.

If two different names are used, there will be no interop: SCRAM
implemented directly in SASL will not talk to SCRAM implemented in
GSS-API, and consequently in SASL via GS2.  Even though it is the same
protocol beneath.  Do you think that is acceptable?

/Simon

Date: Fri, 6 Feb 2009 21:27:15 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Simon Josefsson <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Cc: Alexey Melnikov <[email-masked]>, Nicolas Williams <[email-masked]>, SASL WG <[email-masked]>
Sender: [email-masked]

Simon Josefsson answers me:
>> I understand that others want one mechanism in both GS2 and SASL. 
>> Given that desire, SCRAM-as-GS2 makes perfect sense. But that's not 
>> my desire.
>
> I sense some confusion here.

I confess I didn't pay much attention when the benefits of SCRAM-as-GS2 
were explained. As I said, GS2 doesn't really interest me.

That isn't relevant to my arguments against SCRAM-as-GS2.

> ...
>
> If people are allergic to seeing the terms GSS-API in a document about 
> SCRAM, SCRAM could be described two times:
>
> A) SCRAM as a SASL mechanism
>
> B) SCRAM as a GSS-API mechanism

That's what you keep saying, and I keep being thinking that whatever you 
say, it'll bloat the description of SCRAM in the RFC and/or complicate 
SCRAM, and thereby make it harder for J. Random CRAM Implementer to 
write a SCRAM implementation. Alexey's draft this week did not change 
my mind.

As an alternative, might I suggest adding entirely separate, but 
intentionally parallel, SCRAMs in GSS-API and SASL? No relationship as 
far as protocol goes, but intentionally similar enough that libraries 
which implement both can refactor the code (parsing etc. excepted).

Arnt

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 6 Feb 2009 20:03:41 +0100
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: [Fwd: I-D Action:draft-newman-auth-scram-gs2-00.txt]
Sender: [email-masked]

Alexey Melnikov writes:
> This is a preview of how SCRAM as GS2 document might look like. I think 
> it should have enough details for people to make a decision between 
> stand-alone SCRAM and SCRAM as GS2 (or to raise questions that should be 
> sufficient to make such choice.)

I don't understand.  This is a GS2-* mechanism sending text messages,
but [GS2] section 4.1 says GS2-* messages start with a binary integer.

-- 
Hallvard

From: Simon Josefsson <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 06 Feb 2009 19:30:37 +0100
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> writes:

> I understand that others want one mechanism in both GS2 and
> SASL. Given that desire, SCRAM-as-GS2 makes perfect sense. But that's
> not my desire.

I sense some confusion here.

SCRAM as a GS2 mechanism won't satisfy the crowd (me included) that
wants to use SCRAM in GSS-API.  GS2 is a _SASL_ mechanism, so it does
nothing for GSS-API applications.  What is needed is to specify SCRAM as
a GSS-API mechanism.  Then it will automatically, through GS2, become a
SASL mechanism.  The wire protocols will be close to identical.

If people are allergic to seeing the terms GSS-API in a document about
SCRAM, SCRAM could be described two times:

A) SCRAM as a SASL mechanism

B) SCRAM as a GSS-API mechanism

But we will have to be careful that A) interoperate with B) under GS2.
We could also give up and say that SCRAM-the-GSS-API-mechanism MUST
never be used via GS2.  But that prevents code re-use.

I would prefer to describe SCRAM as a GSS-API mechanism, and have it be
supported in SASL via GS2 automatically.  To cater for those that cannot
read specification that contains the term GSS-API, there could be an
informational document to describe how to implement directly in SASL
using the GS2 SASL mech name.

/Simon

Date: Fri, 06 Feb 2009 09:43:40 -0800 (PST)
From: [email-masked]
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
To: Arnt Gulbrandsen <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Sender: [email-masked]

> Nicolas Williams writes:
> > On Fri, Feb 06, 2009 at 10:31:16AM +0000, Alexey Melnikov wrote:
> >>  Nicolas Williams wrote:
> >>
> >>  >Are the two versions supposed to be the same protocol, but described
> >>  >differently?  Or are they different protocols?
> >>  >
> >>  >
> >>  The two versions are slightly different on the wire - GS2 version
> >>  requires different layout, different MIC to protect authorization
> >>  identity, etc.
> >
> > If it the same messages can't be reused to fashion a GSS mechanism
> > then I'm not interested, so count me as in favor of SCRAM-as-GS2.
> >
> > BUT, I don't understand this poll. Why are we having it as opposed a
> > poll as to how to describe SCRAM? Is it because SCRAM-as-GS2, even
> > described as a pure SASL mech, is too complicated?

> I think so.

> > If so, what are the complicating issues that make it a deal breaker
> > for others?

> I don't care _what_ they are. Let me explain.

> What I want is a replacement for digest-md5 and/or cram-md5, neither
> more nor less. GS2 is entirely irrelevant to me, EXCEPT:

> 1. Making one document define SCRAM both in GS2 and pure SASL formats
> bloats the text. I want the document to be simple, so that _everyone_
> who today has a crammd5.c can write a scram.c _as_easily_as_ it was to
> write that crammd5.c. Bloating the document with an alternate
> definition is no help. People _will_ read the other half and _will_
> spend time trying to understand it, if only to decide what part they
> should understand and implement.

> 2. If the mechanism and document are significantly complicated by the
> requirements of GS2, then that's significantly worse.

This sums up my position nicely. SCRAM is coming to the party very late indeed,
and because of that there's a pretty good chance it won't deploy. Every bit of
additional complexity in the specification increases this chance.

As such, I'm opposed to the GS2 approach unless it can be made to be as simple
or simpler than the direct approach. And from what I can tell from the two
specificaation that's not possible.

> The precise nature of the complicating issues doesn't affect either
> point. Only their existence matter.

Exactly so.

				Ned

Date: Fri, 6 Feb 2009 17:49:05 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Sender: [email-masked]

Nicolas Williams writes:
> On Fri, Feb 06, 2009 at 10:31:16AM +0000, Alexey Melnikov wrote:
>>  Nicolas Williams wrote:
>>
>>  >Are the two versions supposed to be the same protocol, but described
>>  >differently?  Or are they different protocols?
>>  >
>>  >
>>  The two versions are slightly different on the wire - GS2 version
>>  requires different layout, different MIC to protect authorization
>>  identity, etc.
>
> If it the same messages can't be reused to fashion a GSS mechanism 
> then I'm not interested, so count me as in favor of SCRAM-as-GS2.
>
> BUT, I don't understand this poll. Why are we having it as opposed a 
> poll as to how to describe SCRAM? Is it because SCRAM-as-GS2, even 
> described as a pure SASL mech, is too complicated?

I think so.

> If so, what are the complicating issues that make it a deal breaker 
> for others?

I don't care _what_ they are. Let me explain.

What I want is a replacement for digest-md5 and/or cram-md5, neither 
more nor less. GS2 is entirely irrelevant to me, EXCEPT:

1. Making one document define SCRAM both in GS2 and pure SASL formats 
bloats the text. I want the document to be simple, so that _everyone_ 
who today has a crammd5.c can write a scram.c _as_easily_as_ it was to 
write that crammd5.c. Bloating the document with an alternate 
definition is no help. People _will_ read the other half and _will_ 
spend time trying to understand it, if only to decide what part they 
should understand and implement.

2. If the mechanism and document are significantly complicated by the 
requirements of GS2, then that's significantly worse.

The precise nature of the complicating issues doesn't affect either 
point. Only their existence matter.

I understand that others want one mechanism in both GS2 and SASL. Given 
that desire, SCRAM-as-GS2 makes perfect sense. But that's not my 
desire.

> I have the feeling that instead of listing those issues and addressing 
> them we're just giving up.

Yes... I think I gave up earlier this week, when I saw I wasn't the only 
person to be unsure of whether the two SCRAM definitions would 
interoperate (minor mistakes aside). SCRAM won't be what I want.

Arnt

Date: Fri, 6 Feb 2009 09:22:19 -0600
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

On Fri, Feb 06, 2009 at 10:31:16AM +0000, Alexey Melnikov wrote:
> Nicolas Williams wrote:
> 
> >Are the two versions supposed to be the same protocol, but described
> >differently?  Or are they different protocols?
> > 
> >
> The two versions are slightly different on the wire - GS2 version 
> requires different layout, different MIC to protect authorization 
> identity, etc.

If it the same messages can't be reused to fashion a GSS mechanism then
I'm not interested, so count me as in favor of SCRAM-as-GS2.

BUT, I don't understand this poll.  Why are we having it as opposed a
poll as to how to describe SCRAM?  Is it because SCRAM-as-GS2, even
described as a pure SASL mech, is too complicated?  If so, what are the
complicating issues that make it a deal breaker for others?

I have the feeling that instead of listing those issues and addressing
them we're just giving up.

Nico
-- 

Date: Fri, 06 Feb 2009 10:31:16 +0000
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

Nicolas Williams wrote:

>Are the two versions supposed to be the same protocol, but described
>differently?  Or are they different protocols?
>  
>
The two versions are slightly different on the wire - GS2 version 
requires different layout, different MIC to protect authorization 
identity, etc.

Date: Fri, 6 Feb 2009 00:19:01 -0600
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

Are the two versions supposed to be the same protocol, but described
differently?  Or are they different protocols?

Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= <[email-masked]>
Cc: SASL WG <[email-masked]>
Date: Thu, 05 Feb 2009 15:25:19 -0800
To: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

5 feb 2009 kl. 13:14 skrev Alexey Melnikov:

>
> Folks,
> I would like to solicit feedback from people regarding the choice
> between 2 SCRAM versions:
> http://tools.ietf.org/id/draft-newman-auth-scram-08.txt
> and
> http://tools.ietf.org/id/draft-newman-auth-scram-gs2-00.txt
>
> You can use the following URL to see changes between them:
> http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-newman-auth-scram-08.txt&url2=http://tools.ietf.org/id/draft-newman-auth-scram-gs2-00.txt
>
> Please send your opinion on which version you prefer (and a short
> explanation of why) to the mailing list, or say if you need more
> information.

I prefer having SCRAM as a GSS-API mech since if SCRAM was a SASL mech  
we would have to create a GSS-API mech for those protocols that  
doesn't do SASL but only GSS-API.

SASL implementors (or should I say SA implementors) can avoid  the SL  
layer if they want to (as commonly done today), that would bring the  
complexity down for them.

Love

From: "Matthew A. Miller" <[email-masked]>
To: SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Thu, 5 Feb 2009 14:56:57 -0700
Sender: [email-masked]

--Apple-Mail-1112-13263696
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

On Feb 5, 2009, at 14:14, Alexey Melnikov wrote:

>
> Folks,
> I would like to solicit feedback from people regarding the choice  
> between 2 SCRAM versions:
> http://tools.ietf.org/id/draft-newman-auth-scram-08.txt
> and
> http://tools.ietf.org/id/draft-newman-auth-scram-gs2-00.txt
>
> You can use the following URL to see changes between them:
> http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-newman-auth-scram-08.txt&url2=http://tools.ietf.org/id/draft-newman-auth-scram-gs2-00.txt
>
> Please send your opinion on which version you prefer (and a short  
> explanation of why) to the mailing list, or say if you need more  
> information.
>
> I would like to get all answers before February 19th, please.
>
> Regards,
> Alexey
>

If it's a choice between one or the other, I would choose SCRAM (stand- 
alone).  For us (being my employer), everything is already SASL, but  
not GSSAPI.

If SCRAM were updated to discuss "doing SCRAM without GS2/GSSAPI",  
then I would take that.

--
Matthew A. Miller
[email-masked]

--Apple-Mail-1112-13263696
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail-1112-13263696--

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: SASL WG <[email-masked]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 05 Feb 2009 22:36:56 +0100
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> Folks,
> I would like to solicit feedback from people regarding the choice
> between 2 SCRAM versions:
> http://tools.ietf.org/id/draft-newman-auth-scram-08.txt
> and
> http://tools.ietf.org/id/draft-newman-auth-scram-gs2-00.txt
>
> You can use the following URL to see changes between them:
> http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-newman-auth-scram-08.txt&url2=http://tools.ietf.org/id/draft-newman-auth-scram-gs2-00.txt
>
> Please send your opinion on which version you prefer (and a short
> explanation of why) to the mailing list, or say if you need more
> information.
>
> I would like to get all answers before February 19th, please.

I would prefer a document that describe SCRAM as a GSS-API mechanism.

Such a mechanism would be usable within SASL via GS2.  It would also be
useful outside of the SASL framework.

For SASL implementers, in a SCRAM-as-GSSAPI-mechanism document, there
could be a section that describes how to implement it as a SASL
mechanism without having to understand GSS-API or GS2.

/Simon

Date: Thu, 05 Feb 2009 21:14:04 +0000
From: Alexey Melnikov <[email-masked]>
To: SASL WG <[email-masked]>
Subject: Poll: pure SCRAM versa SCRAM-as-GS2
Sender: [email-masked]

Folks,
I would like to solicit feedback from people regarding the choice 
between 2 SCRAM versions:
 http://tools.ietf.org/id/draft-newman-auth-scram-08.txt
and
 http://tools.ietf.org/id/draft-newman-auth-scram-gs2-00.txt

You can use the following URL to see changes between them:
http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-newman-auth-scram-08.txt&url2=http://tools.ietf.org/id/draft-newman-auth-scram-gs2-00.txt

Please send your opinion on which version you prefer (and a short 
explanation of why) to the mailing list, or say if you need more 
information.

I would like to get all answers before February 19th, please.

Regards,
Alexey

Date: Tue, 03 Feb 2009 19:47:23 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: [Fwd: I-D Action:draft-newman-auth-scram-gs2-00.txt]
Sender: [email-masked]

--------------040203000407060309040407
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

This is a preview of how SCRAM as GS2 document might look like. I think 
it should have enough details for people to make a decision between 
stand-alone SCRAM and SCRAM as GS2 (or to raise questions that should be 
sufficient to make such choice.)

--------------040203000407060309040407
Content-Type: message/rfc822;
 name="I-D Action:draft-newman-auth-scram-gs2-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="I-D Action:draft-newman-auth-scram-gs2-00.txt"

From: [email-masked]
To: [email-masked]
Subject: I-D Action:draft-newman-auth-scram-gs2-00.txt 
Date: Tue,  3 Feb 2009 11:45:01 -0800 (PST)
Reply-To: [email-masked]
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Salted Challenge Response (SCRAM) SASL Mechanism (GS2 variant)
	Author(s)       : A. Menon-Sen, et al.
	Filename        : draft-newman-auth-scram-gs2-00.txt
	Pages           : 20
	Date            : 2009-02-03

The secure authentication mechanism most widely deployed and used by
 Internet application protocols is the transmission of clear-text
 passwords over a channel protected by Transport Layer Security
 (TLS).  There are some significant security concerns with that
 mechanism, which could be addressed by the use of a challenge
 response authentication mechanism protected by TLS. Unfortunately,
 the challenge response mechanisms presently on the standards track
 all fail to meet requirements necessary for widespread deployment,
 and have had success only in limited use.

 This specification describes a family of authentication mechanisms
 called the Salted Challenge Response Authentication Mechanism
 (SCRAM), which addresses the security concerns and meets the
 deployability requirements. When used in combination with TLS or an
 equivalent security layer, a mechanism from this family could
 improve the status-quo for application protocol authentication and
 provide a suitable choice for a mandatory-to-implement mechanism for
 future application protocol standards.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-newman-auth-scram-gs2-00.txt

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

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

--NextPart
Content-Type: Message/External-body;
	name="draft-newman-auth-scram-gs2-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--NextPart--

--------------040203000407060309040407--

Date: Sun, 01 Feb 2009 13:57:16 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: [Fwd: I-D Action:draft-newman-auth-scram-08.txt]
Sender: [email-masked]

--------------070406080904030102010308
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

This version doesn't address Hallvard's concern about client 
impersonalization and the order of attributes. But otherwise it should 
be ready for WGLC.

I will post SCRAM-as-GS2 version later next week.

--------------070406080904030102010308
Content-Type: message/rfc822;
 name="I-D Action:draft-newman-auth-scram-08.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="I-D Action:draft-newman-auth-scram-08.txt"

From: [email-masked]
To: [email-masked]
Subject: I-D Action:draft-newman-auth-scram-08.txt 
Date: Sat, 31 Jan 2009 08:30:01 -0800 (PST)
Reply-To: [email-masked]
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Salted Challenge Response (SCRAM) SASL Mechanism
	Author(s)       : A. Menon-Sen, et al.
	Filename        : draft-newman-auth-scram-08.txt
	Pages           : 18
	Date            : 2009-01-31

The secure authentication mechanism most widely deployed and used by
 Internet application protocols is the transmission of clear-text
 passwords over a channel protected by Transport Layer Security
 (TLS).  There are some significant security concerns with that
 mechanism, which could be addressed by the use of a challenge
 response authentication mechanism protected by TLS. Unfortunately,
 the challenge response mechanisms presently on the standards track
 all fail to meet requirements necessary for widespread deployment,
 and have had success only in limited use.

 This specification describes a family of authentication mechanisms
 called the Salted Challenge Response Authentication Mechanism
 (SCRAM), which addresses the security concerns and meets the
 deployability requirements. When used in combination with TLS or an
 equivalent security layer, a mechanism from this family could
 improve the status-quo for application protocol authentication and
 provide a suitable choice for a mandatory-to-implement mechanism for
 future application protocol standards.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-newman-auth-scram-08.txt

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

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

--NextPart
Content-Type: Message/External-body;
	name="draft-newman-auth-scram-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--NextPart--

--------------070406080904030102010308--