GS2 and SCRAM channel bindings

[Sam Hartman <hartmans-ietf@xxxxxxx>]

Hi.  I believe I've read enough of the mail and swapped in enough
state to have an informed opinion on the current channel bindings
discussions.

I believe that gs2 and scram should specify TLS unique channel
bindings as mandatory to implement when TLS channel bindings are used.

I believe that what we standardize today needs to support other
channel binding types besides tls-unique.  I'm not particularly
concerned with tls-server-endpoint although I believe we should keep
options open for that.  I believe that GS2 may be used in environments
where the channel type is not TLS, so the standard needs to support
that.  I cannot support publication of a GS2 or SCRAM standard that is
limited to TLS channel binding.

I'm dubious that we will ever need TLS channel binding negotiation, or
that if we do that it should happen in SASL rather than TLS.  In most
cases I think that the application will know what channel will be used
before SASL starts.  I've heard Kurt's arguments that we want to
negotiate channel binding type and allow a server to have SASL
mechanism selection influence channel binding type selection.  I do
not find these arguments compelling.



As such, I support a proposal where we carry the type of the channel
to be bound in GS2/SCRAM.  I'm fine carrying that all the time; I'm
fine carrying that only when it is not tls-unique.

I think it would be a good idea to have a way to carry additional
channel types without needing to generate new GS2 mechanisms.  I'm
happy with non-critical extensions at the GS2 layer as a way to do
that.  While I prefer having this option, I could support publication
of GS2/SCRAM that did not support additional channel binding types
being carried.

I'm reasonably happy with all the ABNF thrown around on the list that
is consistent with my goals.