[sasl] SCRAM as GSS-API mechanism

[Simon Josefsson <[e-mail]>]

I cannot find anything in section 8 of SCRAM that discuss how SCRAM, as
a GSS-API mechanism, handles a non-NULL GSS-API channel binding.  Is the
intention that this should be supported?

If it is not supported, we would be in the ironic situation that SCRAM,
as a GSS-API mechanism, does not support channel bindings, but GS2
requires that in order for the GSS-API mechanism to be used under GS2.
In other words, SCRAM cannot be used as a GSS-API mechanism for GS2.

I believe it could be made to work.  What is missing from SCRAM is some
wording that says that the only supported use of channel bindings is to
provide a GS2-compliant channel binding, e.g., on this form:

   The initiator-address-type and acceptor-address-type fields of the
   GSS-CHANNEL-BINDINGS structure MUST be set to 0.  The initiator-
   address and acceptor-address fields MUST be the empty string.

   The application-data field MUST be set to the gs2-header, excluding
   the initial [gs2-nonstd-flag ","] part, concatenated with, when a
   gs2-cb-flag of "p" is used, the application's channel binding data.

This is less generic than the Kerberos V5 GSS-API mechanism which allows
arbitrary channel binding data, but at least it would be consistent with
GS2 and would work when the application co-operates.

Thoughts?

/Simon