Re: Proposed Resolution to Issue 357: Channel Binding Definition
From: Yoshihiro Ohba (yohbatari.toshiba.com)
Date: Wed, 7 Jun 2006 11:20:00 -0700 (PDT)
On Wed, Jun 07, 2006 at 08:36:50AM -0700, Bernard Aboba wrote:
> >> Based on the above, how about the following definition?
> >>
> >> "Channel Binding
> >>
> >> A secure mechanism for ensuring that a chosen set of channel properties
> >> (such as authenticator identifiers and properties) are agreed upon by
> >> the EAP peer and server."
> >
> >After Jari's email, I created a thread "Channel Binding analysis" for
> >further discussion.  I still believe three party agreement is
> >essential for Channel Binding.  To me the two party agreement
> >mentioned above looks similar to issueing a Kerberos ticket that is
> >never verified by the consumers of the ticket.
> 
> The text mentions authenticator identifiers and properties, which 
> presumably were agreed upon by the authenticator that sent them (unless 
> it's a forgery).   

Then I think this presumption should be explicitly described in the
draft.

> However, there are also properties which don't relate to 
> the authenticator itself (such as Calling-Station-Id) but are transmitted 
> by the authenticator (e.g. to the backend server).   Are there any cases 
> where a property to be verified by Channel Bindings is *not* transmitted by 
> the authenticator?  Would the following work?
> 
> "A secure mechanism for ensuring that a subset of the parameters 
> transmitted by the authenticator (such as authenticator identifiers and 
> properties) are agreed upon by the EAP peer and server."

Transmitted to whom?  I think not all parameters do not need to be
transmitted to the server while all parameters need to be transmitted
to the peer.  In fact, if the server has the pre-established knowledge
about the parameters, the only information that needs to be sent from
authenticator to the server is authenticator identity which can be
used as the primary database look-up key to find out other parameters
associated with the authenticator identity.

Also I don't understand why peer's lower layer parameter such as
Calling-Station-Id needs to be agreed by peer and server.  What is the
actual threat without agreement?

Yoshihiro Ohba


> 
> I'm not sure what the definition of a "channel property" is in this case.  
> One could argue for example that the Calling-Station-Id is not a property 
> of the channel -- but its verification is still considered part of Channel 
> Bindings.
> 
> 
> 

Results generated by Tiger Technologies using MHonArc.