Re: Poll: use of TLS channel bindings in SCRAM

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

Nicolas Williams <Nicolas.Williams@xxxxxxx> writes:

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

That would work, but I'm not sure it is required.  I don't see what
advantage that gives over the current situation of not sending the
channel binding type and specifying that tls-unique (or
tls-server-end-point) should be used?

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

For the negotiation, I prefer the scheme with explicit channel binding
type negotiation in the mechanism name:

	SCRAM-SHA-1  (no channel binding)
	SCRAM-SHA-1-TLS-UNIQUE
	SCRAM-SHA-1-TLS-SERVER-END-POINT

(of course the names have to be changed to fit within the 20 character
limits)

This approach appears simpler and more robust than either yours or
Jeff's schemes, if I understand them all correctly.

My reasons against Jeff's scheme is that an additional round-trip is
performance costly and adds implementation complexity, and it is easily
avoidable.  Your scheme assumes that all mechanisms wants to use the
same channel binding negotiation approach, which I think can't be
assumed at this point.  I also think your approach fits badly with how
SASL mechanism negotiation are handled in some implementations, which is
a subjective opinion.

/Simon