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

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

Hi Bernard,
Please see comments inline.  

> 
> > > I don't think the channel binding information needs to be 
> the same 
> > > for 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.
> 

Sounds like I have miscommunicated there :) I meant that while the
server may have a complete view of the channel properties, the peer may
not. It is important that the peer and server have the same view of the
properties they can both see, but the peer's view may only be partial.
Hence, it is not an A=B comparison, but more like A is a subset of B
relationship. 

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

There are two methods of obtaining channel binding as I can see - either
the server passes an integrity protected blob to the peer that it can
use to compare subsets it sees against or the peer passes what it sees
and the server vouches for it. The former can still happen in the
pre-authentication case. 

In the pre-authentication case, the EAP authenticator is the target
authenticator that talks to the EAP server. The fact that the
communication between the peer and the target authenticator is indirect
is irrelevant to the EAP server (as we discussed on some other threads,
the server may need to know about pre-authentication for some other
reasons, but not relevant for channel binding purposes). So, I would
think that the server will always know the channel binding information
for a given authenticator. If the peer pre-authenticates with multiple
target authenticators, it has a channel binding blob for every MSK
obtained. So, I don't see an issue with this. 

Depending on how the peer discovers the target authenticator, it may or
may not be able to use the method of passing the information to the
server at the time of pre-authentication. 

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

I am not suggesting that the lower layer security capabilities be part
of channel bindings - that would have to be in the beacon RSN IE or
equivalent. However, the authenticator ID and potentially the ports and
EP IDs for which the current EAP session was executed should be part of
the channel bindings data. When we consider a model where the
authenticator is a switch and has multiple APs attached to it, which are
EPs, the server could send a blob with the authenticator ID and the
multiple SSIDs, while the peer only sees one or two SSIDs, for instance.

In all of this, I was getting at the fact that the view of the channel
binding data at the peer may only be partial in reality and hence,
assuming that the full channel binding blob can be used with the MSK to
derive a compound MSK (without inclusion of the data in the EAP method)
does not always work. 

Vidya
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

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