2) Decide whether we want:
a) a new SASL/GSS framework which does not support security layers,
and which can be described in terms of GSS-API mechanisms that
support channel binding,
or
b) extend GS2 to do (a) but within the existing GS2 framework.
Let's say that (2b) means having a long-form GS2 message exchange
for some mechanisms or uses of them, and a short-form GS2 message
exchange for others.
c) We may also decided that we want to pursue a simple GSS-API
extension to always support GS2 short-form message exchanges where
GSS-API frameworks and mechanisms support that simple extension.
This simple extension would consist, I think, of a new req_flag,
GSS_C_CHANNEL_BINDING_REQ, for GSS_Init_sec_context() and two new
ret_flags for GSS_Init_sec_context() and GSS_Accept_sec_context().
The req_flag would indicate that the caller wants to know if: a)
channel binding is supported by the mechanism, b) this extension
is supported, c) whether channel binding succeeds.
When this req_flag is used and the initiator and acceptor
framework and mechanism support this extension then a) channel
binding failure does not result in context establishment failuer,
b) the new ret_flags are set as follows: GSS_C_CHANNEL_NOT_BOUND
is set if channel binding failed, else GSS_C_CHANNEL_BOUND is set.
I propose that we adopt (1) and (2b) as the simplest, yet general
solutions.
New, pure SASL mechanisms that provide channel binding but no security
layers can then be described that: a) need not be GSS-API mechanisms, b)
can nonetheless be implemented as SASL/GS2 mechanisms, and c) sport the
short-form message exchange.