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

[Nicolas Williams <Nicolas.Williams@xxxxxxx>]

On Tue, Apr 14, 2009 at 10:39:14AM -0700, Kurt Zeilenga wrote:
> On Apr 14, 2009, at 7:39 AM, Jeffrey Hutzelman wrote:
> >Channel bindings are not a parameter for the mechanism to "use"  
> >however it wants.
> 
> The point is more that we shouldn't assume there is one and only one  
> channel binding framework.  RFC 5056 and the particulars of this I-D  
> are in their early stage in its adoption, we should be careful not to  
> assume either is the end-all solution to channel bindings.  For  
> instance, it's quite unclear that the dual naming approach is the end- 
> all negotiation solution (we haven't tried it in the real world yet).
> 
> Channel binding to me is, I think, still a limited extension to SASL.   
> No well established mechanism uses channel binding, and we only have a  
> couple presently in the works.

But that's precisely why we now must define what channel binding means
in the context of SASL.  By "means" I mean: what impact it has on
abstract APIs, and, since we've decided to make the use of channel
binding negotiable, what impact it has on application protocols.

> I simply think it's too early to treat channel bindings as if it were  
> a mature feature of SASL.

I don't understand that statement.  We have consensus, I think, for
SCRAM not providing security layers and for relying on channel binding
for protection against MITMs.  That means we MUST specify what channel
binding means in the context of SASL.  Whether what we specify is
"mature" or not does not enter the picture -- the IETF does not insist
on deployment before standardization, and I'm surprised to see you
arguing, effectively, that it does.

> >Now, to date your objections have been quite vague.
> 
> At present, I am trying to focus on the primary issue I have and hence  
> I haven't attempted to slam each secondary issue I have.  That would  
> be a lot of work, as I have problems with nearly every line of the I- 
> D.  Hence, at present, I intend to focus on the basic premise of the I- 
> D which I disagree with.

You're not giving us much to work with.  State your objection(s).
(Though I believe I've figured it out from your reference to YAP, as I
wrote earlier.)

> From section 1:
> >   The introduction of the Salted Challenge Response (SCRAM) SASL  
> >mechanism [I-D.newman-auth-scram] and GS2 family of SASL mechanisms  
> >[I-D.ietf-sasl-gs2] requires the introduction into SASL of an  
> >abstract interface to channel binding [RFC5056].
> 
> I simply disagree that the introduction of mechanisms which support  
> channel bindings requires any change to RFC 4422.  While certainly  
> introduction of mechanisms with new features requiring new kinds of  
> information to be provided to it will require changes in  
> implementation to obtain and provide this information, this is already  
> discussed in RFC 4422.

Did you read the sub-thread we had where Jeff H. commented that the
logic for selecting a channel binding type to use needed to be not
mechanism-specific?  That's what gave rise to this I-D.  It might help
for you to comment on Jeff's points.

> And as far as the statements premise referring to a need to establish  
> what the INTERNAL interface between components of an implementation,  

I wrote "abstract."  It's definitely NOT an internal interface.  We've a
number of applications available for Linux/Solaris/*BSD/Windows that use
SASL via a system library.  Those interfaces are most definitely
public, not internal.

> such as component primarily implementing an application protocol, a  
> component primarily implement a SASL framework, a component  
> implementing a particular SASL mechanism, a component implementing a  
> lower-lever security service such as TLS, I argue that these are  
> implementation details.

The interfaces between those components must be public interfaces unless
the application is monolythic (i.e., all the components are from the
same implementor, tightly integrated, and not separately
replaceable/updateable).

>                           RFC 4422 has no business specify what is to  
> passed between such components and when... it shouldn't even make  
> assumptions that such components exist as separate modules of code  
> with distinct abstract interfaces between them.  Very unlike this  
> document, RFC 4422 purposely avoided getting into the details of  
> interfaces between components of an implementation.

Nonsense.  Why even have RFC4422 if there's no room for public SASL
interfaces?

Nico
--