Current Meeting Report

2.2.11 Protocol for carrying Authentication for Network Access (pana)

NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date. Last Modified: 03-Mar-02
Basavaraj Patil <>
Alper Yegin <>
Internet Area Director(s):
Thomas Narten <>
Erik Nordmark <>
Internet Area Advisor:
Erik Nordmark <>
Mailing Lists:
To Subscribe:
In Body: (un)subscribe
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:
Dec 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
No Request For Comments

Current Meeting Report

PANA Working Group Meeting Minutes IETF53
(Monday, March 18 at 1300-1500)

1a. WG Scope and Charter Clarification, (By Basavaraj Patil)

Alper Yegin is now new co-chair of PANA WG.

Two WG docs are identified so far

a. Requirements and terminology draft. The design team is working on this draft from the beginning of January. The current timeline for this draft is

- Version 0 by the end of January
- Version 1 will be out based on the mailing list discussion
- Working group last call will be after IETF-53 meeting

b. Usage scenario draft

- Revision 1 is under discussion
- Need couple of issues to be resolved before working group last call

1b. General Charter Clarification Discussion

It seems like there may be some misunderstanding regarding the current goal of PANA WG. As per charter, this WG focuses on the layer2 agnostic mechanism for interacting end host with the authentication and authorization infrastructure. This is essential because a single mechanism is required that performs the authentication and authorization functions. This makes hosts simple to implement, deploy and inter-work. As per this charter PANA will define a network access protocol, which is independent of layer-2 and IP versions (IPv4 or IPv6) and support multiple authentication schemes.

Current mechanisms exist today are

- Use of PPP to carry authentication information
- PPPoE for authentication (note that PPPoE may not be just for authentication).
- Network specific network authentication mechanism (like GSM, CDMA, 802.1x etc.)
- Web/HTTP based mechanism (direct to web site)


Single mechanism for a host to do authorization and authentication over different access network technologies. PANA will define (select) existing protocols for network access that will have the following characteristics:

- L2 agnostic
- Identifying authentication/authorization using existing security mechanism

Moving forward

- Agreement on requirements
- Develop a framework (this should be small effort)
- Propose a protocol as a solution
- Implementations !!!


- There was some confusion among some members in this group regarding what sort of IP address may be used.
- IP connectivity and authentication may be viewed as chicken and egg issue (having authentication before obtaining IP address and getting IP address to perform authentication). If PANA is used, one might not need access layer specific authentication. Single mechanism may be used for any access network regardless it is 802.11, GSM or any other access network.

- Co-chair explained the goal of the charter saying that currently different access networks have different mechanism for authentication. This WG is trying to come up with the generic mechanism, which can be used by all these access networks.
- WG is assuming that this is layer3 mechanism, which is problematic since it will have all types of security attack problems at link layer.
- Further discussion was to have separation of layers functionalities. The group argued that current mechanisms are relying on link layer authentication. For example PPP performs authentication and IPCP rely on that. This brings up the issue of getting PANA adopted by existing access networks
- Pat C. : GSM, CDMA, WLAN are not going to change their authentication mechanism because of a new protocol that PANA will specify. We need authorization at L2.

Alper : Only network authentication at L3
Pat C. : Why separate them ?
George T: L2 authentication happens at access pt, not at the access router, PANA tries to solve this issue.

- Who wants this today ? What are the target environments?
- We don't do business case at IETF. It'll be needed when nodes are in GSM or WLAN.
- IEEE already exists, what is PANA buying here?
- Glen Z (Cisco): Authorize L2 with L3 ? May work for a few protocols, but not for all. Dynamic filtering ?

2. PANA Requirements (By Alper Yegin)


Goal: The current goal is set to define a carrier and at least one payload (in terms of authentication protocol) to meet the requirements of network access authentication.

2a). Authentication

The difference between the carrier and payload were clarified. It was mentioned that PANA must not define new security protocols or mechanisms. Instead PANA must be defined as a "carrier" for such protocols. PANA must identify which specific security protocol or mechanism it can carry in terms of payload.

More than one DI (Device Identifier) can be used by PaC and that may be associated with multiple IP addresses.


- This is not agnostic to layer-2. Here link type does matter. It was clarified that layer-2 information is used in the PANA protocol for authentication purpose. It could either be MAC address, IMSI or anything else. Getting IP address can be done by any means and may not rely on which layer link may be used.
- One DI for more than one IP address may be a kluge.
- DI can be exchanged through some secure way instead of exchanging in the clear-text.
- DI is part of protocol specification and may not be discussed as a part of requirements. Co-chair clarified that it should be part of the requirement to identify type if DI used.
- EAP in the requirements draft seems like the good idea. Mutual authentication, re-authentication, integrity protection are essential requirements. The draft should also assume protection against eavesdropping, spoofing and replay attacks.
- Information like what kind of DOS attack may be occurring etc. should be covered in this draft.
- It is also possible that if EAP is not available, then having secure channel is not guaranteed.

2b). Authorization:

In addition to carrying authentication information, PANA also carries a binary result (i.e., success or failure) of authorization for network access to the PaC.

- Should PANA be designed extensible for finer granularity authorization (ability to carry a chain of extensions) => like qos parameter exchanges etc.
- Should we have a requirement on extensibility?

As far as location of PAA concerns, there should not be any restriction on where the agent should be located. Similarly, this document should not make any assumptions on the protocols or mechanisms used for IP address configuration of the PaC.

EAP association may be limited and should be assumed the same through out the Mobile IP application duration. The question brought up was whether PANA works even before IP address configuration. Note that it is working assumption that PANA works after the IP address configuration. This may be a deployment issue but seems like no one in the group had issues against this. Also, it should be clarified in the requirements that User name and password may not be the only way to authorize the user.

Other requirements on security and DOS attacks were discussed. PANA must be robust. The line containing "robustness is no worse than TCP syn attack" will be removed from the draft.

More comments were taken at this point and commentors expressed concerns on the consistency of the requirement statements and goal of PANA.

More threat analysis to be done to define security requirements.
If PANA depends on EAP then the requirement draft needs to say that.
George T. commented that PANA does not assume EAP on PANA. Then a commentor expressed concern on using L2 over-L3. He was asked to send comments to the mailing list.

3. Usage Scenarios - draft-ietf-pana-usage-scenarios-01.txt (By Hesham Soliman)

Problem statement included reason of having common authentication technique. The current authentication process and access control mechanisms have dependency upon the type of network that a user is attaching to. As a result a need of having a flexible authentication, which is independent of underlying access technologies and access control mechanisms is identified.

Currently some access networks do not have in-built authentication support. PANA helps resolving the following situations:

- Local Re-authentication: There is also a need for local re-authentication between client and PAA. This re-authentication may be due to timing or parameter changes or detection of connectivity/reachability etc.
- IP address configuration and timing independence
- IP version independence (IPv4 and IPv6) since PANA is considered layer-3 protocol.
- Support of multiple access routers
- Solves NAS issues since the location of NAS determination is essential.

A scenario where handoff occurs between different technologies under same administrative domain is discussed. A client is associated with one access type so handoff is a big problem. It was mentioned that context transfer doesn’t help in this case. In the scenario like this, PANA provides single authentication and authorization infrastructure for operators.


- This is a political problem. If both technologies use different authentication scheme, it doesn’t make sense in using PANA in these types of scenarios.
- If user is authenticated with one access network then context transfer is done at the time of handoff. It is still essential that a user is authenticated by the new access network (where user is roaming).
- For the authentication purpose, it is necessary to have NAI type of link layer identifier.
- Details like location of PAA in the network should not be discussed while discussing scenarios in this document.
- Scenario discussed to explain multiple AR is useful but PANA’s role in solving the issue is not very clear.
- Pat C. asks if PAA could be on the edge. ANswer was it can be on both edge and non-edge.
Erik N. points out that this is a valid question in the given scenario.

4. PANA and EAP (George Tsirtsis)

EAP supports most current PANA requirements (directly or indirectly). Checks for each requirements mentioned in the PANA Requirements draft were presented. It was noted that currently Disconnect Indication and PAA discovery are not supported. Reliability and congestion control are also kind of supported.

Work to be done:

- Define EAP transport at the network layer
- Define Explicit DI transport
- Disconnect indication
- PAA discovery
- Local AAA and key distribution: must be coupled
- Reliability and congestion control

- SASL or TLS may be better candidates instead of EAP.
- L2 transport takes care of all these problems. Using EAP for L3 is almost like EAP over EAP.
- EAP BoF will discuss separating key part from the EAP.
- EAP assumes that back end is separate from the relay. This may not be the case with SASL.
- Whether EAP is the only payload PANA should be working on? It was clarified that EAP is a preferred payload and that is the assumption so far. This point will be further discussed on the mailing list. It seems overall, confusion is why layer-3 authentication is required which again rely on the layer2 information.

5. PANA Framework, (By Yoshihiro Ohba)

Different scenarios were discussed explaining how PAA interacts with other network entities and the factors involving the location of PAA. It was mentioned that it is possible to have PAA one hope away from the PAC. Also PAA is viewed separate from the access device. The issue again might be relating to the address assignment since the IP address is used for the authentication. The question raised was that what address should device use as global address.

Security factors identified so far are:

- Requirements for a need of LSA (Local Security Association) between a client and a server
- Key derivation
- PANA exchanges be integrity protected and encrypted
- EAP is one of the candidates based on the current security requirements.

The following are current assumptions on AAA infrastructure:

- Secure AAA infrastructure
- Information carried between AAAL-AAAH is viewed same as PAC-PAA
- PAA should able to pass info to another PAA if necessary. This will reduce server interactions
- AAA authentication information will be pushed down to the access device. This brings one more protocol to the table probably midcom, diameter or something similar.


- These are good requirements but it is essential to have well defined interoperability.

There was also a short discussion on PAA Discovery. The possible candidates are ICMP, DHCP or others.

The co-chair asked for the volunteers to work on the PANA framework draft. More discussion will take place on the mailing list.


PANA Framework
PANA Requirements and Terminology