Subject: Poll: pure SCRAM versa SCRAM-as-GS2

From: Alexey Melnikov <[email-masked]>
Date: Thu, 05 Feb 2009 21:14:04 +0000

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

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 05 Feb 2009 22:36:56 +0100

> 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

---

From: "Matthew A. Miller" <[email-masked]>
Date: Thu, 5 Feb 2009 14:56:57 -0700

> I would like to get all answers before February 19th, please.

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]

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Thu, 05 Feb 2009 15:25:19 -0800

> explanation of why) to the mailing list, or say if you need more

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: Nicolas Williams <[email-masked]>
Date: Fri, 6 Feb 2009 00:19:01 -0600

Are the two versions supposed to be the same protocol, but described
differently?  Or are they different protocols?

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 06 Feb 2009 10:31:16 +0000

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

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 6 Feb 2009 09:22:19 -0600

> requires different layout, different MIC to protect authorization 

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 6 Feb 2009 17:49:05 +0100

Nicolas Williams writes:
> 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.
>
> 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.

> 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

---

From: [email-masked]
Date: Fri, 06 Feb 2009 09:43:40 -0800 (PST)

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

> point. Only their existence matter.

Exactly so.

				Ned

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 06 Feb 2009 19:30:37 +0100

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 6 Feb 2009 21:27:15 +0100

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

> ...

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: Simon Josefsson <[email-masked]>
Date: Fri, 06 Feb 2009 21:43:39 +0100

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

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 6 Feb 2009 22:04:13 +0100

Simon Josefsson writes:
>> 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.

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]>
Date: Fri, 06 Feb 2009 22:15:51 +0100

Arnt Gulbrandsen <[email-masked]> writes:

>>> libraries which implement both can refactor the code (parsing
>>> etc. excepted).
>>
> "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.

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

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

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 08 Feb 2009 09:27:21 +0100

> should understand and implement.

I think this can be easily avoided, if the document is structured correctly.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 08 Feb 2009 09:26:20 +0100

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

>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: Alexey Melnikov <[email-masked]>
Date: Sun, 08 Feb 2009 09:34:42 +0100

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

---

From: Lyndon Nerenberg <[email-masked]>
Date: Sun, 8 Feb 2009 17:17:25 -0800 (PST)

> 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

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 9 Feb 2009 13:09:43 -0800

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)

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Feb 2009 09:45:16 -0600

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Feb 2009 09:46:49 -0600

> much easier to agree on this in the WG.

This would make GS2 pointless.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Feb 2009 09:55:40 -0600

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

> constructive and would be appreciated.

Right, but that's not what's happening.

> Or rather I would not tell my opinion until I hear some feedback.

We will never be told.

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Feb 2009 09:59:13 -0600

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

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Feb 2009 16:16:51 +0000

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

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 10 Feb 2009 09:55:31 -0800

>> 	GSS-API implementations: GS2 security layer

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.

> 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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Feb 2009 11:58:51 -0600

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Feb 2009 12:05:12 -0600

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

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

> to avoid such interoperability problems is not to have classes of

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

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 10 Feb 2009 11:48:58 -0800

> 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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Feb 2009 14:12:45 -0600

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

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 10 Feb 2009 12:17:32 -0800

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Feb 2009 14:35:32 -0600

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

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

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Feb 2009 21:06:25 +0000

>interop with SASL/GS2 implementors.
I agree with both statements.

>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

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 10 Feb 2009 13:14:06 -0800

On Feb 10, 2009, at 12:12 PM, Nicolas Williams wrote:

>>>>>> that if SCRAM were implemented as a GSA-API, the GS2- variant  
>>>>>> would
>>>>>> be
>>>>>> would lead to a significant interoperability problem as there  
>>>>>> would
>>>>>> be
>>>>>> two classes of support:

Do you expect SASL-GS2 I-D to be revised to detail how to implement  
these security layer?

-- Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 10 Feb 2009 22:17:35 +0100

Nicolas Williams writes:
> 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

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 10 Feb 2009 22:23:47 +0100

> GS2-SASL document.  But in the mailinglist too if the poll is also
  ^^^^^^^^
Sorry, GS2-SCRAM document.

-- 
Hallvard

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 10 Feb 2009 13:25:24 -0800

> 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: Nicolas Williams <[email-masked]>
Date: Tue, 10 Feb 2009 15:20:20 -0600

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

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Feb 2009 15:22:36 -0600

> Do you expect SASL-GS2 I-D to be revised to detail how to implement  

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Feb 2009 22:29:59 -0600

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

> draft.  People have mentioned code reuse, I don't know if there is

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 11 Feb 2009 11:31:01 +0100

Nicolas Williams writes:
> 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.

> 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

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 11 Feb 2009 13:48:15 +0100

>    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

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 11 Feb 2009 13:52:15 +0100

>    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]>
Date: Wed, 11 Feb 2009 13:55:49 +0100

> 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: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 11 Feb 2009 14:03:48 +0100

> binding support, which makes it possible to re-use TLS for security 

Glad to hear that.

Arnt

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 11 Feb 2009 05:20:33 -0800

>>> Do you expect SASL-GS2 I-D to be revised to detail how to implement

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.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 11 Feb 2009 10:44:41 -0600

> binding support, which makes it possible to re-use TLS for security

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.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 12 Feb 2009 11:23:37 +0100

> 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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 12 Feb 2009 14:03:29 +0100

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: Nicolas Williams <[email-masked]>
Date: Thu, 12 Feb 2009 08:20:43 -0600

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

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Feb 2009 08:22:45 -0600

> don't think it will prevent future work towards merging the GSS-API and

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.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 12 Feb 2009 16:00:33 +0100

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

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Feb 2009 09:03:13 -0600

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

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 13 Feb 2009 00:29:26 +0100

Nicolas Williams writes:
>(...snip...)

Thank you, nice summary.  Yes, the I-Ds should definitely capture this.

-- 
Hallvard

---

From: Paul Leach <[email-masked]>
Date: Thu, 12 Feb 2009 21:39:10 -0800

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 mandatory-to-implement auth mechanism for a bunch of protocols, then we're very much 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: Alexey Melnikov <[email-masked]>
Date: Sun, 15 Feb 2009 21:01:19 +0000

>BTW: has anyone thought about use of SCRAM with HTTP?
Yes, but not in details. The protocol should be easily extensible to HTTP.

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 15 Feb 2009 16:24:38 -0600

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

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 16 Feb 2009 18:26:43 +0100

> 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

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 16 Feb 2009 10:01:38 -0800

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

> 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 19:49:56 +0100

>    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

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 16 Feb 2009 19:33:27 +0000

>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

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 16 Feb 2009 19:42:17 +0000

Hallvard B Furuseth wrote:

>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
Neither version of SCRAM provide any SASL security layer at the moment.

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

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 16 Feb 2009 20:48:01 +0100

>> Is the HMAC(<StoredKey/ServerKey>, AuthMessage) in SCRAM an integrity

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

>(...)

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

-- 
Hallvard

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 16 Feb 2009 11:57:55 -0800

> Neither version of SCRAM provide any SASL security layer at the  

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: Alexey Melnikov <[email-masked]>
Date: Mon, 16 Feb 2009 19:59:18 +0000

> layer for the GSS-API SCRAM mechanism.

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

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 16 Feb 2009 12:59:44 -0800

> No, it is quite explicit about that: GS2 security layer is  

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

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 16 Feb 2009 15:32:41 -0600

> >No, it is quite explicit about that: GS2 security layer is  

When channel binding succeeds.

> how to offer the GS2+GSSAPI+SCRAM layers, or it should detail why it  

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

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 16 Feb 2009 14:02:54 -0800

> 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

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 16 Feb 2009 14:09:24 -0800

> SCRAM-as-GSS-API-mech documents.

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

-- Kurt

---

From: [email-masked]
Date: Mon, 16 Feb 2009 17:14:54 -0800 (PST)

> 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

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 17 Feb 2009 10:36:07 +0100

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

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 17 Feb 2009 10:40:00 +0000

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

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 17 Feb 2009 08:41:40 -0800

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

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 17 Feb 2009 08:51:01 -0800

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

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 17 Feb 2009 09:07:12 -0800

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

> On Mon, Feb 16, 2009 at 02:09:24PM -0800, Kurt Zeilenga wrote:
> 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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 17 Feb 2009 10:06:49 -0700

Kurt Zeilenga wrote:
>>> (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.
> 

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

Peter

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 17 Feb 2009 10:42:24 -0600

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 17 Feb 2009 18:13:13 +0100

> SASL/DIGEST-MD5 interoperability.  It didn't go well.

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

-- 
Hallvard

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 17 Feb 2009 17:16:35 +0000

>Whee.  Details!  What problems where identified?  Which mistakes are we
Most of this should be in my draft "Digest to historic".

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 17 Feb 2009 17:17:55 +0000

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 17 Feb 2009 11:19:35 -0600

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

> 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  

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

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 17 Feb 2009 09:37:54 -0800

> 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

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 17 Feb 2009 10:01:11 -0800

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

Same uses cases that GS2 security layers serve.

>> reviewers

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.

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

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.

>   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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 17 Feb 2009 11:14:11 -0700

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 17 Feb 2009 12:14:29 -0600

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

> compatibility, than feature completeness (such as inclusion of the GS2- 

I've addressed this.

> being feature incomplete.   I don't think SASL/SCRAM w/o TLS as being  

I can't parse this.

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

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

> Same uses cases that GS2 security layers serve.

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

> specifications in order to better ensure correctness of those  

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

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

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

> features (such as support for GS2 security layers) in GS-SASL.

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

Nico
--

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 17 Feb 2009 10:23:33 -0800

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

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 17 Feb 2009 11:19:49 -0800

>> compatibility, than feature completeness (such as inclusion of the  

Regrettable not to my personal satisfaction.

>> being feature incomplete.   I don't think SASL/SCRAM w/o TLS as being

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.

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

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

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

> 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

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.

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

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 17 Feb 2009 20:55:40 +0100

Nicolas Williams writes:
> 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.

>    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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 17 Feb 2009 13:51:46 -0600

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

> I'm currently leaning towards c, though I'm trying to keep an open  

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

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

> >necessarily help establish that the pure SASL version of SCRAM-as-
> >GS2 is correct.  See above.
> 

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

> 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 21:08:26 +0100

> protected.  But now you are talking as if maybe security layers need not

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 17 Feb 2009 14:02:18 -0600

>   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: Kurt Zeilenga <[email-masked]>
Date: Tue, 17 Feb 2009 13:22:49 -0800

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

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

I was making a suggestion, not a requirement.

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

> 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
> sounds like a recipe for trouble.

I do agree that this is a recipe for trouble.

> The only alternatives are:
>
> 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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 17 Feb 2009 22:37:34 +0100

>  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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 17 Feb 2009 15:54:36 -0600

> anything of the kind, and do oppose making GS2-SASL definitive in  

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 18 Feb 2009 16:23:35 -0500

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:

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

> 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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 18 Feb 2009 16:27:35 -0500

> 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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 18 Feb 2009 17:00:44 -0500

> 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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 18 Feb 2009 22:32:43 +0000

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

---

From: Chris Newman <[email-masked]>
Date: Wed, 18 Feb 2009 16:26:19 -0800

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

---

From: [email-masked]
Date: Thu, 19 Feb 2009 08:02:18 -0800 (PST)

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

> larger code quantity.  So I consider the interop benefit to be outweighed

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.

> beginning of the first client message.  If it's possible to do that, then I

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 19 Feb 2009 18:01:03 +0100

[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

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 19 Feb 2009 22:17:30 +0000

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

---

From: Dave Cridland <[email-masked]>
Date: Fri, 20 Feb 2009 10:17:35 +0000

> can there's still a significant risk this whole thing is going to  

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.

> past. What I found instead was a significantly more complex  

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