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

[Chris Newman <[e-mail]>]

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 
<[e-mail]> 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.