Subject: 52nd IETF - Protocol Carrying Authentication for Network Access BOF (pana)

From: [email-masked]
Date: Wed, 28 Nov 2001 11:36:46 -0500

Protocol Carrying Authentication for Network Access BOF (pana)

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

CHAIRS: Basavaraj Patil ([email-masked])
        Subir Das  (subir @research.Telcordia.com)

AGENDA:

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

Usage Scenario/Yoshihiro Ohba                   30 Mins
Draft

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

Draft-yegin-unap-snard/Alper Yegin              15 Mins

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.