[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-announce
Subject:    WG ACTION: Protocol for carrying Authentication for Network Access (pana)
From:       The IESG <iesg-secretary () ietf ! org>
Date:       2001-11-30 19:39:40
[Download RAW message or body]


A new working group has been formed in the Internet Area of the IETF.
For additional information, contact the Area Directors
or the WG Chair.


Protocol for carrying Authentication for Network Access (pana)
---------------------------------------------------------
 

 Current Status: Active Working Group
 
 Chair(s):
     Basavaraj Patil <basavaraj.patil@nokia.com>
     Subir Das <subir@research.telcordia.com>
 
 Internet Area Director(s): 
     Thomas Narten  <narten@us.ibm.com>
     Erik Nordmark  <nordmark@eng.sun.com>
 
 Internet Area Advisor: 
     Erik Nordmark  <nordmark@eng.sun.com>
 
 Mailing Lists: 
     General Discussion:urp@research.telcordia.com
     To Subscribe:      urp-request@research.telcordia.com
         In Body:       (un)subscribe
     Archive:           ftp://ftp.research.telcordia.com/pub/Group.archive/urp/archive
 
Description of Working Group:
 
The AAA working group is specifying the Diameter protocol for
communication between servers i.e. where Radius is currently being
used. There is currently no general protocol to be used by a user's
device when wanting network access, and this WG will attempt to fill
that hole. That is, a protocol between a user's device and a device at
the network access point where the network access device might be a
client of the AAA infrastructure.

Currently the authentication mechanisms in PPP are being used for many
wired access scenarios as well as some wireless access, which requires
using PPP framing for the data packets. This is not viewed as the
optimal solution in the cases where framing protocols already exist.
Also, IEEE 802 is working on 802.1X which provides EAP authentication
limited to IEEE 802 link layers.

Network access technologies for wired and wireless media are evolving
rapidly. With the rapid growth in the number and type of devices and
terminals that support IP stacks and can access the Internet, users can
potentially use a single device having the capability of attaching via
different multiple access media and technologies to interface to the
network. The model for providing the users' information to the
network for authentication, authorization or accounting needs to be
the same and NOT be tied in to the underlying access type.

The intent of this WG is to develop a protocol but the working group
can't start doing that until the requirements document is done.

The working group's primary task is to define a protocol between
a user's device and a node in the network that allows:

 - A device (on behalf of a user) to authenticate to an agent
   in the local network. The agent might be non-local, but at the 
   boundary of some AAA-equivalent function. The agent is called PANA 
   Authentication Agent (PAA) in this charter.

 - The device to discover the IP address of the PAA.

 - The PAA to use either local mechanisms/knowledge, or the AAA
   infrastructure i.e. being a client of the AAA, to authenticate the 
   device.

 - Outside of the scope of the protocol, allows for the PAA to install
   access control mechanisms in the network, based on the results of
   the AAA protocol exchanges. This follows the model of current Radius 
   being able to provide filtering rules to NASes.

The working group will also provide documentation on

 - Requirements placed on the protocol (in requirements draft)

 - Chosen approach for handling the security issues and which existing
   security mechanisms that are chosen for the protocol. (in framework 
   draft)

 - What assumptions the protocol is making on the AAA infrastructure 
   e.g. in terms of security. (in framework draft)

 - The relative location of the PAA and any access control functions in
   the network and how their location affects the performance and 
   scalability of the PAA solution, as well as the tradeoffs in the 
   level of access control enforcement. (in framework draft)

 - The relationship between the PANA protocol and e.g. PPP and 802.1X
   in deployment where both might be viewed as useful.
   (in "interactions" draft)

A naive view of a PANA protocol would just be to define how to carry
EAP (RFC 2284) messages in an IP based protocol. However, EAP makes
certain assumptions about PPP like link-layers such as:

 - The link-layer is point-to-point i.e. a single NAS or Access Router
   is involved in the EAP exchange. For PANA there is a desire to be    
  
   able to support redundant ARs on multi-access link layers where 
   inbound and/or outbound packets might use more than one AR.

 - The link-layer providing a disconnect indication. PANA should not 
   make this assumption. The assumption affects both the ability to
   tell when the session has ended from an accounting perspective,
   and it affects the frequency at which the device needs to be
   reauthenticated.

A possible way to address the need for more frequent re-authentication
is to have the first authentication, using the AAA infrastructure
and the assumed shared secret between the device and its AAA home
domain, create a security association between the device and the PAA.
Then re-authentication can be done using this security association
without involving the AAA infrastructure. Note that this local security
association is between a pair of entities: the device and the PAA. It
is not intended to be viewed as some general security association
between the device and the operator of the access network. In fact,
such general security associations are outside the scope of PANA.

The WG will not directly work on solutions relating to mobility of
the device. However, it is noted that the ability to re-authenticate
locally with the PAA, can be an important element in allowing efficient
handling of mobile devices.

The PANA protocol needs reliability and congestion ontrol, taking into
account that the PANA protocol needs to be able to operate over
multiple router hops. The congestion control principles are documented
in RFC 2914.

The WG will not invent new security protocols and mechanism but instead
will use existing mechanisms. For example, already specified EAP
methods. In particular, the WG will not define authentication 
protocols, key distribution or key agreement protocols, or key 
derivation.

The protocol must support both IPv4 and IPv6, but given that the
MOBILEIP WG is building Mobile IPv4 specific solutions to this problem, 
the urgency for solutions are likely to be higher for IPv6. The
protocol must not assume a particular method of IP address 
configuration. In particular, it must not interfere with standard
techniques and protocols like IPv6 stateless address autoconfiguration
(including the temporary addresses specified RFC 3041) and DHCP.
This implies that it is desirable that the PANA protocol be independent
of IP address configuration.
 
 Goals and Milestones: 
 
   Nov 01       First draft of Usage Scenarios I-D (Informational)             

   Feb 02       Submit first draft of Requirements and terminology I-D 
                (Informational)                                                

   Mar 02       Usage Scenarios I-D sent to the IESG for consideration as an 
                Informational RFC.                                             

   Apr 02       Submit first draft of Framework specification based on 
                scenarios I-D (PS)                                             

   May 02       First draft on PANA interactions with PPP and 802.1X (INFO)    

   Jun 02       Requirements and terminology I-D sent to the IESG for 
                consideration as an Informational RFC.                         

   Jun 02       First draft of Protocol specification I-D (PS)                 

   Aug 02       Framework document sent to the IESG for consideration as 
                Proposed.                                                      

   Oct 02       PANA interactions with PPP and 802.1X to IESG                  

   Nov 02       Protocol specification to IESG                                 

   Dec 02       First draft of MIB definition (PS)                             

   Mar 03       Submit MIB Definition I-D to IESG for consideration as 
                Proposed.                                                      

   Mar 03       Close down or recharter                                        

[prev in list] [next in list] [prev in thread] [next in thread]