eap Mailing List: RE: issue 325 - channel bindings

[Bernard Aboba (bernard_aboba]

> Channel Bindings
>
> Channel Bindings include lower layer parameters that are verified for   
> consistency between the EAP peer and server.  In order to avoid
> introducing media dependencies, EAP methods that transport Channel
> Binding data MUST treat this data as opaque octets.  Typically the
> EAP method imports Channel Bindings from the lower layer on the peer,  and 
> transmits them securely to the EAP server, which exports them to
> the lower layer.  However, transport may occur from EAP server to
> peer, or may be bi-directional.  On the side of the exchange (peer or  
> server) where Channel Bindings are verified, the lower layer passes
> the result of the verification (TRUE or FALSE) up to the EAP method.

As noted earlier by Yoshi, while channel binding comparisons
can be done on either the peer or server, only the server can verify that
the values are actually *correct*.  A peer cannot do this because it does
not have knowledge of the infrastructure.  Therefore while the channel
bindings can be passed in both directions, it seems that it is only
possible to address the "impersonation" problem if they are passed in the
direction of peer to server.  This is probably worth noting.

> It is also possible that the verification is performed entirely
> within the EAP layer. In this case, the EAP layer exports only the
> result to the lower layer. Given that EAP treats the data as opaque
> octets, verification at the EAP layer can only be performed as
> an exact match.

I'm not sure how this is supposed to work. The channel bindings which are
passed to the backend authentication server depend on what attributes the
NAS sends.  For example, it is not mandatory for a NAS to send
Called-Station-ID or Calling-Station-ID to the backend authentication
server.  An 802.11r implementation might send a
"Mobility-Domain-ID" attribute, while an 802.11i implementation
woudl not.  Similarly, the Channel Bindings sent up by the lower layer may
vary according to the implementation.

Given this, some policy is typically required in order to determine which
of the attributes MUST match, which can be ignored, what actions
are taken, etc.

Requiring an "exact match" would imply that exactly the same attributes
are sent by the NAS as are sent up by the particular driver
implementation, in the same format.  This would be very brittle;
unless the EAP peer, server and authenticator implementations are provided
by the same vendor, this seems unlikely to work reliably.

> Channel Bindings are only interpreted by the lower layer.

Maybe this should be "only interpreted by the lower layer or AAA layer."