Subject: Problem Statement and Scope of WG

From: <[email-masked]>
Date: Wed, 3 Apr 2002 18:39:45 -0600

Hello,

At IETF53, there were some questions about the scope of PANA and the
problem that this WG was aiming to solve. Below is a brief description
of the problem statement and also the scope of what we hope to do in
this WG. If WG members think that this problem statement is clear
enough we could modify the charter and make it more lucid.

-Chairs

                PANA Problem Statement and Scope
                --------------------------------

Hosts need to provide credentials and authentication information
before being allowed access to networks that require access 
authentication. This is a function that is normally performed at the
link-layer by protocols such as PPP, PPPoE, 802.1x and protocols that 
are specific to cellular technologies (e.g.: GSM, CDMA, TDMA, etc.). 

Network authentication has two aspects:

 - Access authentication and authorization: 
   To verify legitimacy of the clients before they gain access to the
   network. The goal of PANA is to enable this function.

 - Per-packet authentication/encryption: 
   To provide data integrity and confidentiality, and to prevent
   service theft after clients gain access to the network. PANA
   can also enable per-packet authentication/encryption.

While the former is a must, the latter is optional but in many cases 
required.

EAP (Extensible Authentication Protocol) is a widely used protocol for 
network access authentication. It provides a framework that allows the 
use of multiple authentication mechanisms, and defines how it is 
encapsulated in PPP frames. EAP over Wireless (EAPOW) and EAP over
LAN (EAPOL) of 802.1x are defined to carry EAP on IEEE 802 type links. 
And for any other link type that does not define its own encapsulation, 
PPP/PPPoE is used to carry EAP protocol. While EAP encapsulation 
capability of PPP/PPPoE is useful, the other functionalities of these 
protocols are not always needed but cannot be turned off either. 
Therefore using PPP/PPPoE as a media agnostic encapsulation for EAP 
creates sub-optimal solutions (extra round-trips, overhead of 
encapsulation and processing, forced topology into point-to-point), 
whereas this functionality can be easily provided by a simple 
protocol explicitly defined for this purpose.

So to state it very simply:
The goal of the PANA Working Group is to define a link-layer 
agnostic encapsulation for EAP. It will define a network-layer messaging 
protocol that enables access authentication and authorization. 

The general framework of all access control mechanisms is shown in the 
following figure.

                 Authentication Agent------------Authentication Server
                          |
Client-------------Enforcement Point

PANA does not change this model. The functional elements and framework 
used are identical to existing encapsulations (e.g.: EAPOW, PPP). PANA is 
used to encapsulate EAP between the Client and the Authentication Agent, 
whereas EAP is still encapsulated using protocols like Diameter or Radius 
between the Authentication Agent and the Authentication Server. 

The Authentication Agent can reside on any node in the network that can 
send/receive IP datagrams (i.e., has an IP stack). The Authentication 
Agent and the Enforcement Point can be co-located (as is the case with 
PPP and EAPOW), or be on separate nodes. PANA will identify a transport
(e.g., AAA, SNMP, COPS, etc.) to carry access control information 
(such as filters) from the Authentication Agent to the Enforcement point 
when these two entities are separated.
There are pros and cons associated with having the authentication
agent beyond the first hop [NAS/AP/Rtr/etc.]. This is an issue that
needs to be delved into by the WG.

Where to use PANA
-----------------

PANA can be used in networks that do not have mechanisms at the 
link-layer to authenticate hosts. Even when the link-layer provides
access authentication, PANA can still be used as an EAP-enabler or to
provide additional network-layer authentication (when required).

Currently only IEEE 802 type links have a native encapsulation for EAP. 
None of the other link-types define how to carry EAP although they might have 
their own protocols for access authentication and authorization. Even 
when the link-layers have their own protocols, using EAP provides a 
standard, flexible, and extensible tool for authentication. This is 
where PANA will be used to provide the link-layer agnostic encapsulation
for EAP. By using PANA, individual link-layers don't have to define 
their own speciic encapsulations to take advantage of EAP. 

PANA is even much more needed for link-layers that support 
neither access nor per-packet authentication. It can be used as the 
only means to provide access authentication. Per-packet authentication/
encryption can be achieved by the use of IPsec or other ciphering
mechanisms.

Per-packet authentication/encryption
------------------------------------

A number of EAP methods have key derivation and distribution 
capabilities. PANA does not change the model how these keys are 
generated or used. But as a network-layer transport, it provides the 
flexibility to use these keys either at the link-layer or at the 
network-layer.

If the link-layer supports data authentication/encryption, then the 
keys may be provided to the link-layers of the Client and the 
Enforcement Point, so that traffic can be protected as provided by the 
link-layer. 

If the link-layer does not support link-layer authentication/
encryption, but per-packet protection is still required by the 
upper-layers, then the keys may be used by IPsec between the Client and 
the Enforcement Point to protect the traffic as required.

---

From: "James Kempf" <[email-masked]>
Date: Thu, 4 Apr 2002 08:37:41 -0800

Raj & Alper,

I think it would  be helpful to explicitly list nongoals of PANA. For
example, I assume that one nongoal is to replace existing link layer
authentication mechanisms for network access authentication.

>   can also enable per-packet authentication/encryption.

The implication I get from this goal is that PANA is proposing to
replace the IPsec gateway mode, whereas, what I think you are really
talking about is an alternative key distribution mechanism for session
keys. That is, I get the impression that PANA will do the actual
encryption/authentication. I think you need to be much clearer about
this.

> encryption can be achieved by the use of IPsec or other ciphering

I would suggest:

    An even stronger case can be made for PANA for link layers that
    support neither access nor per-packet authentication. PANA can
    be used with such link layers as the exclusive means to provide
    access authentication.
.

            jak

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 11 Apr 2002 18:12:09 -0700

> needs to be delved into by the WG.

PANA provides the flexibility that the Authentication Agent and the
Enforcement Point can be co-located or separate. Co-location is the
model that is already used with the existing link-layer authentication
protocols.
Separation looks like a good feature, yet it requires using another
transport between two.

In order to better understand the value of separation, we need to look at
some
usage scenarios. Can people think of such scenarios?

Comments please..

alper

---

From: "James Kempf" <[email-masked]>
Date: Fri, 12 Apr 2002 17:38:25 -0700

I question the value of separation, since it will require a separate
protocol to transmit the enforcement decisions between the enforcement
point and the authentication agent. I have, as yet, not seen a
compelling need for complicating the traditional NAS architecture in
this manner.

            jak