eap Mailing List: Re: Review of draft-arkko-eap-service-identity-auth-02.txt

[Bernard Aboba (aboba]

> Yes. There seems to be some support in various methods for
> it, but at least I have gotten the perception that such support
> was not fully baked and likely not implemented.

I think that's fair.  Part of the problem is figuring out how to implement
Channel Bindings without having to constantly update the method
specification for new parameters.  For example, suppose a new lower layer
supports a NAS-Identifier attribute; you'd want the EAP method to
automatically support that attribute and for the AAA server to be
able to verify it, all without a code update.

> I guess part
> of the reason for the draft was that, but the other part was that
> we wanted to avoid a situation where we start to lose the various
> independence properties of EAP, e.g., one method would only
> define the parameters for channel bindings in one L2 but not
> for others.

Right.  I think this is part of the update problem.

> In the Basic Facts thread Yoshihiro and myself talked also about
> this issue. One of the questions that was posed was why some
> particular node is set in a special role in this verification, and I'm
> not sure I can answer that fully yet.

I think that security may be part of the answer.  The AAA server obtains
its Channel Binding parameters within the AAA protocol, and therefore they
are integrity protected.  Also, if proxies are doing the recommended
checks along the path the parameters have been sanity checked.

On the other hand, the peer may have obtained parameters from the lower
layer with no security, so they could have been forged.  For example,
parameters obtained in an 802.11 Beacon or Probe Response can have been
sent by an attacker.  So I think that the peer and server are in different
positions with respect to confidence in the information they receive.

> I think we may need to understand the implications from
> the point of view of the different players. Many of the
> folks working on this technology look at things from the
> point of view of the providers; I at least confess I often
> focus too much on it.

One of the reasons for the interest in Channel Bindings is the potential
for fraud.  For example, a point of attachment can attract peers
via advertisement of misleading Channel Bindings, then provide different
information to the AAA server.

One attack that has gotten some publicity is the "Evil Twin" attack where
a rogue AP impersonates a popular SSID and attracts peers to attach to it.
It then spoofs popular web sites, potentially obtaining personal financial
information.

In a roaming environment, such an attack can succeed, even where EAP
methods supporting mutual authentication and strong encryption are used,
as long as the rogue AP can reach the home AAA server via some roaming path.
For example, one operator can masquerade as another operator to the user,
convincing them to attach and then charge the user for roaming to another
network.

In this scenario, the interest of the user and home server are probably
aligned: they want to prevent fraud.  The interest of the local operator
or downstream proxy may not be aligned with the peer and server depending
on whether they are in cahoots with the attacker.

> What I'd like to understand better is whether there's a similar
> issue the other way around. If the peer does not have the
> information, will there be some case where the server can
> claim something that the peer can't verify? For instance, could
> the server claim that there's a mismatch?

Yes, the server can claim there is a mismatch.  If the peer doesn't obtain
the server parameters, it can't verify if this is true or not.  This seems
like it could be an issue if only for debugging purposes: the AAA server
could be set up incorrectly, requiring an attribute that the peer doesn't
send.

> This is a good idea. There seems to be two parts in this: the
> format and the availability of AAA attributes. We may also
> have a situation where there's a legitimate need for information
> that is presently not available as an AAA attribute.

Since the AAA server can only verify the information sent by the EAP peer
against that it receives from the NAS, it would appear that this would
reuqire creating a new AAA attribute.  Something like a country code
appears to be a reasonable for that, IMHO.

> Right. We realized this in our recent list discussion. Our -02
> is the first step into this direction, but probably not yet
> sufficient.

One question is where the verification policy resides.  If it is on the
server, then the server can decide what attributes are required to be
present and which ones must match, without additional information from the
peer.  However, if the peer gets a say in this then maybe its opinions
need to be expressed.

> This is an issue. Any thoughts on how it could be solved?

I have only bad ideas, unfortunately.  EAP-TLS doesn't open a data channel
after TLS authentication completes.  This has been a source of frustration
when trying to extend it. The only (bad) idea I have is potentially to use
attribute certificates, and send the blobs that way.