Subject: RE: [eap] Re: issue 357: Channel Binding Definition

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 3 May 2006 19:00:37 -0700

Hi Yoshi,
Please see comments inline.  
 
> On Tue, May 02, 2006 at 03:02:21PM -0700, Narayanan, Vidya wrote:
> > I don't think the channel binding information needs to be 
> the same for 
> > all parties. For e.g., consider a case where the server has 
> a view of 
> > the SSIDs for which a given MSK is valid. The peer at a 
> given moment 
> > may only see a subset of the SSIDs - as it moves though, it 
> needs to 
> > know that a new SSID it sees may or may not use that MSK 
> for TSK derivation.
> > 
> > For this reason, actually mixing of the keys with channel 
> binding data 
> > doesn't quite make sense to me yet. This implies that the 
> peer has a 
> > complete view of the channel binding data at a given time, 
> which does 
> > not seem to make practical sense in all models of deployment.
> 
> Since I don't think the complete channel binding data is so 
> large, I don't see a practical issue here.  What is 
> deployment scenario in your mind?
> 

I'm not sure that there isn't a practical issue. Depending on the
authenticator location and the number of enforcement points under an
authenticator or how many ports the authenticator has, this could be
fairly large - and I don't think it is valid to say that the peer will
be able to have a complete view at all times. 

> > 
> > It may make sense for the peer have the entire channel binding data 
> > from the server - as it moves, it can compare to see if 
> what it sees 
> > is a subset of that data it received from the server or not.
> 
> I don't think only comparing subset of that data with the 
> server does not work for Channel Binding verification, as an 
> attacker can still fool around the rest of data that is not 
> part of the subset.
> 

Not really. The idea here is that the entire channel binding blob from
the server is integrity protected - so, if someone fooled with some of
that data, the integrity check will fail and hence, it becomes
detectable. But, the blob may contain, say, a concatenation of lots of
information. The peer would then have to compare what it got from the
authenticator or EP to the data it got from the server to say whether or
not that data was part of what the server sent it or not. 

> > Alternately, the
> > peer just needs confirmation from the server that what it 
> sees is valid.
> 
> This requires channel bindind data to be sent from the peer 
> to server, while the server pre-configures the channel 
> bindind data.  This is redundant information exchange to me.
> 

Not really. If the peer sent the channel binding data as it sees it, the
server only has to say whether or not it is correct. So, a protected
channel binding result indication is all is needed in the return path. 

Regards,
Vidya

> Yoshihiro Ohba
> 
> 
> 
> > 
> > 
> > Vidya
> > 
> > > -----Original Message-----
> > > From: Bernard Aboba [mailto:[email-masked]]
> > > Sent: Tuesday, May 02, 2006 12:23 PM
> > > To: Narayanan, Vidya; [email-masked]
> > > Subject: RE: [eap] Re: issue 357: Channel Binding Definition
> > > 
> > > That makes sense.  Do we also need to indicate that the channel 
> > > bindings need to be the same for all parties?  For example:
> > > 
> > > "Channel Binding
> > > 
> > > A secure mechanism for ensuring the synchronization and 
> correctness 
> > > of channel properties (such as endpoint
> > > identifiers) provided to the EAP peer, authenticator and server."
> > > 
> > > >Minor clarification:
> > > >
> > > >"Channel Binding
> > > >
> > > >A *secure* mechanism for ensuring the correctness of channel
> > > properties
> > > >(such as endpoint identifiers) provided to the EAP peer,
> > > authenticator
> > > >and server. "
> > > >
> > > >The word secure is to imply that if this data is in fact
> > > sent as a blob
> > > >between the peer and server, it must be integrity protected.
> > > >
> > > >Vidya
> > > 
> > > 
> > > 
> > _________________________________________________________________
> > To unsubscribe or modify your subscription options, please visit:
> > http://lists.frascone.com/mailman/listinfo/eap
> > 
> > Arhives: http://lists.frascone.com/pipermail/eap
> > 
> > 
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 04 May 2006 15:29:56 -0400

> be able to have a complete view at all times. 

I think not all pieces of information associated with the
authenticator have to be part of EAP Channel Binding data.  I mean
some information such as identifier of each enforcement point can be
bound locally betweeen peer and authenticator, using lower layer
chanel binding provided by SAP, as long as basic information such as
authenticator identity is validated using EAP Channel Binding and the
valid authenticator is advertising that locally bound information.

On the other hand I think the entire EAP Channel Binding data needs to
be available to the peer when keying material is exported by an EAP
method.  Otherwise, key scope becomes ambiguous at the time of
creating the keying material, which could open up some vulnerability
in key management.

> detectable. 

I am not sure I fully understand your idea.  Say Channel Binding data
is XYZ.  Suppose the peer learns X from the authenticator via lower
layer, but it does not yet learn YZ via lower layer.  How can the peer
determine that the authenticator is valid by only validating X but
before validating YZ?

> But, the blob may contain, say, a concatenation of lots of

Please see my comment above. Not all pieces of information associated
with the authenticator have to be part of EAP Channel Binding data.

> channel binding result indication is all is needed in the return path. 

What about the forward path?  I don't see a need for the peer to send
the Channel Binding data to the server if the peer learns the entire
Channel Binding data from lower-layer and the server pre-configures
the same data.

Regards,
Yoshihiro Ohba

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 04 May 2006 16:13:10 -0700

>creating the keying material, which could open up some vulnerability

Right.  Maybe we could make this clearer in the document.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 05 May 2006 09:47:42 -0400

> Right.  Maybe we could make this clearer in the document.

I agree.

Yoshihiro Ohba