Re: Poll: use of TLS channel bindings in SCRAM

[Nicolas Williams <Nicolas.Williams@xxxxxxx>]

On Thu, Jun 04, 2009 at 10:08:19AM +0200, Simon Josefsson wrote:
> Nicolas Williams <Nicolas.Williams@xxxxxxx> writes:
> > gs2-header       = gs2-cbind-flag [ authzid ] "," [ gs2-ext-attrs "," ]
> >                                                   ^^^^^^^^^^^^^^^^^^^^^
> > Or something like that.  (One might prefer something slightly different
> > that makes it easier to find the end of the GS2 header.)
> 
> Right, you need a reliable way to identify the end of the gs2-header.  I
> also dislike the complexity in a parser that always will have to ignore
> any number of gs2-* parameters, so how about this instead:
> 
> string     = 1*(UTF8-char-safe / "=2C" / "=3D")
> gs2-authzid  = "a=" string
> gs2-cbind-flag   = "n" / "y" / "p"
> gs2-nonstd-flag = "F"
> gs2-header       = [gs2-nonstd-flag "," ] gs2-cbind-flag "," [ gs2-authzid ] "," [ "gs2-ext" "=" string ] ","
> 
> Servers that doesn't understand a gs2-ext token MUST fail
> authentication.

The extension doesn't have to be critical to do what we want it to.
More importantly, we don't have an error message defiedn so any failure
could only be communicated through the SASL outcome of authentication
message, and that need not provide machine-readable mechanism-specific
information, so the mechanism on the client can't use any failure
information for, say, Kurt's multi-level negotiation proposal (though I
am not sure that he meant that seriously -- I certainly don't take it
seriously).

So I think "MUST ignore unknown" is good enough.

> Having thought about this proposal (briefly), I don't think an extension
> idea is a good idea.  What you propose is an extension mechanism inside
> a SASL mechanism.  I have a fairly strong general preference against
> that -- SASL is an extensible protocol, and the way to negotiate
> extensions is to specify a new SASL mechanism name and have clients
> prefer that mechanism.  The new mechanism can be a cut'n'paste of the
> old mechanism, plus some new wording.  I don't see a need for an
> extension mechanism inside GS2 here?

This is not an extension in that sense -- we're not negotiating new
features.  We're merely providing future downgrade protection against a
future negotiation that could be done via SASL mech name nego.