Re: Poll: use of TLS channel bindings in SCRAM

[Nicolas Williams <Nicolas.Williams@xxxxxxx>]

On Fri, May 29, 2009 at 12:06:51AM +0200, Simon Josefsson wrote:
> 1a
> 4a
> 3
> 4b (I'm assuming it refers to tls-server-end-point)
> 1b
> 2
> 5 use YAP

Mostly the same for me, as you can see from my other post, but I need to
add some details.

After much discussion with Jeff H. and, separately, Sam H., I think the
following proposal is likely to be simple enough to garner consensus and
yet flexible enough to let us adapt to future conditions.  The proposal:

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

Note that there's no reference to tls-server-end-point in the above
proposal.  And notice that the server knows what channel binding type
the client chose.

Notice too that we are left in a position where we can actually add
channel binding type negotiation later.  Jeff has one sketch of such an
extension, and I have another.  Both rely on the fact that we have
mechanism negotiation to begin with.  Jeff's is an pseudo-mechanism for
negotiation (think of SPNEGO), and adds a round-trip.  Mine adds no
round trips, and does not have the N*M mechanism name registration
problem -- it adds new affixes like SCRAM/GS2's -PLUS suffix to indicate
the need for channel binding type negotiation, and uses the mechanism
negotiation to negotiate both: mechanism and channel binding type.
Details of these sketches should be discussed only to establish that we
will be able to add channel binding type negotiation later if we ever
need it, and, crucially, to show that the GS2 header field mentioned
above makes that possible.

The sum total changes to SCRAM/GS2 would be:

 - New text to describe the default channel binding type agreement
   process.

 - New text and ABNF to describe the new GS2 header field.

Comments?

Nico
--