issue 357: Channel Binding Definition

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