Subject: Updated WG Charter

From: <[email-masked]>
Date: Tue, 9 Jul 2002 15:58:09 -0500

A few updates based on comments from ADs included in the following
charter:

---------------------------------------------------------------

PANA

In some scenarios, an IP-based device is required to authenticate
itself to the network prior to being authorized to use it. Today, such
authentication typically occurs at L2, e.g., via IEEE 802.1X or PPP.
Prior to being authenticated, a node's access to the network is
typically limited. For example, a node may only be allowed to send
traffic necessary to invoke an authentication protocol (possibly
enforced by L2 mechanisms). Once a device has been authenticated, it
would be granted broader access to the network (e.g., possibly
connectivity to the public Internet).

There are some scenarios where no L2 authentication is used. For
example, in some scenarios, IP connectivity is granted to anyone, but
only within a local scope (e.g., within a hotel or airport).  Broader
access is granted only after authentication. Because there is
currently no generic access protocol that allows a device to
authenticate itself to the network at layer 3 (i.e., at or above IP),
ad-hoc schemes are employed. For example, one (simplistic) approach is
to intercept all Web traffic and display a web page with instructions
for how to gain access.

The goal of PANA is to define a protocol that allows clients to
authenticate themselves to the access network using IP protocols. Such
a protocol would allow a client to interact with a site's back-end AAA
infrastructure to gain access without needing to understand the
particular AAA infrastructure protocols that are in use at the
site. It would also allow such interactions to take place without an
L2-specific mechanism.

Note that although PPP can provide the above functionality, PPP is
deemed an inadequate solution for a number of reasons.  Using PPP just
for client authentication requires extra round-trips, includes
overhead of PPP processing (for data packets), and forces the network
topology into a point-to-point model. For some wireless networks, the
point-to-point model is particularly inappropriate.

PANA will develop an IP-based protocol that allows a device to
authenticate itself with the network (and to a PANA Authentication
Agent (PAA) in particular) in order to be granted network access. For
simplicity, it is assumed that the PAA is attached to the same link as
the device (i.e., no intermediary IP routers). The PAA itself may
interface with other AAA backend infrastructures for authenticating
and authorizing the service being requested by the host, but such
interactions are transparent to the client.

The PAA does not act as an enforcement point to prevent unauthorized
usage of the network. When a client succesfully authenticates itself
to the PAA, enforcement points will need to be suitably notified. 
The details of how this takes place are outside of the scope of this
WG. The PAA and the enforcement point are colocated and the 
communication between the PAA and the EP are considered to be internal
or implementation dependent.

Mobile IPv4 developed its own protocols for performing PANA-like
functions (e.g., MN-FA interaction). Mobile IPv6 does not have the
equivalent of a Foreign Agent (FA) that would allow the access/visited
network to authenticate the MN before allowing access. The PAA can
perform the authentication function attributed to the FA in Mobile IPv4,
in Mobile IPv6 networks.

It is assumed that a client is already configured with an IP address
before using PANA. This IP address will provide limited reachability
to the client until it is authenticated with the PAA. Upon successful
authentication, client is granted broader network access possibly by
either a new IP address assignment, or by enforcement points changing
filtering rules for the same IP address.

PANA will not define any new authentication protocol nor does it
define key distribution, key agreement or key derivation protocols.
It is believed that PANA will be able to meet its goals if it is able
to carry EAP payloads. Note, however, that EAP may need to be extended
in order for PANA to meet the need for all of its intendend
usages. Such extensions are outside the scope of the PANA WG.

Deliverables of the WG:

AUG 02 Usage Scenarios and applicability statement
SEP 02 Requirements of PANA
NOV 02 Interaction of PANA with 802.1x and PPP
FEB 03 Protocol Specification
JUN 03 MIB for PANA Protocol