Re: Holding gs2

[Nicolas Williams <Nicolas.Williams@xxxxxxx>]

OK, I've been thinking about this.

I think we should:

1) Formalize what a SASL mechanism that supports channel binding is.

   This would be an update of RFC4322.

   SASL mechanisms that support channel binding are SASL mechanisms
   whose client and server init/step functions take the following
   additional input parameters:

    - channel binding
    - security layers to be negotiated if channel binding succeeds

   and which perform the channel binding operation as part of the
   mechanism's authentication exchanges.  The security layers selected
   will be either the regular security layers as provided through the
   traditional inputs to these functions (if channel binding fails), or
   the second set of security layers input described above (if channel
   binding succeeds).

   This should suffice as guidance for anyone designing new SASL
   mechanisms that support channel binding.

   With a minor tweak such mechanisms can also be based on what I will
   call GS3 below.


Before I go on to (2) below, note that a SASL/GSS framework for GSS-API
mechanisms that support channel binding but where the framework will NOT
support any security layers is trivial: no MIC tokens are needed,
instead the client sends its initial token and authzid, with authzid ||
channel bindings as the GSS channel bindings, and thereafter it's a
normal, framed GSS-API context token exchange.


2) Decide whether we want:

   a) a new SASL/GSS framework which does not support security layers,
      and which can be described in terms of GSS-API mechanisms that
      support channel binding,

   or

   b) extend GS2 to do (a) but within the existing GS2 framework.

      Let's say that (2b) means having a long-form GS2 message exchange
      for some mechanisms or uses of them, and a short-form GS2 message
      exchange for others.

   c) We may also decided that we want to pursue a simple GSS-API
      extension to always support GS2 short-form message exchanges where
      GSS-API frameworks and mechanisms support that simple extension.

      This simple extension would consist, I think, of a new req_flag,
      GSS_C_CHANNEL_BINDING_REQ, for GSS_Init_sec_context() and two new
      ret_flags for GSS_Init_sec_context() and GSS_Accept_sec_context().
      The req_flag would indicate that the caller wants to know if: a)
      channel binding is supported by the mechanism, b) this extension
      is supported, c) whether channel binding succeeds.

      When this req_flag is used and the initiator and acceptor
      framework and mechanism support this extension then a) channel
      binding failure does not result in context establishment failuer,
      b) the new ret_flags are set as follows: GSS_C_CHANNEL_NOT_BOUND
      is set if channel binding failed, else GSS_C_CHANNEL_BOUND is set.


Let's consider (2b).

   If the application requests no security layers in the channel binding
   failure and success cases then:

   i) channel binding failure -> mechanism failure;

   ii) because of (i) the GSS-API channel semantics will match the SASL
       mechanism's channel binding semantics, therefore GS2 can use
       GSS-API channel bindings and dispense with the MIC token
       exchanges (i.e., GS2 short-form message exchange).

   If the application requests different security layers in the channel
   binding success and failure cases then GS2 must use the long-form
   message exchange.

Let's consider (2a).

   This would look just like the GS2 short-form message exchange
   described above, but would have a different SASL mechanism name
   prefix than GS2.

Let's consider (2c).

   In this case GS2 can automatically select which of the short-form and
   long-form message exchanges to execute based on the capabilities of
   the GSS-API framework and mechanism (on both, the initiator and
   acceptor sides).


I propose that we adopt (1) and (2b) as the simplest, yet general
solutions.

New, pure SASL mechanisms that provide channel binding but no security
layers can then be described that: a) need not be GSS-API mechanisms, b)
can nonetheless be implemented as SASL/GS2 mechanisms, and c) sport the
short-form message exchange.

New, pure SASL mechanisms that provide channel binding and optional
security layers will require the GS2 long-form message exchange (with
MIC tokens) when the application wishes to use security layers in the
case of channel binding failure, but will use the short form when the
applications requests no security layers in either case.

(1) and (2a) would be OK, of course.

(1) and (2c) would be the most general solution, but I wouldn't blame
the WG for not biting!

Nico
--