GS2 meeting material

[Simon Josefsson <[e-mail]>]

Hi All,

Here are slides to guide discussions regarding GS2:

http://josefsson.org/sasl-gs2/ietf66-sasl-gs2.odp
http://josefsson.org/sasl-gs2/ietf66-sasl-gs2.pdf

The open issue is channel bindings.  I'm including the proposed new
section 5 that attempts to resolve this below.  Ideally, I'd like to
reference draft-ietf-nfsv4-channel-bindings-04.txt instead to define
channel bindings in GS2.  However, d-i-n-c-b is not ready and propose
to use the client/server finished messages -- this is discussed in my
presentation, and this seem to be the main open issue.

As always, more background is available from:

http://josefsson.org/sasl-gs2/

I hope to be available in the Jabber room during the meeting.

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 SHOULD set the "client_cbqops" and "server_cbqops" to
   no security layer and instead depend on the session security afforded
   by the bound-in channel.

   Use of no SASL security layers in combination with channel binding
   should provide better performance than using SASL security layers
   over secure channels, and better security characteristics than using
   no SASL security layers over secure channels without channel binding.
   For more discussions of channel bindings, see [16].

   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.