Subject: [sasl] SCRAM as GSS-API mechanism

From: Simon Josefsson <[email-masked]>
Date: Tue, 13 Jul 2010 22:35:09 +0200

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 13 Jul 2010 16:00:15 -0500

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

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

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

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 13 Jul 2010 16:28:48 -0500

On Tue, Jul 13, 2010 at 04:00:15PM -0500, Nicolas Williams wrote:
> [...]

Er, what I meant is that we cannot make it a requirement that the
gs2-header be present in the SCRAM-as-pure-GSS-API case.  Such a
requirement would conflict with RFC5554.

Quite clearly, when SCRAM-as-pure-GSS-API is used via a GS2
implementation the channel bindings data MUST be prefixed with the
gs2-header.

Aside from this my response remains the same.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 15 Jul 2010 11:55:29 -0400

> 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

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 Jul 2010 11:27:55 -0500

On Thu, Jul 15, 2010 at 11:55:29AM -0400, Jeffrey Hutzelman wrote:
> 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.

Right, I clarified my MUST NOT minutes later.  We must not require
GSS-API apps to prefix channel bindings data with the gs2-header -- the
only GSS-API that is allowed and required to do that is GS2.

If we started special casing channel bindings handling on a per-
mechanism basis, for anything other than the old "binding to network
addresses" thing, then we'd be making the GSS-API no longer a generic
API.

Nico
--