eap Mailing List: Re: network discovery & selection: problem definition

[Yoshihiro Ohba (yohba]

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



On Mon, Dec 01, 2003 at 10:38:45PM +0200, Jari Arkko wrote:
> Michael Richardson wrote:
> 
> >    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.
> 
> 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
> 
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap