Subject: RE: PANA FAQ

From: <[email-masked]>
Date: Thu, 27 Jun 2002 17:48:26 -0500

>
>At 23:25 27/06/2002, [email-masked] wrote:
>>Guess that was a poor example of PANA applicability.
>
>I'm still looking for the good ones ;->

Well, I will keep trying :) to convince a skeptic...

>>I agree. Current operators force users to authenticate at L2. But is
>>there any real benefit in the case of WLAN operators in authenticating
>>at L2 as opposed to authenticating at L3?
>
>Actually, most don't and use the horrible http-hijacking method (urk), 
>afaik, because when they started 802.1X wasn't there, and now there is some 
>laziness to develop 802.1X clients for most platforms. 

Thats true. The current model in most hotspots is based on
http-redirect or hijacking as you call it. But 802.1x is definitely
being built into hosts and APs. So it is only a matter of time.

>But, yes, there are 
>advantages for L2 authentication rather than L3 (mainly revolving around 
>security in the case of WLANs, and around other L2 user-dependent 
>parameters that one could wish to set, in general). 

I am not completely convinced about the security argument for WLANs
being better at L2 but I can go along with that for now.

>But the real question 
>is: is there any real benefit in authenticating at L3 (which requires a new 
>protocol) as opposed to L2 (where the protocols already exist)?

Well, you are only considering the applicability of PANA from an
access to network perspective and comparing it only to existing L2
mechanims. However, IMO, PANA can also be used to authenticate a user
for authorizing access to a service or a resource. So a device may
gain access to the network by authenticating at L2 (using .1x or PPP)
and subsequently use PANA for authenticating the user when a resource
or service is requested.

For networks that have well defined L2 mechanisms and are already
deployed, I agree that developing a new protocol to accomplish the
same task (in this case gain network access) is of no benefit. However
for newer L2s that are developed in the future should not have to be
forced into reinventing the wheel and develop yet another L2 protocol
or retrofit a protocol such as PPP for simply the minimal
functionality of authenticating users for network access. 

>
>>And if operators are worried about assigning IP addresses to hosts
>>before it is authenticated then hopefully IPv6 solves that problem.
>
>It's indeed one possible issue (one could mount a DoS attack on a WISP node 
>by depleting the DHCP pool). Indeed IPv6 will help, but I think most people 
>won't wait for the white knight to arrive in its shiny armour :-/
>

And that is why we are proposing that a node be allowed to use the
unspecified address in order to authenticate itself. 

>>If operators are worried about hosts attaching to APs at L2 and not
>>authenticating, I guess you could have mechanisms to drop
>>non-authenticated (performed at L3) L2 connections based on some
>>timers.
>
>Don't allow them to connect in the first place :-)

But even with 802.1x the host does associate itself with the AP for a
short duration of time, does'nt it? So what would be different from an
implication perspective?

>
>>And again to reiterate one of the reasons of why L3 based
>>authentication is useful:
>>If you have multi-interface devices (Ethernet, .11, GPRS, 1X), you
>>could use a common mechanism for authenticating the user instead of
>>having to do .1x when attached to WLAN and PPPoE when connected over
>>Ethernet and PPP when connected to GPRS or 1X.
>
>802.1X when attached to WLAN or Ethernet... It's the same thing,
>remember. 

Yes.

>Forget about PPPoE. 

Would you agree that PANA would be a suitable candidate for networks
that rely on PPoE???

>So that leaves 802.1X for 802 media and PPP for the 
>rest. Given that:
>a) the real authentication is in EAP which is common

Agreed.

>b) you have to implement PPP anyway for GPRS and co.

You do not have to implement PPP in GPRS. The only reason for doing so
would be to authenticate a user to his ISP. Since the host is
authenticated at L2 (for network access) using a GPRS specific
scheme, there is no real reason that PPP is required at all in GPRS.

>c) the rest of a 802.1X or PPP EAP client is really, er, trivial (if you 
>have the rest of the corresponding L2 stack, of course)
>then, what's the point?

For networks and hosts that have .1x and PPP already specified or
deployed, PANA would not be applicable for authenticating the user for
network access. However it can be used for authenticating access to
resources (as mentioned above).

>
>So, what are the other reasons again?

And among other reasons: 
1. Newer L2 protocols that do not have inherent
authentication mechanisms.

2. The availability of a solution for doing authentication at
a higher layer when it is not absolutely required that it be done
at L2. (Operators will eventually make the call of what mechanism
they will use, but at least the capability is there).

>Naughty-Jacques :-)
-Basavaraj

---

From: Jacques Caron <[email-masked]>
Date: Fri, 28 Jun 2002 01:14:40 +0200

>being better at L2 but I can go along with that for now.

Well, having L2 authentication allows you to set up per-user or per-session 
encryption. This allows protection from DHCP pool depletion DoS attacks, 
DoS and other types of attacks against other clients on the same AP, and a 
few other similar things. Not perfect, but still better than nothing :-/

>and subsequently use PANA for authenticating the user when a resource

What is a service or resource? Most of those I can think of already have 
their own authentication methods built-in. And if they are remote (e.g. a 
web server somewhere else on the Internet), then things like NAT or proxies 
prevent the use of independent IP connectivity: the authentication has to 
happen in the same connection as the service. If the service is local, then 
what prevents communication of L2 authentication information to that resource?

Also, just for kicks, I thought PANA was supposed to authenticate Network 
Access? Services and resources don't qualify for network access, do they?

>functionality of authenticating users for network access.

Well, once EAP will have been cleaned up, I think it'll just be a matter of 
defining an encapsulation. 802.1X is a bit longuish because the IEEE folks 
tried to make it a lot more precise than the original EAP spec was, by 
adding the state machines and all that. If all this is integrated in the 
base EAP spec (and the PPP encapsulation moved out to a separate document), 
then new implementations will probably take a couple of (useful) pages at 
most...

>short duration of time, does'nt it? So what would be different from an

Yep. But this already implemented in the PAE, no sense adding complication 
by doing it at L3 and then having to talk back to the L2 device to 
disconnect the user or something similar...

>Would you agree that PANA would be a suitable candidate for networks

802.1X is a better candidate :-)

>scheme, there is no real reason that PPP is required at all in GPRS.

So the problem here is that the "native" GPRS authentication does not 
support EAP? Why not try to fix that?

>authentication mechanisms.

Just define an EAP encapsulation for those.

>they will use, but at least the capability is there).

As described above, I don't think it would be that useful (or I haven't 
understood what a service or resource is). And I don't believe in the 
"let's define yet another protocol, maybe somebody will have a use for it". 
Either there is a specific scenario were it is needed, and it is an 
appropriate solution, or there isn't, and you're a constructing a protocol 
in a requirements void, which will make it at worst useless, at best 
ill-suited.

Long time I haven't read the scenarios draft, are there any real scenarios 
in there that actually need something new vaguely related to 
authentication/authorization by now?

Jacques.

---

From: James Carlson <[email-masked]>
Date: Fri, 28 Jun 2002 06:54:42 -0400

> 802.1X is a better candidate :-)

An even better candidate would be to run PPP over that naturally
point-to-point DSL bit-pipe, and get rid of the burden of PPP over
PPPoE over Ethernet over ATM.  HDLC is cheap and effective.

But I agree with you that if you're stuck with those awful Ethernet-
to-ATM bridge kludges, then 802.1x makes sense.

> Just define an EAP encapsulation for those.

Agreed!  L2 layers that are found to be missing authentication
mechanisms in markets that require them should be fixed.

-- 
James Carlson, Solaris Networking         <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 28 Jun 2002 15:08:25 -0400

> to-ATM bridge kludges, then 802.1x makes sense.

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.

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.

Yoshihiro Ohba

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 28 Jun 2002 15:34:15 -0700

> support EAP? Why not try to fix that?

Clearly wherever it's available, using 802.1x is a better choice than
using a L3 protocol like PANA. PANA is not meant to replace 
L2 authentication  protocols. 

But, is expecting and waiting for all access technologies to adapt EAP 
a realistic approach? It's easier said than done. Do we know if these 
people are already working on building EAP into their link-layers? 
Especially when they have the simple solution of using PPP.....

And as for using either PPP or a L3 approach like PANA for 
authentication, we have already identified deficiencies of 
using PPP for that purpose. That doesn't mean that as soon as
PANA is available everyone will drop PPP/PPPoE and switch
to PANA. This is not our expectation. But we received positive 
indication that a L3 solution would be preferred by some people.

alper