Re: Update of GS2

[Simon Josefsson <[e-mail]>]

Here is the new version and rfcdiff compared to -01:

http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2.txt
http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-from--01.diff.html

I'm including the new channel binding section below.  It doesn't
reference draft-ietf-nfsv4-channel-bindings-04.txt because that
document doesn't contain the necessary details yet.

Is this approach regarding channel binding OK with everyone?

There is one more issue, maybe we can resolve it on-list:

* Should the document say that integrity/privacy layers
  MAY/SHOULD/MUST be negotiated?  If channel binding negotiation
  succeeds, it currently says:

   Implementations MAY set the "client_cbqops" and "server_cbqops" to no
   security layer to improve performance by using only one security
   layer.

  This seems acceptable to me, but we may also require that a security
  layer must always be negotiated if there is no channel binding.

  There is a complication when the GSS-API mechanism doesn't provide
  security layers.  Should we say anything about this?

The only remaining item, that I am aware of, is to add example
connections for channel bindings, but I'll work on that separately.

Thanks,
Simon

5.  Channel Bindings

   The GS2 mechanism provide its own channel binding mechanism, instead
   of using the "chan_binding" parameter in the GSS-API context
   functions.  The reason for this is that the GS2 mechanism provide an
   option to proceed even if the channel bindings does not match.  The
   GSS-API framework specifies that authentication cannot proceed if
   channel bindings does not match.

   Client and servers MUST set the "chan_binding" parameter in the calls
   to GSS_Init_sec_context to GSS_Accept_sec_context, respectively, to
   NULL.

   Implementations MAY set the "client_cbqops" and "server_cbqops" to no
   security layer to improve performance by using only one security
   layer.

   For TLS, the channel binding data is specified below.  For other
   security layers, channel binding data will have to specified
   elsewhere, and this specification will have to be updated with
   explicit considerations.

5.1.  Name Of TLS Channel For Use As Channel Binding

   The TLS Pseudo-Random Function (PRF) generate, using the constant
   string "TLS channel binding", and based on the master secret and the
   random values established during a TLS handshake, a 64 octet string
   that make up the SASL channel binding data.

   Using the terminology of TLS [13], the channel binding data is
   computed as follows:

          ChannelBinding =
             PRF(SecurityParameters.master_secret,
                "TLS channel binding",
                SecurityParameters.server_random +
                SecurityParameters.client_random) [0..64];

   The derived ChannelBinding is intended to be used as a name of the
   TLS channel that is cryptographically bound to the channel, for use
   in authentication mechanisms tunneled over TLS.