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

From: Jari Arkko <[email-masked]>
Date: Mon, 01 Dec 2003 13:01:50 +0200

Michael Richardson wrote:

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

This is interesting. But, as far as I can see, this does not completely solve
the problem. In v4, the attacking node would simply offer its own DHCP
server, the user would authenticate it and get an internal IP address
from it. Then the attacking node would NAT all the packets to an
address provided by the real bandwidth provider.

The situation isn't much better in v6, except that we might perhaps expect
or even verify that there is no NATs in between. If we could do that, then
the RA signatures are sufficient to bind our own address - router - access
authentication together.

And if the attacker tunnels everything through the access
network to a centrally placed server, then neither EMSK or
RA certs are going to be very helpful. But in this case
the attacker would have to provide at least some central
bandwidth, even if he can skip the provisioning of the
access network.

I'm ccing Bob because he was recently interested in certificates
handed out from L2.

>   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

Its probably in scope for IETF to figure out, but this might also be bigger
than network selection issue and handled separately. Anyway, lets focus
on mapping what the problem is, when that concludes we can think about
how to divide the work.

> one of the major things that has fallen through the cracks between IETF
> and IEEE. 

Agreed. Part of the reason for this is that the understanding of
various binding issues has only grown recently... and I think we
are still learning, as far it comes to IP vs. L2 issues.

--Jari

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 01 Dec 2003 11:32:27 -0500

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

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

    Jari> We could call this the "payload route binding problem". In this
    Jari> problem, authentication and l2 support do not guarantee that the
    Jari> 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
    >> 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> This is interesting. But, as far as I can see, this does not
    Jari> completely solve the problem. In v4, the attacking node would
    Jari> simply offer its own DHCP server, the user would authenticate it
    Jari> and get an internal IP address from it. Then the attacking node
    Jari> would NAT all the packets to an address provided by the real
    Jari> bandwidth provider.

  Assuming that we can solve the original layer 2 problem - of authenticating
with the right AP, then we can also solve the equivalent layer 3 problem

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

]       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"); [

---

From: Jari Arkko <[email-masked]>
Date: Mon, 01 Dec 2003 18:58:00 +0200

> with the right AP, then we can also solve the equivalent layer 3 problem

Why? Perhaps I'm missing something obvious. But even if I authenticate
Gamma to be Gamma in IEEE/EAP/AAA, and Gamma's router in SEND, Gamma
can still NAT all my traffic and send it off to Delta.

But perhaps you are thinking that the user will see "Gamma" on his
screen and cry foul. I'm not very optimistic that most users would do
this... Even you and I might have trouble understanding whether
"Gamma Global Roaming WLAN" is a legal, another SSID on a virtualized
"Delta" AP or a bad guy performing an attack.

--Jari

---

From: Michael Richardson <[email-masked]>
Date: Mon, 01 Dec 2003 12:50:21 -0500

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

    >> Assuming that we can solve the original layer 2 problem - of
    >> authenticating with the right AP, then we can also solve the
    >> equivalent layer 3 problem

    Jari> Why? Perhaps I'm missing something obvious. But even if I
    Jari> authenticate Gamma to be Gamma in IEEE/EAP/AAA, and Gamma's router
    Jari> in SEND, Gamma can still NAT all my traffic and send it off to
    Jari> Delta.

    Jari> But perhaps you are thinking that the user will see "Gamma" on his
    Jari> screen and cry foul. I'm not very optimistic that most users would
    Jari> do this... Even you and I might have trouble understanding whether
    Jari> "Gamma Global Roaming WLAN" is a legal, another SSID on a
    Jari> virtualized "Delta" AP or a bad guy performing an attack.

  Of course.  And his bill will say "Gamma".
  And if necessary, the customer can dispute it. 

  But, the customer now has the tools to prevent this abuse. If they choose
not to, well, fine. That's not our problem.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 01 Dec 2003 22:38:45 +0200

> not to, well, fine. That's not our problem.

Ok. I think we agree now.

In terms of what to do about it: Bernard and Henrik have added
some words to the 2284bis document to describe the (general)
issue related to fraudulent claims of authenticators. They have
also added a requirement that method specs should say whether
or not they offer some protection for this. Can you take a look
if you like the text:
http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20200

(Solution space: my gut feeling is that this is bigger than
individual methods or network selection, and needs to be handled
in a general fashion. Without doing an EAPv2 design, the best we
can probably do is to design an extension to popular methods,
with common parameter formats and AAA attribute definitions.)

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 01 Dec 2003 14:03:40 -0800

I am not sure what is agreed on. :)

The particular attack Michael mentioned seems to hold even when Gamma
AP advertises "gamma" instead of "delta".  In that case:

- Two authentication signaling paths are valid, i.e., 

  one is:     

  supplicant           <-> gamma AP <-> AAA proxy <-> gamma's AAA server
  (= gamma's customer)

  the other is:    

  supplicant           <-> delta AP <-> AAA proxy <-> delta's AAA server
  (= gamma AP 
   = delta's customer)

- SSIDs advertised by APs are valid.
  (i.e., gamma AP advertises "gamma", delta AP advertises "delta".)

- The data traffic path is still "valid", i.e., 

  supplicant           <-> gamma AP       <-> delta AP <-> Internet
  (= gamma's customer)     (= NAT router)

It seems that actually no entity is doing anything wrong.

Just that the Gamma Coffeeshop is smart enough to leverage the
existing acocounting and billing schemes to increase its revenue.

If the above observation is correct, I don't see any problem with this
in terms of security.

Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Tue, 02 Dec 2003 00:09:38 +0200

> - Two authentication signaling paths are valid, i.e., 

Yes.

>   (i.e., gamma AP advertises "gamma", delta AP advertises "delta".)

Yes. But see below.

> - The data traffic path is still "valid", i.e., 

Yes.

> existing acocounting and billing schemes to increase its revenue.

Right.

> If the above observation is correct, I don't see any problem with this

Michael started from a case where Gamma was advertising "Delta"
instead. He argued that the protocols should be able to prevent
such lies. I agreed.

The rest is up to the user.

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 01 Dec 2003 14:23:30 -0800

> instead. He argued that the protocols should be able to prevent

I agree that the lying NAS problem is a security issue in general.  But
what I'd like to mention is that the Gamma/Delta coffeshop example might
not be an appropriate example for explaining the lyning NAS problem.

Yoshihiro Ohba