Re: Poll: use of TLS channel bindings in SCRAM

[Jeffrey Hutzelman <jhutz@xxxxxxx>]

--On Friday, May 29, 2009 12:13:17 AM -0500 Nicolas Williams 
<Nicolas.Williams@xxxxxxx> wrote:

>  - GS2 (and, therefore, SCRAM) will provide a DEFAULT channel binding
>    type agreement process for all SASL application protocols that do not
>    provide their own channel binding type agreement.
>
>    This default would be:
>
>     - Servers MUST implement tls-unique;
>     - Clients MUST implement tls-unique;
>     - Clients MUST choose the highest-layer/innermost end-to-end TLS
>       channel as the channel to bind to;
>     - Clients SHOULD choose the tls-unique channel binding type.
>
>       Conversely, clients MAY choose a different channel binding type
>       though: user input, configuration, or a future, as-yet undefined
>       channel binding type negotiation protocol.
>
>     - clients MUST convey to the server, through GS2, which channel
>       binding type it chose.
>
>  - The GS2 header needs a to gain a field by which the client can tell
>    the server what channel binding type it chose (see above).
>
>    This header should either always be present, or it should be present
>    only when the client chooses a channel binding type other than the
>    default.  If it's easier for the WG to accept this new GS2 header
>    field by making it not present in the default case, then so be it.

Yup, that's it.  Except...

 - Clients SHOULD choose the highest-layer/innermost end-to-end TLS
   channel as the channel to bind to;

That is, s/MUST/SHOULD/, to avoid inadvertently prohibiting clients from 
binding to a channel type other than TLS.



BTW, note that we say both client and server MUST implement tls-unique; 
this assures that a secure, interoperable configuration is possible, but 
does not preclude other configurations.

-- Jeff