Subject: Authentication and its good friends Authorization and Accounting

From: Jacques Caron <[email-masked]>
Date: Fri, 08 Feb 2002 23:29:10 +0100

Hi all,

Let's just step back for a minute, will you?

Authentication is just not a goal by itself (or very rarely is?). 
Authentication is only a pre-requisite for authorization (in its simplest 
form "allow connection, yes/no?") and accounting.

Now, if we take the following diagram:

Client <---service---> Edge Device
    <----authentication-------------------------------> Home server
                            <-----authorization------->
                            <-----accounting---------->

Where:
- service is anything you want: physical L2 connection, virtual L2 
connection, L3 connectivity, application, whatever...
- edge device is the endpoint for this service (the thing that provides the 
service: NAS, AP, switch, tunnel endpoint, router, server, etc, depending 
on the service)

One sees that the big difference between authentication and its two good 
friends is that, obviously, the authentication information is exchanged 
between the client and home server (via the edge device), while its two 
good friends authorization and accounting are exchanged between the edge 
device and the home server.

Now, we know that all three AAA components can be carried over RADIUS or 
Diameter between the Edge Device and the Home Server, and that's very well 
like that, I guess we all agree.

Also, the contents and semantics of the authentication are fully specified 
by any EAP method, depending on the specific requirements of the home server.

So the only thing left is how to carry EAP between the client and the edge 
device, right? This could be EAP over PPP, 802.1x for 802 media, other 
forms of EAP encapsulation, or PANA (anybody have a hint of which other 
services they want authentication on do not fit in the PPP or 802 categories?).

Also, authorization, beyond the simplest "allow connection yes/no" feature, 
includes many other features. Protocols allowed, IP addresses, routes, 
compression, encryption, QoS, filters and many more are part of the 
authorization.

Some of these are clearly L2 features, and should thus be transmitted to 
the L2 device. Among those, some even need to be known by the L2 device 
before it can bring up L2 (I'm thinking compression and encryption here, 
for instance). This is not achievable with PANA.

Other L2 features that could be put in place after L2 is brought up 
(filters? QoS? -- note the security issues though for the filters, since it 
means an insecure "window" would exist) would need some PAA-to-L2-device 
protocol to communicate these elements [some might contend this protocol 
would be RADIUS or Diameter, that the PAA is merely a RADIUS or Diameter 
proxy, and then we fall back on the L2 device is the edge device as shown 
above, and PANA is a L2 EAP encapsulation].

Other features still are L3, put are needed quite early in L3, when L3 is 
being brought up, like IP addresses. However, PANA probably requires L3 to 
already be up and IP addresses to already have been assigned (otherwise 
it's just not L2-independent, right?). So this does not work either.

I think you're facing quite a challenge here. Certainly, PANA does not seem 
able to *replace* existing L2 authentication protocols. So in those cases, 
it might just be a duplicate. And for any L2 media that do not yet have an 
EAP encapsulation, PANA will face quite a number of challenges to achieve 
all desired functionality, while moving back the Edge Device limit in the 
diagram above to the L2 edge device, and creating the appropriate EAP 
encapsulation, might be oh so easy in comparison.

I submit (once again) that PANA can be seen as an interim or fallback 
method that would be easier to port and implement, but would be quite 
limited in terms of features.

Not that I want to say PANA should not exist (I see a definite need for 
some form of EAP over UDP encapsulation as an interim measure until 802.1x 
is widely deployed), but I don't think it can be up to the expectations 
many of you seem to be placing into it as the ultimate replacement for all 
other authentication methods.

Jacques.

-- Jacques Caron, PSINet Europe Innovative Services Group
    Phone: +41 32 967 54 18 - Mobile: +41 79 699 83 89
    Fax: +41 86 079 699 83 89

"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former." -- Albert Einstein

---

From: Jacques Caron <[email-masked]>
Date: Sat, 09 Feb 2002 00:21:58 +0100

Oops. If you have any replies to this message, please use my personal 
address (this one) rather than of the original mail (work address, totally 
unrelated).

Thanks,

Jacques.

At 23:29 08/02/2002, Jacques Caron wrote:
>- edge device is the endpoint for this service (the thing that provides 
>the service: NAS, AP, switch, tunnel endpoint, router, server, etc, 
>depending on the service)
>
>Also, authorization, beyond the simplest "allow connection yes/no" 
>feature, includes many other features. Protocols allowed, IP addresses, 
>routes, compression, encryption, QoS, filters and many more are part of 
>the authorization.
>
>(filters? QoS? -- note the security issues though for the filters, since 
>it means an insecure "window" would exist) would need some 
>PAA-to-L2-device protocol to communicate these elements [some might 
>contend this protocol would be RADIUS or Diameter, that the PAA is merely 
>a RADIUS or Diameter proxy, and then we fall back on the L2 device is the 
>edge device as shown above, and PANA is a L2 EAP encapsulation].
>
>I think you're facing quite a challenge here. Certainly, PANA does not 
>seem able to *replace* existing L2 authentication protocols. So in those 
>cases, it might just be a duplicate. And for any L2 media that do not yet 
>have an EAP encapsulation, PANA will face quite a number of challenges to 
>achieve all desired functionality, while moving back the Edge Device limit 
>in the diagram above to the L2 edge device, and creating the appropriate 
>EAP encapsulation, might be oh so easy in comparison.
>

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 12 Feb 2002 23:43:50 +0100 (CET)

Jacques,

You said:
> (I see a definite need for 
> is widely deployed)

How long time do you think it will take for 802.1x to be widely deployed?

How long time do you think it will take for this WG to agree on requirements
and a protocol and get those specifications clear and concince enough to
be considered as proposed standard RFCs?
From the time those RFCs exist how long time until products implement those
specifications will be widely deployed? 

Which one is likely to finish sooner?

  Erik