Subject: Re: PANA FAQ

From: Jacques Caron <[email-masked]>
Date: Mon, 01 Jul 2002 10:39:51 +0200

Hi,

At 21:08 28/06/2002, Yoshihiro Ohba wrote:
>I don't think 802.1x make sense in that case.
>
>If you have an 802.11a/b AP in your home through which you access to
>the DSL, then you may want to apply 802.11i packet encryption with
>dynamically generated per-packet encryption key (instead of using weak
>WEP with static encryption key) to protect your network from
>eavesdropping by hackers outside your home, which would require 802.1X
>for dynamic key distribution in your Wireless LAN, probably based on
>SSN pre-shared key mode.  On the other hand, you also have to perform
>network access authentication to access to the DSL, however, you
>cannot use 802.1X between your PC and the Ethernet bridge in the DSL
>provider's network unless you put a router in between, since you
>already used 802.1X between your PC and AP.  Instead of this, you can
>simply use multi-level authentication in which 802.1x is used between
>your PC and AP and PANA is used between your PC and access router in
>the DSL provider's network.

Well, 802.1X is a link authentication protocol, so it should be the AP or 
router authenticating to the DSL provider. Which makes sense if you 
consider that there will probably be more than one device connecting via 
the AP, don't you think?

>It is not always true that single authentication is desired.  Whether
>to use multi-level authentication or single authentication is a matter
>of an administrative boundary issue.  If administrative regions are
>hierachically defined, multi-level authentication is pretty much
>natural.

Which 802.1X can do without a problem since it allows for authentication on 
any link...

Jacques.

-- Jacques Caron, IP Sector Technologies
    Join the discussion on public WLAN open global roaming:
    http://lists.ipsector.com/listinfo/openroaming

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 1 Jul 2002 16:27:42 -0400

Hi,

> consider that there will probably be more than one device connecting via 

If there is also wired user devices through a home Ethernet hub behind
the AP as well as wireless user devices, AP would not be an adequate
place to put 802.1X for authenticating to the DSL provider.  Do I need
an 802.1X-enabled router or Ethernet hub?  Moreover, does it work with
my currently installed DSL modem which probably is also an Ethernet
bridge without 802.1X support?  

Yoshihiro Ohba

---

From: Jacques Caron <[email-masked]>
Date: Mon, 01 Jul 2002 22:46:46 +0200

At 22:27 01/07/2002, Yoshihiro Ohba wrote:
>place to put 802.1X for authenticating to the DSL provider.

The router or switch then. Whatever is the first element before the DSL modem.

>   Do I need an 802.1X-enabled router or Ethernet hub?

You would need one, yes.

>   Moreover, does it work with

Yes. Probably not ideal for a number of reasons, but it does work: 802.1X 
is just a specific Ethertype (0x888E) which is bridged like any other. If 
the bridge is actually 802.1D compliant, you lose the 802.1X multicast 
address "feature" (so your 802.1X supplicant can't just send an EAP-Start 
to the multicast address), but it's quite easy for the authenticator to see 
some traffic coming in and start EAP with the MAC address it just learned.

Actually, I do that in another setup where I authenticate to my gateway 
using 802.1X even though I have a totally 802.1X-agnostic AP in between. 
Works like a charm (even though in this specific case I lose the dynamic 
keying, of course).

Jacques.

---

From: John Schnizlein <[email-masked]>
Date: Mon, 01 Jul 2002 16:57:20 -0400

Yes, in the ideal envisioned for standard controlled network access, 
you should use 802.1X authentication for both wired and wireless
host connections. You probably know as well as (better than?) the
rest of us that a currently installed DSL access device probably
lacks this. We probably agree that PPP over Ethernet, bridged to
an ATM virtual circuit, is not the best technical solution.

But, do you think converging on the already defined and deployed
802.1X access control will happen sooner or later than something about
which we are still discussing its justification? Along that line of
thinking, would this useful convergence happen more quickly if the
alternative were no longer under discussion? 

John

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 1 Jul 2002 18:05:47 -0400

Hi,

> an ATM virtual circuit, is not the best technical solution.

Yes, I agree on that PPPoE is not the best technical solution.

> alternative were no longer under discussion? 

I'm sorry, for this part, no.  Even Jacques has not provided me a
satisfactory 802.1X usage for DSL when legacy and 802.1X-capabile 802
devices are mixed in the same LAN (the proprietary method suggested by
Jacques is more than what is described in 802.1X specification and
seems to be problematic).  Do you believe every 802 device including a
cheap 4-port Ethernet hub is 802.1X-enabled in a near future?

Yoshihiro Ohba

---

From: John Schnizlein <[email-masked]>
Date: Mon, 01 Jul 2002 18:17:19 -0400

Thank you for the engaging discussion. More below:

At 06:05 PM 7/1/2002, Yoshihiro Ohba wrote:
>...

No, I expect to see 802.1X widespread only in switches (bridges, 
including wireless access points), not in bit-repeating hubs.
I do expect 802.1X to be much more widely deployed than PANA.
That is the relevant comparison, isn't it?

I also expect EAP over <any new layer-2 technology> will be widely
deployed. It takes so little for any new layer-2 to define a packet
type for the purpose of network access authentication now that the
IEEE demonstrated retrofitting this onto 802.3 (Ethernet), the most 
popular of the 802 family, and its rapidly growing 802.11 family.

John

---

From: Jacques Caron <[email-masked]>
Date: Tue, 02 Jul 2002 00:18:32 +0200

At 00:05 02/07/2002, Yoshihiro Ohba wrote:
>seems to be problematic).

Problematic? Not in this scenario, and afaik it is not proprietary, just a 
pretty direct application of the spec, considering the DSL modem/bridge to 
be transparent...

>   Do you believe every 802 device including a

1. Most such devices support PPPoE today. Adding 802.1X is quite trivial, 
especially on the supplicant side. The only "hard" part is the 
extensibility support (for multiple EAP methods), but the same issue would 
arise with PANA, obviously.
2. Do you believe every 802 device including a cheap 4-port Ethernet hub 
will be PANA-enabled in a near future?

Obviously, you don't want each of your PCs to PANA-authenticate to your DSL 
provider, do you? This would be quite fun, wouldn't it? And if as a DSL 
provider that was your goal, then it's up to you to provide the switch/AP 
that authenticates each of the devices connected to it (using 802.1X, of 
course)...

Jacques.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 1 Jul 2002 18:48:00 -0400

> some traffic coming in and start EAP with the MAC address it just learned.

I think this usage is beyond what is described in 802.1X.  I can imagine 
the following problems with your scheme.

o  The 802.1X Supplicant may not send or forward any packet other than 
   sending EAPOL EAP-Start message before receiving a PPPOL 
   EAP-Request/Identity message, both messages are to be discarded at 
   the intermediate 802.1D bridge.  So the 802.1X Authenticator will 
   not receive any incoming traffic to pick up the source MAC address.

o  Given that the above problem is fixed somehow, the 802.1X Authenticator 
   may have to unicast a EAP-Request/Identity message to each MAC 
   address it has seen in the source MAC address field in the 
   incoming traffic.  If 802.1X is enabled on multiple 802 devices at
   the user side due to, e.g, mis-configuration, then multiple 802.1X
   sessions could occur on the single port and this would cause problems 
   if the Authenticator is expecting a single Supplicant on that port.

> Works like a charm (even though in this specific case I lose the dynamic 

AP products without a dynamic keying capability will not survive in
the future.  So I believe this is mentioned just as an example for
802.1X through a legacy 802 bridge (but not satisfactory due to the
issues mentioned above).

Yoshihiro Ohba

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Mon, 1 Jul 2002 15:47:30 -0700

----- Original Message ----- 
> alternative were no longer under discussion? 

You mean PPP :) ? Current alternative to building 802.1x into
every access link is PPP. So, if we didn't discuss PANA, would
it help people move from PPP to native EAP transport even
faster? I don't think so.. Instead, they'll stay with PPP and its
consequences... After all, if native EAP transport over the link-layer
is the best and most practical solution, nothing should be slowing
people from doing it. Neither the existence of PPP nor these PANA
discussions.

alper

> >bridge without 802.1X support?  

**********************Confidentiality Note**********************
Privileged/Confidential Information may be contained in this e-mail and any
attachment to it and may be covered by existing non-disclosure or
confidentiality agreements.
If you are not the addressee (or authorized to receive for the addressee),
you may not use, copy or disclose to anyone any information contained in
this e-mail.  If you have received this e-mail in error, please notify the
sender immediately by reply e-mail and delete it from your system.
Thank you very much.
*************************************************************

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 1 Jul 2002 19:35:49 -0400

> pretty direct application of the spec, considering the DSL modem/bridge to 

Direct application of the spec?  Section 8.4.6 of 802.1X spec only suggests 
timeout-based scheme in which a Supplicant can assume that it is authorized 
to access the bridged LAN if it does not receive a response for EAP-Start.
Or am I missing something?

> arise with PANA, obviously.

Not the same, because PANA does not necessary assume to run over a LAN
segment, it does not matter whether a legacy 802 device exists between
a PaC and PAA.  PANA does not even assume that underlying L2 is IEEE
802.

> will be PANA-enabled in a near future?

No, please see above.

> provider, do you? 

That depends on the usage.  If there is only one PC, I can use PaC on
my PC.  Or for a DSL provider that allows roaming between my home and
coffee shop through DSL with my DSL account, PaC on my PC makes sense.

Yoshihiro Ohba

> This would be quite fun, wouldn't it? And if as a DSL

---

From: Jacques Caron <[email-masked]>
Date: Tue, 02 Jul 2002 19:25:01 +0200

>people from doing it. Neither the existence of PPP nor these PANA

For one, I believe many people are just not really aware that:
- 802.1X exists
- 802.1X works in wired as well as wireless environments
- 802.1X is simple

Also, in environments where you need 802.1X to talk to clients such as PCs 
or PDAs, access to raw Ethernet frames is indeed not as simple as sending 
or receiving UDP packets. So people get a bit lazy and try to come up with 
simpler "solutions"...

And finally, PPP is not necessarily bad. It's a quite good protocol for 
normal point to point links, and PPPoA for instance (or even "simpler" 
solutions, like PPP over HDLC) is totally fine. The only bad thing is to 
use it over Ethernet...

Jacques.

---

From: Jacques Caron <[email-masked]>
Date: Tue, 02 Jul 2002 19:11:19 +0200

>Or am I missing something?

You missed all of section 6 (which says that the port enabling/disabling 
only happens on the authenticator side), and the paragraph of 8.4.6 right 
after the one you mention:

"As the concept of the controlled and uncontrolled Ports applies only to 
systems that support Authenticator
functionality, a system that only supports Supplicant functionality can 
attempt to transmit data frames prior
to completion of the authentication process. Hence, in the example above, 
there is no necessity for the Supplicant
system to wait for the end of the authentication timeout period before 
initiating data exchanges via
the Bridge Port."

Given this, most 802.1X clients will start doing whatever they usually do 
on startup, i.e. most probably a DHCP request (as noted in the spec). This 
can then be used to trigger initiation of the 802.1X exchange by the 
authenticator.

>a PaC and PAA.  PANA does not even assume that underlying L2 is IEEE

"the same" applied to implementing the EAP method extensibility. This is 
totally independent from the encapsulation...

>coffee shop through DSL with my DSL account, PaC on my PC makes sense.

802.1X and roaming between your "home network" and the coffee shop makes 
more sense. Unless, as I said somewhere else, your DSL provider sells you 
multiple (wired or wireless) ports and asks you to authenticate on each 
(they would of course operate the DSL modem, bridge, AP, whatever in this 
case).

Jacques.

---

From: Jacques Caron <[email-masked]>
Date: Tue, 02 Jul 2002 19:19:17 +0200

>    not receive any incoming traffic to pick up the source MAC address.

The 802.1X supplicant may send or receive any packets it wants. It's the 
authenticator who will drop it.

>    if the Authenticator is expecting a single Supplicant on that port.

Definitely, 802.1X is not quite designed for multiple supplicants on the 
same port. But you're out of the scenario we were discussing, and it's 
really a very simple issue to fix...

>802.1X through a legacy 802 bridge (but not satisfactory due to the

It is indeed just an example, which I believe applies quite well in a wired 
environment (I totally recognize that not being able to do dynamic keying 
on WLANs is just a no-no).

Jacques.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 2 Jul 2002 14:49:59 -0400

> can then be used to trigger initiation of the 802.1X exchange by the 

I'm sorry, I don't believe the word "usually do" or "most probably"
when we talk about interoperability.  Are there any explicit
description in 802.1X specification that guarantees real
interoperability to work with legacy 802 devices?  If it provides
"real" interoperability then why the spec has to mention timeout-based
scheme?

> totally independent from the encapsulation...

OK.  Anyway there is no need for PANA to implement EAP on cheap
Ethernet switches.

> (they would of course operate the DSL modem, bridge, AP, whatever in this 

Then my question comes again, what happens when I use 802.1X between 
my PC and AP in my home just for dynamic key distribution?  Then it 
will lead to 802.1X's interoperability issue with legacy devices.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 2 Jul 2002 15:12:24 -0400

> authenticator who will drop it.

How can I believe "may"? :)

> really a very simple issue to fix...

I don't think it is a simple issue to fix.  There is also a security
issue as well as mis-configuration.  An attacker that shares the same
port can simply send EAPOL-Logoff to terminate the session.  The
attack from wireless attackers can be protected by using per-packet
integrity check provided by 802.11i, but how about wired attackers?

> on WLANs is just a no-no).

It would be my pleasure to be able to find an agreeable point :)

Yoshihiro Ohba

---

From: Jacques Caron <[email-masked]>
Date: Tue, 02 Jul 2002 21:23:57 +0200

>"real" interoperability then why the spec has to mention timeout-based

The section you quoted involves having a 802.1X-aware supplicant facing a 
non-802.1X-aware authenticator (or actually, non-authenticator!). In this 
case, indeed, there is no way for a supplicant to discover that the 
switch/AP/whatever it's connected to doesn't do 802.1X (at all) other than 
by timing out. That doesn't prevent it from starting it's usual chores 
(DHCP, etc.) in the meantime.

The case we're discussing (doing 802.1X across a non-802.1X bridge) is 
different. Indeed, it relies on the supplicant starting its activity before 
authentication can take place, and indeed there is no guarantee that this 
happens, but there is nothing that prevents it either (the supplicant can 
send all the frames it wants even though it's not authorized yet). I guess 
that if such a scenario were really needed (the obvious solution is rather 
to make the DSL modem/bridge be 802.1X-aware), it might need some 
clarification.

>OK.  Anyway there is no need for PANA to implement EAP on cheap

Uh? And why is that?

>will lead to 802.1X's interoperability issue with legacy devices.

I don't quite see the issue here? Which legacy device?

Jacques.

---

From: Jacques Caron <[email-masked]>
Date: Tue, 02 Jul 2002 21:28:15 +0200

>How can I believe "may"? :)

It's may in the "nothing in the spec prevents it from doing it" sense...

>integrity check provided by 802.11i, but how about wired attackers?

Obviously, 802.1X takes for granted that you have either physical security 
(for wired networks) or some kind of encryption (for wireless networks). 
Definitely, if you invite a hacker in your home, and let him connect to a 
hub you have between your DSL modem and your PC, anything can happen. But I 
don't believe anything can be done against that, and I would be in his 
place I would just cut the wire, it's definitely faster and more efficient...

Jacques.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 2 Jul 2002 16:00:55 -0400

> (DHCP, etc.) in the meantime.

It would be problematic in terms of interoperability if anything other
than 802.1X is neccesary for 802.1X messages to pass through
non-802.1X-aware device.

> to make the DSL modem/bridge be 802.1X-aware), it might need some 

I believe that such a scenario is really needed as well as the obvious
solution.

> >OK.  Anyway there is no need for PANA to implement EAP on cheap

I mean that PANA would not need anything other than PANA 
for PANA messages to pass through non-PANA-aware device.

> I don't quite see the issue here? Which legacy device?

Legacy device here is non-802.1X-aware 802 devices.
For the issue here, please reread this thread carefully.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 2 Jul 2002 16:07:35 -0400

> It's may in the "nothing in the spec prevents it from doing it" sense...

But that does not guarantee interoperability I have been mentioning.

> place I would just cut the wire, it's definitely faster and more 

Yes, anything can be done by you. :)

Yoshihiro Ohba

---

From: Jacques Caron <[email-masked]>
Date: Tue, 02 Jul 2002 22:59:03 +0200

>than 802.1X is neccesary for 802.1X messages to pass through

802.1X messages are not supposed to go through other devices. 802.1X is 
done between two devices at each end of a point-to-point link. Other cases 
like the one we mentioned earlier are really just hacks. It works, but it's 
not needed.

>I believe that such a scenario is really needed as well as the obvious

I think there are only two valid solutions: make the bridge 802.1X-capable 
(both as an authenticator and as a supplicant, so both links are 
authenticated: the one between your network and the bridge, and the one 
between the bridge and the DSL provider), or make it transmit 802.1X even 
with the multicast address. This would be considered "proxy 802.1X" :-) The 
latter change is so trivial it's not even funny.

>for PANA messages to pass through non-PANA-aware device.

Yes, but then the authentication does not occur between the same 
endpoints... In the 802.1X case we were talking about you authenticating to 
your AP, and your AP/switch/routeur/whatever authenticating to the DSL 
provider. In the PANA case apparently you authenticate directly to your DSL 
provider.

>For the issue here, please reread this thread carefully.

OK, let's try again.

   +--+
   |YO|    +--+    +--+    +---+    +-----+
   +--+<-->|AP|<-->|SW|<-->|DSL|<-->|DSLAM|
  /  /     +--+    +--+    +---+    +-----+
+--+                ^
                     |
+--+                |
|PC|<---------------+
+--+

+-------+ +------+
|YO's AS| |ISP AS|
+-------+ +------+

YO is your laptop. PC is your PC.
Who owns/manages AP, SW, DSL (modem/bridge/router)?
What is SW (just a switch, or a router doing NAT maybe, or...)?
What is DSL (a modem/bridge or a modem/router)?
Who wants/needs to authenticate who, using which authentication servers 
(yours: YO's AS, or the DSL providers: ISP AS)?

You can have several scenarios...

Jacques.

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Tue, 2 Jul 2002 13:58:53 -0700

> - 802.1X works in wired as well as wireless environments

OK. But not discussing PANA isn't going to help this change.
Actually, PANA discussions DO help in advertising 802.1x :)

> or receiving UDP packets. So people get a bit lazy and try to come up with

This is only reasonable.

> solutions, like PPP over HDLC) is totally fine. The only bad thing is to

Other people seem to mind using PPP over non-Ethernet links as well.

alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 2 Jul 2002 17:29:02 -0400

On Tue, Jul 02, 2002 at 10:59:03PM +0200, Jacques Caron wrote:
> 802.1X messages are not supposed to go through other devices. 

OK, this one sentence is enough to conclude that 802.1X does 
not work in an interoperable manner if there is a non-802.1X-aware 
device in between.  I don't think we should continue this discussion 
in this WG any further.

Thanks for the clarification,

Yoshihiro Ohba

> 802.1X is