Subject: RE: PANA FAQ

From: Jacques Caron <[email-masked]>
Date: Thu, 27 Jun 2002 23:46:57 +0200

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

> >Providing L3 addresses and L3 connectivity are two different things. You
> >can provide the former without the latter.
>
>And what would be the benefit of not providing even limited L3
>connectivity?

Enable PANA to work? :-))) I guess we would have to define exactly what "L3 
connectivity" means, but since I think it's totally irrelevant, let's not 
venture in that space...

> >But I doubt anyone would give L2
> >connectivity if they don't want to give L3 connectivity and they can use L2
> >authentication. For what purposes?
>
>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. 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). 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)?

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

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

>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. 
Forget about PPPoE. 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
b) you have to implement PPP anyway for GPRS and co.
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?

So, what are the other reasons again?

Naughty-Jacques :-)

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 28 Jun 2002 06:43:31 -0700 (PDT)

Hello,

--- Jacques Caron <[email-masked]> wrote:
> laziness to develop 802.1X clients for most
> platforms. 

well it's my turn to disagree...

the http hijacking (a.k.a captive portal) was
developed because of one the same reasons PANA exists:
having a access agnostic authentication method.

It wasn't developed for 802.11, but for networks where
there was no session indication (cable, ethernet, ADSL
with pure RFC1483) or hybrid carriers that provided
two types of access services and people wanted one
authentication method.

People use it in 802.11 networks not because of
laziness but because in hot spots you cannot assume
anything about the users laptop/mobile/whatever,
except that he has a browser. 

regards,

Reinaldo

But, yes, there are 
> So, what are the other reasons again?

__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

---

From: James Carlson <[email-masked]>
Date: Fri, 28 Jun 2002 10:17:51 -0400

Reinaldo Penno writes:
> It wasn't developed for 802.11,

Note that the text above references 802.1x, an authentication
mechanism that works on all 802 media, rather than just 802.11
wireless in particular.

> but for networks where

Even after this or any other hacks are used, there's still no real
"session" there.  Broadcast-type media generally allow those on a
given segment to spoof identity of another on the same segment.  The
only points where it makes sense to me to enforce some sort of
'session' identification are:

	1. the peers on a point-to-point connection with some form of
           physical security, or

	2. the end nodes involved in a particular conversation, where
           there's some form of cryptographic security.

(1) corresponds to point-to-point L2 authentication, while (2)
corresponds to end-to-end IPsec or application level security.

I don't understand how I plug a device into a network and somehow have
a router behind one or more bridges determine *precisely* who I am,
and exclude all others.  For instance, what happens if a user on a
different bridge within the same subnetwork spoofs my source MAC
address?

> except that he has a browser. 

Agreed, but that certainly looks like more of a deployment issue than
a protocol issue.

In other words, if folks aren't deploying and using 802.1x in the
cases where it would work, and are instead relying on awful HTTP
hacks, then what real chance is there that any new protocol (which is,
as yet, less deployed than 802.1x) will improve the situation?

-- 
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: Reinaldo Penno <[email-masked]>
Date: Fri, 28 Jun 2002 08:25:27 -0700 (PDT)

Hello James,

--- James Carlson <[email-masked]>
wrote:
> "session" there.  

well, you can find out when the user logged in, out,
radius accouting type data, etc.

The issues you bring up are valid, but they are
security related. Each method needs to deal/cope with
its own security risks, complexity trade-offs.I was
making the point that with captive portal you can have
access agnostic authentication. 

Broadcast-type media generally
> allow those on a

Because now it will not be *just* for 802.1x based but
more any access method that is IP based.