Protocol Carrying Authentication for Network Access WG (pana)

Thursday, December 13 at 1530-1730
===================================

CHAIRS:	Basavaraj Patil (Basavaraj.Patil@nokia.com)
       	Subir Das  (subir @research.Telcordia.com)


AGENDA:

Agenda bashing  & WG                 Subir Das/Basavaraj Patil                  15  Mins
Milestones Discussion


Usage Scenario                       Yoshihiro Ohba                             30 Mins
Draft


A Smart-Card-based scenario          Jari T. Malinen                            10 Mins
over PANA framework


Discussion on                        Subir Das/Basavaraj patil                  30 Mins
Requirements/
Framework Drafts


Router Discovery: A candidate        Alper Yegin                                10 Mins 
over PANA framework


General Discussions/
All                                                                             25 Mins
Next steps



Charter:


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 and/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 is called Authentication Agent in this charter.
 - The device to discover the IP address of the AA.
 - The AA 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 AA 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 AA and any access control functions in  the network
and how their location affects the performance and scalability of the AA solution,
as well as the tradeoffs in the level of access control enforcement. (in framework
draft)
 - The relationship between the PANA  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  would just be to define how to carry EAP (RFC 2284)
messages in an IP based protocol. However, EAP makes certain  bassumptions 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 re-authenticated.


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 AA. 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 AA. 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 AA, can
be an important element in allowing efficient handling of mobile devices.


PANA needs reliability and congestion control, taking into account that the
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 be independent of IP address configuration.


Milestones:
========


 Nov 01  WG chartered


 Nov 01  First draft of Usage Scenarios I-D (Informational)


 Feb 02  First draft of Requirements and Terminology I-D (Informational)


 Mar 02  Usage Scenarios sent to the IESG.


 May 02  First draft of Framework Specification based on scenarios I-D (PS)


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


 July 02  Requirements and Terminology sent to the IESG.


 July 02  First draft of Protocol Specification I-D (PS)


 Aug 02  Framework document sent to the IESG.


 Oct 02   PANA interactions with PPP and 802.1X to IESG.


 Dec 02  Protocol Specification to IESG


 Dec 02 First draft of MIB Definition (PS)


 Mar 03  MIB Definition to IESG.