ietf-sasl

[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: Poll: use of TLS channel bindings in SCRAM Jeffrey Hutzelman Thu May 28 23:00:30 2009


--On Friday, May 29, 2009 12:13:17 AM -0500 Nicolas Williams <[EMAIL PROTECTED]> 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