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

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 2 May 2006 15:02:21 -0700

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. 

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. Alternately, the
peer just needs confirmation from the server that what it sees is valid.

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 02 May 2006 18:42:20 -0400

> 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?

> 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.

> Alternately, the

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.

Yoshihiro Ohba

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 02 May 2006 16:20:22 -0700

> > all parties.

The goal of Channel Bindings is to ensure that the EAP peer and server 
obtain correct information from the EAP authenticator.  If a parameter is 
being validated by channel bindings and the authenticator gives a different 
value to the peer and server, then it will be detected.

It is true that all participants may not have complete knowledge of all the 
channel properties.  But if a parameter is included in channel bindings, 
then the goal is to ensure that the peer and server are hearing the same 
thing from the authenticator, so it seems to me that channel binding 
parameters need to be known by the peer, authenticator and server.

>For e.g., consider a case where the server has a view of the SSIDs for 
>which a given MSK is valid.

The server may have an opinion as to what SSIDs the peer is allowed to use 
(e.g. Allowed-SSIDs).  This is useful in EAP pre-authentication where the 
server may not know what SSID the client wants to access yet (this isn't 
known until the peer associates).   However in this case the SSID would not 
be considered to be part of channel bindings since the EAP peer has the 
information, but the authenticator and server do not.  As a result, the peer 
cannot ask the server to verify the SSID, or include it in the calculation 
of the MSK.

>As it moves though, it needs to know that a new SSID it sees may or may not 
>use that MSK for >TSK derivation.

In 802.11, the advertisement of AP capabilities is handled in the Beacon.  
This allows the STA to know what security mechanisms are being used (WPA2, 
11r, 11w, etc.).  The capabilities are verified in the handshake between the 
STA and AP.

However, there are AAA attributes corresponding to the AP security 
capabilities so that it is not possible for the EAP peer and server to 
verify that the authenticator has told them the same thing.  As a result, I 
don't think that 802.11 security capabilites can be considered "channel 
bindings".