Subject: [eap] network discovery & selection: problem definition

From: Jari Arkko <[email-masked]>
Date: Fri, 28 Nov 2003 19:07:11 +0200

Folks,

In IETF-58 we discussed network discovery and selection issues,
and the straw poll indicated that the WG wants to work on this.

I'd like initiate a discussion on the problem definition
for this work before actually adopting it as something that
the EAP WG intends to standardize. As a result of the discussion,
we should know what the issue is, what functions are required, and
what constraints should be placed on a potential solution.

Here is the plan for the discussion:

  o  All input should be received by December 15. The goal
     is to have also a common understanding of the problem
     by then.

  o  Lets keep the actual solution discussion separate. In
     other words, lets not talk about the pros and cons of
     different approaches, or where this functionality should
     be placed in terms of the network or the protocol stack.

  o  The results of the discussion will be summarized by
     the chairs. The need for documentation in the form
     of a draft will be determined during the process.

  o  Next steps after this discussion has been concluded
     include another discussion & possible drafts in the
     solution space. At that time we also need to make
     a decision whether the work should stay in the EAP WG
     or be moved elsewhere.

The following is my first cut at the problem definition.
Comments appreciated -- I'd be happy if you can shoot my
definition down. I have included a few questions within
the definition -- if you have answers I'm sure the group
would like to hear them.

The primary network discovery and selection issue
is routing within the AAA infrastructure, giving
access to the user from the right home AAA and via
the right AAA proxies. Currently, we have the NAI [RFC2486]
functionality. NAIs allow users to specify their
domain so that the AAA requests can be routed to the
right home AAA servers. However, this does not provide
support for the following:

   o  Ability of the client to know which of his multiple
      home networks are available from a given access?
      Can I get to [email-masked], or only to
      [email-masked]?

   o  Ability of the AAA requests to be routed correctly
      where there is no complete, global AAA routing table.

      Deployed AAA mechanisms use an essentially
      statically configured local routing tables,
      there is no e.g. link state routing protocols
      for AAA.

      Such local mechanisms are sufficient when there
      limited amout of branching in the AAA network.
      For instance, there is no need for a global
      routing table if all your clients are either
      locally authenticated or served by one other entity
      (such as a global ISP, teleoperator, or a roaming
      consortium).

      However, if the access network supports two different
      intermediaries, it becomes necessary to figure out
      which intermediary handles the domain given in a NAI.

      Question: what is the expected number of intermediaries
      per one network hop? Can you cite current numbers from
      existing networks, or projections of future network
      topologies?

      Question: Is it necessary to support multiple levels
      of selection, e.g. go first to intermediary 1, then
      to intermediary 2, etc?

   o  For commercial reasons, intermediaries want
      to participate the AAA transaction.

      Question: Is there a need for someone else than
      the access network to control the routing to go
      via a special intermediary? This is not very
      clear to me.

   o  For the purposes of choosing an intermediary
      with specific properties, users may wish to
      control network selection, or at least wish
      to be aware of the results. For instance,
      I can get to @ericsson.com either via piuha.net
      or commercialoperator.net, but since I want to
      go via piuha.net since it is free for me.

      Question: what are the security requirements for
      this? This is bordering on solution space, but as
      far as I know, none of the proposed mechanisms
      can support secure advertisements or secure
      selection indications. Is this acceptable?

      Question: what kind of information needs to be
      presented in protocols vs. provisioned in the
      clients vs. simply told to the user off-line?
      It seems that it would be possible to provide
      network name over protocols, but a standardized
      format for offered CoS of QoS would probably
      not be possible.

An interesting twist in the AAA routing problem
is that all the above has to work for requests, responses,
as well as server-initiated messages.

The network discovery and selection problem is closely
related to the problem of access point discovery and
selection in wireless networks. The two problems coincide
when each access point offers exactly one network over
one AAA route. However, the network discovery and selection
problem may exist even where there is just one access
point to attach to, if it offers multiple networks
or multiple routes to these networks.

During the discussion of solutions for these problems,
it has become apparent that there are some additional
constraints that may have to be placed on solutions.
Some of the possible constraints are listed below:

   o  Solution can be adopted for the whole network
      without requiring changes to the largest base
      of installed devices -- access points and
      clients.

   o  Allow interoperability with clients, access networks,
      AAA proxies, and AAA servers that have not been
      modified to support network discovery and selection.

   o  Works on all AAA protocols.

   o  Does not prevent the introduction of new AAA or
      access network features, such as link-state AAA
      routing protocols (pretty far fetched) or
      fast handoffs.

   o  Does not consume a significant amount of
      resources, such as bandwidth or network
      attachment time.

   o  Does not cause a problem with limited packet
      sizes of current protocols.

Further discussion can be found from
http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-and-selection-00.txt
(including some solution space issues too).

--Jari

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 Nov 2003 14:38:29 -0500

-----BEGIN PGP SIGNED MESSAGE-----

An additional area, maybe out of scope:
    how do I know that these intermediaries are legitimate, vs MITM?

i.e. how do I avoid being tricked into selecting the wrong network?
- -or- do I believe anything I've discovered?

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Sat, 29 Nov 2003 00:26:28 +0200

>     how do I know that these intermediaries are legitimate, vs MITM?

I suppose they still have to be legitimate AAA proxies.
That is, an access network should not send your request to
an unknown intermediary. If it has a business relationship
with three intermediaries int1.com, int2.com, and int3.com,
it will route your request through one of them, even if you
tried to request routing through mitm.org.

Its good that you brought this up! This is a requirement.
And if we don't write it down, an implementation might
actually forget to check this.

An additional issue is that even if the intermediaries
are legitimate, they could be switched. For instance,
an access network could advertise that it has a deal
with elcheapointermediary.net, and then switch the user's
selection to pricey.com instead. To make this relevant,
the pricing would have to be based on the intermediary.
Furthermore, even if were to secure the selection, we
would be unable to guarantee that the QoS or other
properties claimed by the network were indeed provided.
This leads me to think that at the moment, the advertisements
and selections cannot be more than hints, and everyone should
be made aware of that. Typically, non-protocol means
are used to detect problems like that. [Solution space:
Independent of the network selection issue, some of
us have talked about ways to authenticate claims made
by access points and service selections picked by the
client. It looks like we could do it as a backwards
compatible extension of popular EAP methods such as
EAP-TLS or EAP-SIM. I would rather design a general
feature for such protection rather than somethign
specific for network selection.]

--Jari

---

From: Michael Richardson <[email-masked]>
Date: Sat, 29 Nov 2003 18:34:35 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Jari" == Jari Arkko <[email-masked]> writes:

    >> how do I know that these intermediaries are legitimate, vs MITM?

    Jari> I suppose they still have to be legitimate AAA proxies.
    Jari> That is, an access network should not send your request to
    Jari> an unknown intermediary. If it has a business relationship
    Jari> with three intermediaries int1.com, int2.com, and int3.com,
    Jari> it will route your request through one of them, even if you
    Jari> tried to request routing through mitm.org.

  It is more immediate than that.

  Let's assume that there are two competing hotspots, physically adjacent
to each other. The signal is available in both locations. Both are using
NAT. 

  Call the two operators DeltaCoffee and GammaCoffee. They are using ESSID
"delta" and "gamma". Both make deals with arkohotspotproxy.com, the most
popular clearing house for EAP-AKA based payments.

  However, GammaCoffee has found a way to make money without spending much.
  They set their ESSID to "delta", and respond to EAP.

  As a supplicant, one could get a EAP Request from either one. Let's say
that I get one from GammaCoffee's AP. It takes my request, goes back on the
wireless, authenticates against arkohotspotproxy.com using radius. Yes,
passing the packets to DeltaCoffee's AP, to which it has already
authenticated *itself* with.

  The supplicant and authenticator do their thing, and then the supplicant
gets an IP address from GammaCoffee's AP. supplicant's packets are NAT'ed by
Gamma, and sent to Delta (who NATs them again).

  The result:
      Gamma gets a revenue stream from arkohotspotproxy.com
      Delta pays for the bandwidth

  If the charges are based upon per-byte, then maybe Gamma has to pay Delta
as much as it takes in. If they are based upon time, then Gamma wins. 
  (Best is if Gamma manages to steal a username/password along the way,
from some user that is willing to do username/password instead of something
that is secure)

---

From: Jari Arkko <[email-masked]>
Date: Sun, 30 Nov 2003 12:01:32 +0200

>   It is more immediate than that.

Ok, reading on...

>   They set their ESSID to "delta", and respond to EAP.

This could happen, yes.

> authenticated *itself* with.

Are you thinking that the GammaCoffee's AP simply has its own userid for
access to DeltaCoffee, or some sort of a mitm authentication attack?
I am assuming the former, because I do not see the mitm authentication
attack here. Only one of the access points gets the session keys from
the home AAA. The other AP would not, and hence one of the AP could not
complete the 4-way handshake or send/receive packets.

> from some user that is willing to do username/password instead of something

I think I see your attack (if my assumption above was correct). Its an
interesting attack, though I'm not sure how specific it is to network selection
or even to authentication mechanisms such as EAP. Here's why: the current
network access mechanisms enable us to have authentication, and link layer
protection. They do not, however, guarantee anything about the delivery of
the actual payload packets. In particular, there is no guarantee that the
payload packets are delivered through a right route, or NATed only up to
some specific number of times.

We could call this the "payload route binding problem". In this
problem, authentication and l2 support do not guarantee that
the packets are actually routed through the path that appears to have
been offered. Basically, if I have a flat fee account *and* a deal with
a clearing house, I can offer access to anyone with a per-byte account,
NAT their packets, and send the traffic forward on my account, and get
a lot of money. The local ISP would not be any wiser, as I could tunnel
my AAA packets through him encrypted. The user would not be any wiser
either, because there's nothing in 802.11i or EAP that binds the SSID
to the authentication. And even if there were, the user wouldn't care
about the SSID enough to look at it. You would probably be breaking
the contract with your provider, often they have just-one-machine
clauses. But it would be hard for them to detect this.

In conclusion this looks like an interesting attack. It appears
to exist without any network selection functionality, so its a
general issue. What would you like to do with this issue - solve
or document it? I am not sure if we talk about something like this
already in the keying document. Or maybe we should go into business
together and start selling software that does this on the background
on everyone's PC ;-)

--Jari

---

From: Michael Richardson <[email-masked]>
Date: Sun, 30 Nov 2003 16:16:47 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Jari" == Jari Arkko <[email-masked]> writes:
    Jari> Are you thinking that the GammaCoffee's AP simply has its own
    Jari> userid for 
    Jari> access to DeltaCoffee, or some sort of a mitm authentication attack?

  Either way.

  If DeltaCoffee regularly uses username/password to get online (such as,
for instance, for regular customers, or for the "staff" machines), then it is
trivial for GammaCoffee to steal such an ID.
  But, we agree that those methods are inheirently insecure.

    Jari> I think I see your attack (if my assumption above was correct). Its
    Jari> an 
    Jari> interesting attack, though I'm not sure how specific it is to
    Jari> network selection 

  If the customer can figure out which AP belongs to DeltaCoffee and which
ones does not, then they customer can input this to their selection
algorithm.

  Btw, this was essentially the situation that we had at the last IETF,
except that the "rogue APs" weren't so cooperative as to route our packets.

    Jari> network access mechanisms enable us to have authentication, and
    Jari> link layer 
    Jari> protection. They do not, however, guarantee anything about the
    Jari> delivery of 
    Jari> the actual payload packets. In particular, there is no guarantee
    Jari> that the 
  
  Right, so this opens up the whole system up to disputes that one was
charged for service that was not received. You included QoS and pricing
in your "selection" algorithm.
  (No service is a QoS)

    Jari> We could call this the "payload route binding problem". In this
    Jari> problem, authentication and l2 support do not guarantee that
    Jari> the packets are actually routed through the path that appears to have
    Jari> been offered. Basically, if I have a flat fee account *and* a deal 

  If I took a shared key from the EAP EMSK somewhere, and used that to
authenticate the DHCP server (3118), it might have a serious positive
benefit. 

  In v6 land, we could use the channel created by EAP to provide the
certificates for the SEND secured RA. Both ways, that means that we are 
sure we are speaking at layer 3 to the services that we authenticated at
layer two.
  
    Jari> a lot of money. The local ISP would not be any wiser, as I could
    Jari> tunnel 
    Jari> my AAA packets through him encrypted. The user would not be any wiser
    Jari> either, because there's nothing in 802.11i or EAP that binds the SSID
    Jari> to the authentication. And even if there were, the user wouldn't care
    Jari> about the SSID enough to look at it. You would probably be breaking
    Jari> the contract with your provider, often they have just-one-machine
    Jari> clauses. But it would be hard for them to detect this.

  The one-machine clause has effectively died around here, with pretty much
all the ISPs selling "network sharing" NAT boxes themselves.

    Jari> In conclusion this looks like an interesting attack. It appears
    Jari> to exist without any network selection functionality, so its a
    Jari> general issue. What would you like to do with this issue - solve
    Jari> or document it? I am not sure if we talk about something like this
    Jari> already in the keying document. Or maybe we should go into business
    Jari> together and start selling software that does this on the background
    Jari> on everyone's PC ;-)

  I'd like a way to avoid the attack by careful network selection.
  If you think it is out of scope - that's fine. But it is, in my opinion
one of the major things that has fallen through the cracks between IETF
and IEEE. cf. my comment last summer about "subipSEC"