Current Meeting Report
Jabber Logs

2.3.11 Protocol for carrying Authentication for Network Access (pana)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 05/20/2002

Basavaraj Patil <>
Alper Yegin <>
Internet Area Director(s):
Thomas Narten <>
Erik Nordmark <>
Internet Area Advisor:
Erik Nordmark <>
Mailing Lists:
General Discussion:
To Subscribe:
In Body: (un)subscribe
Description of Working Group:
In some scenarios, an IP-based device is required to authenticate itself to the network prior to being authorized to use it. This authentication usually requires a protocol that can support various authentication methods, dynamic service provider selection, and roaming clients. In the absence of such an authentication protocol on most of the link-layers, architectures have resorted to filling the gap by using a number of inadequate methods. For example, inserting an additional layer between link-layer and network-layer mostly for client authentication purpose (e.g., PPPoE), overloading another network-layer protocol to achieve this goal (e.g., Mobile IPv4 with Registration- required flag), and even defining application-layer ad-hoc authentication mechanisms (e.g., http redirects with web-based login). In these and other cases, a network-layer authentication protocol may provide a cleaner solution to the authentication problem.

The goal of PANA is to define a protocol that allows clients to authenticate themselves to the access network using IP protocols. Such a protocol would allow a client to interact with a site's back-end AAA infrastructure to gain access without needing to understand the particular AAA infrastructure protocols that are in use at the site. It would also allow such interactions to take place without a link-layer specific mechanism. PANA would be applicable to both multi-access and point-to-point links. It would provide support for various authentication methods, dynamic service provider selection, and roaming clients.

Mobile IPv4 developed its own protocols for performing PANA-like functions (e.g., MN-FA interaction). Mobile IPv6 does not have the equivalent of a Foreign Agent (FA) that would allow the access/visited network to authenticate the MN before allowing access. The PANA authentication agent (PAA) can perform the authentication function attributed to the FA in Mobile IPv4, in Mobile IPv6 networks.

The WG will work with the assumption that a PANA client (PaC) is already configured with an IP address before using PANA. This IP address will provide limited reachability to the PaC until it is authenticated with the PAA. Upon successful authentication, PaC is granted broader network access possibly by either a new IP address assignment, or by enforcement points changing filtering rules for the same IP address.

PANA will neither define any new authentication protocol nor define key distribution, key agreement or key derivation protocols. It is believed that PANA will be able to meet its goals if it is able to carry EAP payloads. Note, however, that EAP may need to be extended in order for PANA to meet the need for all of its intended usages. Such extensions are outside the scope of the PANA WG.

PANA will develop an IP-based protocol that allows a device to authenticate itself with the network (and to a PAA in particular) in order to be granted network access. For simplicity, it is assumed that the PAA is attached to the same link as the device (i.e., no intermediary IP routers). The PAA itself may interface with other AAA backend infrastructures for authenticating and authorizing the service being requested by the host, but such interactions are transparent to the PaC.

The PAA does not necessarily act as an enforcement point (EP) to prevent unauthorized access or usage of the network. When a PaC succesfully authenticates itself to the PAA, EP(s) (e.g., access routers) will need to be suitably notified. This WG will identify a (preferably existing) protocol solution that allows the PAA to deliver the authorization information to one or more EPs when the PAA is separated from EPs. A single PAA may serve many access routers. The WG will also propose a solution of how the PaC discovers the IP address of PAA for sending the authentication request.

The PANA WG will deliver

- A mechanism for the PAC to discover the PAA on the link.

- The PANA protocol itself, capable of carrying multiple authentication methods (e.g. using EAP)

- Select or define a protocol to carry authorization information between the PAA and the EPs.

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
  • - draft-ietf-pana-usage-scenarios-02.txt
  • - draft-ietf-pana-requirements-02.txt
  • No Request For Comments

    Current Meeting Report

    Protocol for Carrying Authentication for Network Access (PANA) WG
    Monday, November 18 at 1300-1500
    Chairs:	Basavaraj Patil, Alper Yegin
    Note Takers: Ernie Tacsik, Subir Das
    1. Agenda Bashing, 5 Mins
    No comments made
    2. Charter Update and WG document status, 10 Mins, Chairs
    Report by chair (Basavaraj Patil):
    Only change to charter after Yokohama - added PAA and enforcement point 
    separation, and updated the milestones. Charter is available at ietf web 
    page. Three WG documents are available at this moment, and they will be 
    informational. Security threat analysis is a new wg document.
    3. Requirements draft update, 10 Mins, Reinaldo Penno.
    short presentation covering updates to the requirements draft.
    PAA-EP protocol requirements
    - Security
    - Protocol used between PAA and EP should be able to detect inactive peer 
    within an appropiate time period and delete the related states.
    - Architecture needs to allow PaC and PAA initiated 
    - Have a mechanism for a newly introduced EP to learn the policies 
    currently in effect on that access network.
    - PAA should be able to notify an EP for 
    allowing/disallowing access for a particular client. This should happen 
    without EP sending a request to the PAA.
    changes in requirements draft
    - pana models
    - discovery
    Michael Thomas: are we dealing with policy discovery here? 
    Chair (Basavaraj Patil):  no - PANA only addresses discovery of PAA.
    4. Security issues and Threat analysis, 40 Mins, Mohan 
    The draft does not talk about solution, specific protocols. List may not be 
    complete. Only general threats are discussed, for example: PAA 
    discovery, authentication, leaving the network, attack the network etc.
    Discussion on requirement PANA MUST protect the identity of the PaC 
    against eavesdropping
    Michael Thomas: risk reward benefit  expose identity  consider that you may 
    NOT want to expose identity of PAA in discovery  client may need to know (or 
    guess) the PAA.
    Hannes Tschofenig: questions requirement of must protect identity - this 
    requirement seems to favour certain solutions.
    Comment: if you have layer 2 protection  then this is not a problem.
    Michael Thomas: to protect identity you must do something like 
    Michael Thomas: identity protection is costly.
    Hannes Tschofenig: agreed.
    Chair (Basavaraj Patil): questions if diffie-hellman is appropriate does 
    access network need to know id of client? or only need to 
    Michael Thomas: suggested real requirement is to provide ability to 
    protect client privacy, not a "MUST protect" requirement. 
    Jarno Rajahalme: suggested real requirement is to protect user privacy.
    Unknown1: Whom do you want to protect the identity or what type of 
    threats are analyzed?
    Unknown2: may be location privacy..
    Hesham Soliman: base requirements should be on the general case, we 
    should have one set of requirements, not multiple depending on the 
    various deployment environments.
    Michael Thomas: DoS is an issue of we want id confidentiality.
    Discussion on leaving the network 
    Unknown: Is it realistic to think about disconnection.. things may 
    crash.. wire may be disconnected... 
    Chair (Alper Yegin): It is not mandatory but if one sends it should be 
    Attack on normal communication - requirement: PANA in combination with the 
    underlying authentication protocol (e.g. EAP) MUST be able to derive keys in 
    order to enable confidentiality.
    Michael Thomas: how do you use keys? will it be solved in PANA?
    Discussion on the extent of protection
    Unknown: how are packets protected  smacks of reinventing ipsec? 
    Answer: No implication that data is secure.
    Erik Nordmark: PANA protocol must be secure itself, questions if this is 
    just last-hop local protection? 
    Mohan Parthasarathy: yes, for the local protection.
    Unknown: I think PANA should take care by itself but here we see a 
    different things. Not clear to me whether the last hop protection is 
    Hannes Tschofenig: I think it is necessary to know whether it is about 
    exchanging EAP messages securely, or something else. Whether the focus of 
    PANA is to put the filters at the first hop router .
    Chair (Basavaraj Patil): Charter does not talk about securing data at the 
    first hop networks it talks about securing PANA itself.
    Unknown: We should put a requirement that EP and PAA are secured..
    Hesham Soliman: suggested must be able to derive keys in order to enable 
    confidentiality and per-packet authentication."
    Gopal Dommety:  is draft suggesting doing encryption EAP to PaC  should 
    this be mandated?  other issues with keys.
    Michael Thomas: is PANA a layer 3 PPP or is it a AAA key 
    distribution system  need explicit use sceanarios.
    Chair (Basavaraj Patil): the intended threat to address is to protect 
    against someone injecting packets into network using a previously 
    authenticated users IP address.
    Erik Nordmark: confidentiality on the identity is not needed.
    George Tsirtsis: (on PANA requirement of having an IP address) we can use 
    unspecified IP addresses.
    Hesham Soliman: is this an issue for IPv6?
    Erik Nordmark: there is a tradeoff, between having and not having having IP 
    address there already - there are pros and cons.
    George Tsirtsis: what if one meets all requirements without using an IP 
    address configured on the PaC? 
    Gopal Dommety: a solution that works Without an IP address would be good.
    5. Secure Network Access Authentication (SeNAA), 20 Mins, Dan Forsberg
    Discussion on  running TLS over UDP:
    Hannes Tschofenig: How are you deriving the SA for IPsec? If it is 
    authetication only, then why you care about confidentiality. Also if you use 
    only EAP then EAP should provide you the confidentiality.
    Michael Thomas: running TLS over UDP loses many TCP benefits (such as 
    fragmentation, support for long certificates)
    Hannes Tschofenig: TLS needs PKI, or else MitM attacks is an issue.
    Chair (Basavaraj Patil): do we need to protect DI of PAA?
    6. PANA over TLS, 20 Mins, Yoshihiro Ohba
    Design policy
    Start from providing maximum level of security
    Basic features
    Authentication parameters including EAP
    PDUs are carried over TLS
    TLS runs over reliable transport
    Unknown: You mentioned that you would like to support some EAP methods but if 
    I move and want to support the legacy authentication methods. may be we 
    should consider some other mechanisms to protect those legacy 
    What about protecting the other hops.
    Yoshihiro Ohba: The current draft addresses the EAP protections over TLS but a 
    security discussion is necessary to address these issues.
    Hannes Tschofenig: on secure channel  terminate tunnel in home AAA not at 
    last hop  protection mechanism need to be all the way to the end  cannot 
    assume the access network is trustworthy. 
    Michael Thomas: huge overlap with IPSRA and IKE  per packet integrity on 
    data flows. Why all this effort to use TLS?
    Chair (Alper Yegin): we are open to discussing other solutions.
    Erik Nordmark: WG should not consider lot of other proposals. I 
    advocate to discuss the high level methods on the mailing list before 
    producing several drafts... 
    Chair (Basavaraj Patil): Let's explore the other methods and discuss in the 
    mailing list.
    Derek Atkins: notes there is work in progress on a draft to use 
    Kerberos over EAP.
    Clarification by chair (Alper Yegin):  there are no assumptions in PANA to 
    use TLS.
    6. Next steps: chair (Alper Yegin)
    - Wg last call on problem space and usage cenarios after ietf 55
    - Complete threat analysis draft and go to wg last call  jan03
    - Complete requirements draft and go to wg last call  end of jan03
    - Focus on options for protocol solutions on the mailing list


    Secure Network Access Authentication
    Next Steps
    PANA Requirements and Terminology
    PANA Threat Analysis and Security Requirements
    PANA over TLS