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

[Kurt Zeilenga <[e-mail]>]

On Apr 14, 2009, at 12:37 PM, Jeffrey Hutzelman wrote:

>
> --On Tuesday, April 14, 2009 12:06:38 PM -0700 Kurt Zeilenga <[e-mail] 
> > wrote:
>
>>
>> RFC 4422 purposed avoided detailing APIs.
>
> We're talking about abstractions, not API's.


I argue that the I-D does detail interfaces (beyond what RFC 4422  
says).  It specifically discusses what and when channel binding  
information and mechanism information is to be passed between  
components of an implementation.

     In order to use SASL [RFC4422] with channel binding the client  
and server applications MUST provide a channel binding type and  
channel binding data to the selected SASL mechanism before the first  
mechanism's authentication message is produced (client side) or  
consumed (server side).
This is unnecessarily prescriptive.
>
>
>> It merely says that generally
>> possible to abstract interfaces between application protocols and a
>> framework and between a framework and a mechanisms.  It leaves the
>> particulars of what boundaries to draw between components of an
>> implementation to the implementation, as well as the particulars of  
>> what
>> is passed over those boundaries, and when, etc.
>
> Not really.  It _claims_ to do that, but then it goes on to describe  
> what is expected of protocols and mechanisms.  It _does_ create an  
> abstraction; if it didn't, it would be useless.

Yes, but it's descriptive in nature, not prescriptive.  I find the  
language in the I-D far too prescriptive.


>
>
> For example, we know that mechanisms produce tokens which the  
> protocol is expected to transport back and forth, but whose format  
> and semantics are known only to the mechanism.  And, we know that  
> the client and server sides of a mechanism always take turns  
> producing tokens, so that the protocol can transport them via a  
> challenge/response or request/reply sort of exchange.
>
> We know that mechanisms result in either success or failure, but  
> that it is up to the protocol to decide how to convey this from  
> server to client.  In the case of success, mechanisms also produce  
> an authenticated name, whose syntax and semantics are mechanism- 
> specific(*).
>
> We also know that protocols may provide an authorization name, whose  
> syntax and semantics are known only to the protocol, but which the  
> mechanism is responsible for transporting from client to server,  
> possibly (preferably?) in a secure manner.
>
> We know that mechanisms may provide a facility for encryption and/or  
> integrity protection of application data exchange after the  
> authentication process completes.  We know that when such a layer is  
> in use, it works by the protocol passing definite-length chunks of  
> protocol data ("buffers") to the mechanism, which transforms them  
> into buffers of protected data in a mechanism format.  The protocol  
> is then responsible for transporting the protected buffers and  
> handing them to the mechanism on the far end, which transforms them  
> back into plain protocol data.
>
>
> All of this, and more, we know because RFC4422 specifies these  
> things about the interaction between protocols and mechanisms,  
> without regard to which protocol and which mechanism.  That is an  
> abstract interface.  "Interface" does not always mean "C function  
> call API".

Of course.   I've tried to avoid use of the term API.

> What draft-ietf-sasl-channel-bindings does is extend the abstract  
> interface defined by RFC4422 to encompass handling of channel  
> bindings.

I argue that
	1) no change to RFC 4422 is required to "handle channel bindings"
	(the I-D implies changes are required)

	2) while adding some recommendations and considerations might be  
appropriate at this time,
         I generally think it premature to mandate particulars of  
channel binding in the SASL specification.

> It does so by saying that mechanisms may support channel binding and  
> protocols may provide CB data to the mechanism.

The I-D and its proponents appear to be arguing that changes to RFC  
4422 are required for SCRAM, YAP and other mechanisms to be  
successfully implemented and deployed, and uses this 'requirement' to  
justify nearly a dozen mandates.

I argue that the premise that changes to RFC 4422 are required is  
incorrect.  No change to RFC 4422 is required for such mechanisms to  
be successfully implemented and deployed.

So before we argue about individual mandates, I'd like the premise of  
the I-D to be restated.

> When the mechanism supports CB and the protocol client and server  
> both provide CB data, then authentication succeeds only when the CB  
> data provided on both ends matches.  Like the other items listed  
> above, this behavior is and should be independent of which protocol  
> and which mechanism is used.

I might agree to such so long as we don't mandate the CB data be RFC  
5056 CB data.  Now maybe I read too much in the draft, but given that  
my suggested SHOULD was not well received by Nico, I assume I read the  
I-D correctly.

>> No, we've (basically) decided that use of channel binding in SCRAM  
>> and GS
>> should be negotiable.   We haven't made any decision that all futures
>> that support channel bindings must do so in a manner which is  
>> negotiable.
>
>
>>> That means we MUST specify what channel
>>> binding means in the context of SASL.
>>
>> In the context of SCRAM certainly.  In general, no.
>
> No, if we do it at all, we must do it at the SASL layer.  Attempting  
> to do it only at the SCRAM layer violates the abstraction, by  
> requiring every protocol to have mechanism-specific knowledge.

RFC 4422 doesn't hide particulars of mechanism implementations from  
particulars of framework implementations from particulars of  
application protocol mechanisms.

The RFC 4422 abstraction only allows for protocols and mechanisms to  
be specified independently.

New mechanisms have always tended to introduce new data requirements  
which impact interfaces between components of an implementation.  Such  
an introduction does not break the SASL conceptional model, the impact  
is simply an artifact of the conceptional model.

RFC 4422 says:
    It is possible to design and implement this framework in ways that  
do
    abstract away particulars of similar mechanisms.  Such a framework
    implementation, as well as mechanisms implementations, could be
    designed not only to be shared by multiple implementations of a
    particular protocol but to be shared by implementations of multiple
    protocols.

So, from an RFC 4422 perspective, the differences in channel bindings  
between say it is possible to abstract away particulars of SCRAM and  
YAP channel binding, but that some future mechanism may not fit into  
that abstract.

> That would defeat the point of having SASL in the first place.

I guess we disagree on the point of SASL is.

>
>
>
>>> 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?
>>
>> Yes, and I agree it need not be mechanism specific.  However, I  
>> disagree
>> that it need be the same in all mechanisms.
>
> Then you missed my point.  The point is _not_ that it does not need  
> to be mechanism-specific.  The point is that it _does_ need to _not_  
> be mechanism-specific.  This is how we avoid writing a hundred new  
> RFC's whenever someone designs a new mechanism.  It's also how sane  
> application protocol implementors avoid having to change their  
> implementations for every new mechanism.

I argue it is premature to view our channel binding solution to be the  
end-all solution to channel binding.

> If you want to implement every combination of protocol x mechanism  
> separately, feel free.  But don't deny me the abstraction that  
> allows me to instead implement each protocol once and each mechanism  
> once,

Oh please.  Nothing I suggest hinders your ability to abstract away  
the particulars of mechanisms and protocols.  Folks have been doing  
this for ages.

> and further to let someone else do most of that work while I reap  
> the benefits simply by changing configuration.
>
> Abstraction is _important_.
> Modularity is _important_.

I assume some implementors will continue to let you do such that.   
Nothing in RFC 4422 ever said implementors of SASL were required to  
abstract away the particulars of mechanisms.  They simply choose to do  
so (and for good reason).

What RFC 4422 did was leave the particulars of such abstractions to  
implementors.  Whether and how a particular implementor chooses to  
abstract away any particular mechanism difference has been, and should  
continue to be, an implementation choice.

> These things provide scalability, and thus feasibility.
> These things make the difference between analysis that is too  
> complicated to be possible, and analysis that is simple enough to do.
>
> Having channel bindings work the same way for every protocol and for  
> every mechanism allows me to analyze how each protocol handles  
> channel bindings and how each mechanism handles channel bindings,  
> instead of having to separately analyze each combination.  This  
> significantly improves my job in promoting the security of my site  
> and of the Internet.
>
>
>> The point here is that any interface between components of an
>> implementation are implementation details, not protocol details.  RFC
>> 4422 specifies protocol, not implementation details.
>
> RFC 4422 specifies almost no protocol.
> It specifies an abstraction.

A very limited abstraction.

>
>
>> Your I-D gets into details which RFC 4422 left to implementors.  For
>> instance, it mandates what and when and how channel binding data is
>> passed between two components of implementation.
>
> No, it mandates what and when and how channel binding data is passed  
> between abstract components in a (implied) block diagram, which may  
> or may not bear any resemblance to an actual implementation.  In the  
> same way that RFC4422 mandates what and when and how mechanism  
> tokens or security layer buffers are passed between the same  
> abstract components.

I guess we'll just have to agree to disagree.