eap Mailing List: Re: issue 325 - channel bindings

[Jari Arkko (jari.arkko]

Bernard Aboba wrote:

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

Right. Add "While the verification can be done eithe rby the peer
or the server, typically only the server would have knowledge to
determine the correctness of the values, as opposed to merely
verifying their equality."

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

I fully agree.

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

Yes. We are not claiming that the approach is a good one, just that
its possible and that it has some issues (such as requiring exact match).
Do we want more text about the brittleness, or do you want to delete
the change altogether?

> > Channel Bindings are only interpreted by the lower layer.
>
>
> Maybe this should be "only interpreted by the lower layer or AAA layer."
Ok.

--Jari