Subject: RE: PANA FAQ

From: <[email-masked]>
Date: Fri, 28 Jun 2002 15:41:22 -0500

Jacques,

>At 00:48 28/06/2002, [email-masked] wrote:
>>I am not completely convinced about the security argument for WLANs
>>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 :-/
>

True. But seriously if someone wants to launch DoS attacks, there is
not really much that 802.1x will be able to do to prevent it.

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

Okay, bringing in the concept of services and resources was a bad
idea. We have ruled this as being out of scope and I should have stuck
to that. The scope of PANA (as the name says :) ) is to provide
Network Access. So let me not even continue on this thread of services
and try to justify the need for PANA for authorizing access to
services. 

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

Nope :(
Sorry for the digression....

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

That is probably quite true. And discussing what future networks may
need is simply being speculative and non-productive to this WG.

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

Agreed.

>
>> >Forget about PPPoE.
>>
>>Would you agree that PANA would be a suitable candidate for networks
>>that rely on PPoE???
>
>802.1X is a better candidate :-)

Well, that would be like saying "if you have a hammer everything looks
like a nail"  
But I guess 802.1x is a possibility that cannot be ignored.

>>1. Newer L2 protocols that do not have inherent
>>authentication mechanisms.
>
>Just define an EAP encapsulation for those.

Could be done I s'pose.

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

What we are trying to achieve with PANA is basically to have a
mechanism that allows EAP to be carried over IP. 
Some networks that do not have PPP or 802.1x may find this useful for
authenticating users. In the presence of PPP and 802.1x, it is hard to
justify to operators deploying networks to use another protocol for
authenticating users for network access without showing the advantages
of doing so :( 

You do have some very valid points and I agree that it is time for us
to really think about where PANA would be applied. 

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

-Basavaraj