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.