Re: Channel Binding and GSS-API mechanisms

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

Sam Hartman <hartmans-ietf@xxxxxxx> writes:

> Folks, a couple of odd consequences of how GS2 and channel binding
> interact came to me during the meeting and I want to make sure we're
> aware of them and agree they are OK.
>
> First, if you have a channel binding that requires confidentiality for
> a channel that does not provide confidentiality you cannot use it with
> GS2.  Honestly I don't consider this a big deal because I cannot think
> of any reason you'd define such a channel binding.  It seems like such
> a bad idea I'd hope that the expert would decline the registration.
> If we do find a channel where this is the right solutionwe'll have
> some work to do.

There is a security consideration in GS2 about this:

   The channel binding is sent without privacy protection and knowledge
   of it is assumed to provide no advantage to an attacker.  This is a
   property that has to be considered when specifying channel bindings
   for a security protocol that will be used with GS2.

Is there anything else the document could say, or is this sufficient?

> The second problem is more concerning.  The way GS2 handles channel
> bindings makes it a bit tricky for things that want to be both a SASL
> mechanism and a GSS-API mechanism.  GS2 does not use the GSS-API
> binding facility.  It instead uses a wrap token.  So, you'll need to
> define a wrap token for your mechanism.

I don't think that is required, see section 4.3.1 of GS2:

4.3.1.  The GS2_Wrap function

   The GS2_Wrap function have two implementations, and which one is used
   depends on whether the negotiated GSS-API context supports per-
   message protection.  When a context is successfully negotiated (i.e.,
   when GSS_S_COMPLETE is returned from, for clients,
   GSS_Init_sec_context, or, for servers, GSS_Accept_sec_context) and
   the output variable integ_avail is FALSE, then GSS_Wrap cannot be
   used and instead we define GS2_Wrap to be the identity function.
   When integ_avail is negotiated TRUE, the GS2_Wrap is identical to
   calling the GSS_Wrap function with conf_flag set to FALSE and using
   the generated output_message as the output data.

The rest of the document uses GS2_Wrap, not GSS_Wrap.

> However if your mechanism is going to support channel binding when it
> is used as a GSS-API mechanism, then it needs to also support channel
> bindings in the GSS-API token.
>
> This complexity isn't a over-the wire complexity issue.  It does not
> effect round trips.  If you are only implementing the SASL mechanism
> there is not more work to do.
>
> However it makes the spec kind of complicated.

That may still be the case, though.

/Simon