Subject: Channel Binding and GSS-API mechanisms

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Dec 2007 09:37:55 -0500

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.

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.

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.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 20 Dec 2007 15:52:57 +0100

> If we do find a channel where this is the right solutionwe'll have

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?

> 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 it makes the spec kind of complicated.

That may still be the case, though.

/Simon

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Dec 2007 10:04:58 -0500

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> Sam Hartman <[email-masked]> 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.

    Simon> There is a security consideration in GS2 about this:

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

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

No, I think the doc is fine.
The question is whether the WG is OK with that consequence.
My personal recommendation is no change in this area.

    >> 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.

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

    Simon> 4.3.1.  The GS2_Wrap function

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

    Simon> The rest of the document uses GS2_Wrap, not GSS_Wrap.

You cannot use channel binding with contexts that do not have
integ_avail.

So, if you are going to design a SASL mechanism as a GSS-API mechanism
and want channel binding to work, you must provide gss_wrap with
integrity tokens.

The GS2 document explains why we made that design decision.  I
understand and agree with that explanation.  I just want to make sure
the WG is aware of the consequences.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 20 Dec 2007 09:24:03 -0600

On Thu, Dec 20, 2007 at 09:37:55AM -0500, Sam Hartman wrote:
Sam> First, if you have a channel binding that requires
Sam> confidentiality for a channel that does not provide
Sam> confidentiality you cannot use it with GS2.  Honestly I don't
Sam> consider this a big deal because I cannot think of any reason
Sam> you'd define such a channel binding.  It seems like such a bad
Sam> idea I'd hope that the expert would decline the registration.  If
Sam> we do find a channel where this is the right solutionwe'll have
Sam> some work to do.

Correct.  It's because such a thing would be so silly that this doesn't
bother me in the least.

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

Sam> However if your mechanism is going to support channel binding
Sam> when it is used as a GSS-API mechanism, then it needs to also
Sam> support channel bindings in the GSS-API token.

Yes, this has bothered me before too, but I came to accept it as a
result of the difference in channel binding failure semantics that we
want for SASL vs. the GSS-API's.  I suppose we could work on a GSS-API
extension to make channel binding failure result in an output ret_flag
rather than plain failure, then we could use GSS channel binding in GS2,
say, but it turns out that there are lots of complexities there as well.

The biggest problem with the GS2 approach is that we lose the
opportunity to work the channel bindings into the mechanism's context
tokens, where it makes the most sense.  There was a discussion about
this after most of you left the SASL jabber room.

Sam> This complexity isn't a over-the wire complexity issue.  It does
Sam> not effect round trips.  If you are only implementing the SASL
Sam> mechanism there is not more work to do.

Sam> However it makes the spec kind of complicated.

I know.  I wish it weren't so.  I'll think a bit more about alternatives
that don't merely shift the complexity elsewhere.

Nico
--