[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Poll: use of TLS channel bindings in SCRAM



Nicolas Williams <Nicolas.Williams@xxxxxxx> writes:

> Huh, I think we can do something far simpler still: just add enough ABNF
> to define non-critical GS2 header extensions.  (That's what I get for
> posting late at night instead of sleeping on the idea.)
>
> ;; Non-critical GS2 extension headers; servers MUST ignore if they don't
> ;; understand them
> gs2-ext-attr     = "gs2-" 1*ALPHA
> gs2-ext-attr-val = gs2-ext-attr "=" value
> gs2-ext-attrs    = gs2-ext-attr-val *("," gs2-ext-attr-val)
>
> ;; GS2 header
> gs2-cbind-flag   = "n" / "y" / "p"
> 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.

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?

So, my preferences are:

1) GS2 -13 but remove tls-server-end-point and only support tls-unique.

2) GS2 -13 plus the changes I proposed earlier to send a list of channel
binding types.  This allows tls-server-end-point to work if there is
someone that is willing to do the work (specify an outer negotiation
protocol) for that.

3/4) GS2 -13.
3/4) GS2 plus your Y/P proposal.
  Not sure how to rate these two against each other.  The Y/P scheme is
  close to an extension scheme.

5) GS2 plus the above extension scheme.

/Simon