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.