Channel Binding and GSS-API mechanisms

[Sam Hartman <hartmans-ietf@xxxxxxx>]

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.