Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt

[Nicolas Williams <Nicolas.Williams@xxxxxxx>]

On Mon, Apr 13, 2009 at 07:38:26PM -0700, Kurt Zeilenga wrote:
> 
> On Apr 13, 2009, at 4:07 PM, Nicolas Williams wrote:
> >I think what we can do then is this: the application MUST provide all
> >the types of channel binding available and the mechanism MUST pick one
> >to use according to the default rules we shall list (prefer
> >tls-server-end-point over tls-unique) or one specified for the  
> >mechanism
> >(YAP always insists on tls-unique).
> 
> My concern holds:
>   My view is that while GS2 mechanisms (such as SCRAM) handle channel  
> in similar ways (by design), we should not impose any restriction that  
> other mechanisms which support channel bindings do so in a like way.

I don't quite agree.  We're not saying "you can't use the channel
binding as an input to key derivation" or "you can't send the channel
binding as is."  What we are saying is: the channel binding type is not
negotiated, therefore it has to be known from context.

Ignoring YAP the relevant context is: the use or non-use of a TLS server
cert.  To allow for YAP we need to make the relevant context be
mechanism-specific (for YAP: always tls-unique, for all others so far:
the use or non-use of a TLS server cert).