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

[Nicolas Williams <Nicolas.Williams@xxxxxxx>]

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

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

> > > I can tell this issue of wire-compatibility is important to you, but
> 
> > Actually, it's not at all.  There is no wire compatibility in this case.
> > That was never the point.  The point is re-use.
> 
> Not to be catty or anything, but use has to preceed re-use.

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

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

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

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

	 The channel bindings data will have been:

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

      S: A r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
         ^ -------------------------------------------
	 |          SCRAM message
	 |
	 GS2 header indicating that the server accepts the client's max
	 buffer size and requested sec layers

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

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

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

	 The channel bindings data will have been:

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

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

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

	 Same as above, but with the smaller max buffer.

	 The channel bindings data will have been:

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

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

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

Comments?

Nico
--