Re: [sasl] SCRAM as GSS-API mechanism

[Nicolas Williams <[e-mail]>]

On Tue, Jul 13, 2010 at 10:35:09PM +0200, Simon Josefsson wrote:
> 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?

The text could be clearer, but it follows from this:

   SCRAM is actually also a GSS-API mechanism.  The messages are the
   same, but a) the GS2 header on the client's first message and channel
   binding data is excluded when SCRAM is used as a GSS-API mechanism,
   and b) the RFC2743 section 3.1 initial context token header is
   prefixed to the client's first authentication message (context
   token).

and from knowing GS2 and subtracting GS2's ABNF from SCRAM's, that in
the pure-GSS-API variant of SCRAM gs2-header gets re-defined from this:

   gs2-header      = gs2-cbind-flag "," [ authzid ] ","

to this:

   gs2-header	   =
		   ;; empty

Which means that cbind-input gets re-defined from this:

   cbind-input   = gs2-header [ cbind-data ]

to this:

   cbind-input   = [ cbind-data ]

What we could, and maybe should have done, is to publish the ABNF for
SCRAM-the-pure-GSS-API-mechanism's security context tokens.

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

Just a reference to RFC5554 might do.  Clearly, SCRAM cannot and does
not support anything but the application-data field of
GSS-CHANNEL-BINDINGS since we did not provide an encoding of
GSS-CHANNEL-BINDINGS for SCRAM.

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

Yes, this follows from the fact that SCRAM doesn't provide an encoding
of GSS-CHANNEL-BINDINGS.

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

No, absolutely not.  See above.  The gs2-header MUST NOT be present in
the SCRAM-as-pure-GSS-API case.

IMO a simple erratum for RFC5802 adding a reference to RFC5554 and a
paragraph stating that SCRAM supports only the use of the
application-data field of GSS-CHANNEL-BINDINGS will do.

Nico
--