Re: [sasl] SCRAM as GSS-API mechanism

[Jeffrey Hutzelman <[e-mail]>]

--On Tuesday, July 13, 2010 04:00:15 PM -0500 Nicolas Williams 
<[e-mail]> wrote:

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

In fact, when you use SCRAM-as-a-GSS-API-mechanism under GS2, GS2 adds that 
header back in, producing something that is wire-compatible with 
SCRAM-as-SASL-mechanism, which was the whole point.

-- Jeff