Re: Poll: use of TLS channel bindings in SCRAM

[Nicolas Williams <Nicolas.Williams@xxxxxxx>]

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

So today SCRAM/GS2 would be essentially unmodified from what we had
going into this poll.  Later, when we add CB type negotiation we can add
an attribute for listing the CB types that the client saw in the 'y' and
'p' cases, and an attribute for specifying the CB type chosen by the
client in the 'p' case.

(And if we really wanted to we could add critical GS2 header extensions,
which, if present, cause the server to reply with an error if the server
doesn't understand the extension, else with a normal GSS context token
prefixed with a small header to distinguish from such errors.  Then even
Kurt's multi-level negotiation scheme could be added.)

Nico
--