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

[Kurt Zeilenga <[e-mail]>]

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