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

[Nicolas Williams <Nicolas.Williams@xxxxxxx>]

On Sat, Feb 28, 2009 at 12:51:50PM +0100, Arnt Gulbrandsen wrote:
> Nicolas Williams writes:
> >Chris said that he wants channel binding and no sec layers, but later 
> >it was pointed out that not every implementor is ready to do channel 
> >binding to TLS at this time, so I *think* we have consensus that 
> >SCRAM should provide at least an integrity sec layer.
> 
> SASL security layers haven't succeeded. I don't know why. If you know 
> the reasons why, and they don't apply to SCRAM (as implemented by 
> randoms, not by ietf-sasl regulars), then fine. Otherwise it's just a 
> dead feature.

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

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

         The channel bindings data will have been:

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

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

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

That means:

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

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

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

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

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

Nico
--