Re: Channel Binding and GSS-API mechanisms

[Nicolas Williams <Nicolas.Williams@xxxxxxx>]

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