2.3.19 Protocol for carrying Authentication for Network Access (pana)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional PANA Web Page

Last Modified: 2005-01-25


Basavaraj Patil <basavaraj.patil@nokia.com>
Alper Yegin <alper.yegin@samsung.com>

Internet Area Director(s):

Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Thomas Narten <narten@us.ibm.com>

Mailing Lists:

General Discussion: pana@ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/pana
In Body: (un)subscribe
Archive: http://www.ietf.org/mail-archive/web/pana/index.html

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
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.

Network access authentication enables the client to be authorized for
packet data service. However it is possible that the underlying link
itself is insecure, i.e the packets being sent to and received on the
link between the client (PaC) and the 1st hop access router (EP) in the
network are not protected by any physical or cryptographic
means. In such cases, PANA will enable the establishment of an IPsec
SA between the client and the 1st hop access router to secure the
packets on the link. In networks that have physical security or
ciphering as a link-layer feature, no such SA is required. Hence the
establishment of the IPsec SA is optional. The WG will deliver a
document that explains how such an IPsec SA is established by using
IKE after successful PANA authentication. No enhancements to either
IKE or IPsec are expected.

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. SNMP will be used
by the PAA to deliver the authorization information to one or
more EPs when the PAA is separated from EPs. The WG will document
the solution based on SNMP for carrying the authorization information
between the PAA and the EP.

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)

- A document that describes how SNMP is used to deliver authorization
information from the PAA to the EP in the scenarios where the PAA
and EP are separated.

- A document that explains the establishment of an IPsec SA between
the client and the 1st hop access router subsequent to
authentication for securing the data packets on the link.

Goals and Milestones:

Done  Submit usage scenarios and applicability statement to the IESG
Done  Submit security threat analysis to the IESG
Done  Submit protocol requirements to the IESG
Aug 04  Submit PANA framework to the IESG
Aug 04  Submit PANA protocol specification to the IESG
Aug 04  Submit IPsec-based access control to the IESG
Aug 04  Submit SNMP-based PAA-to-EP protocol specification to the IESG
Dec 04  Submit MIB for PANA to the IESG


  • draft-ietf-pana-requirements-09.txt
  • draft-ietf-pana-threats-eval-07.txt
  • draft-ietf-pana-pana-07.txt
  • draft-ietf-pana-ipsec-05.txt
  • draft-ietf-pana-snmp-03.txt
  • draft-ietf-pana-framework-03.txt
  • draft-ietf-pana-mobopts-00.txt

    No Request For Comments

    Current Meeting Report

    Protocol for carrying Authentication for Network Access (PANA)
    WG meeting minutes from IETF62
    Wednesday, March 8th; 0900-1130

    Basavaraj Patil <basavaraj.patil@nokia.com>
    Alper Yegin <alper.yegin@samsung.com>

    Basavaraj (Raj) Patil presenting:

    Blue sheets.

    Document status update.
    - Yoshi has been diligent in keeping the document updated.
    - Threats and requirements in the RFC editors queue.
    - PAA-EP document has been reviewed by the MIB doctor

    - Jari Arkko will be the technical advisor to the PANA WG.


    2. Multihop PANA
    Alper Yegin presenting:

    URL: http://panasec.org/docs/IETF62/mhop-PANA.txt

    - Discussion carried out on the mailing list.
    - Objective of this discussion is to remove the criteria that limits the PAA and PaC being a single hop away from each other.
    - Currently the charter says that the PAA and PaC are on the same subnet
    - Benefits include the fact that the NAS can be beyond the 1st hop and other deployment models
    - Unless this change makes the protocol extremely complicated, it is worthwhile removing the 1 hop limitation.
    - Clarified the scope of multi-hop PANA as opposed to multi-hop EAP BoF that was held earlier.

    Presented the various issues that have been discussed on the mailing list. (See slides)
    Issue 1: PAA Discovery
    PAA discovery can be easily handled and no changes are needed to the current protocol spec.

    Jyunghoon Jee: If PaC can be preconfigured with the PAA's prefix, then you could possibly use anycast to discover the PAA? Does this make sense? If it knows the network prefix in advance, it could use the anycast mechanism.
    Alper: Agrees that it makes sense to do such a discovery.

    Issue 2: IP Addressing
    No changes to the base spec expected to address this problem.

    Issue 3: EP Location
    PAA must know the location of the EP.

    Raj: Do you have a problenm when there are multiple EPs as a result of moving the PAA higher up in the network?
    Alper: This can be done using the current PAA-EP solution. Hence it is not a limiting factor.
    Raj: Is it possible that different filters be pushed to different EPs? The PAA will have to know the EPs.
    Alper: The EPs are preconfigured and yes it is possible that different EPs receive different filters.

    Subir: The EP and PAA cannot be colocated in the scenario?
    Alper: The PAA and EP cannot be colocated when you have the multi-hop scenario. Because the EP has to be on the same subnet.

    Issue 4: NAT traversal
    Decision on mailing list was to get rid of the integrity checks associated with the IP address.
    2 Issues: Port number and IP address integrity check. Two possibilities to address this problem. We can try to make PANA NAT friendly. If there are major challenges to doing this, we can go with Option 2 which simply says that PANA has a limitation of being used in the presence of NATs.

    Subir: Can the NAT be colocated with the EP/AR?
    Alper: Yes.
    Subir: Do all the same arguments that you made apply?
    Alper: Yes

    Yoshi: Agrees that it makes sense to remove the integrity check verification.

    James Kempf: If you move the PAA from the subnet, what is the difference between the PAA and AAA? The PAA is a functional architectural element.
    Alper: Agrees with James'comment.

    Alper: So the next step as a result of this discussion is that we will update the charter to remove the 1 hop limitation, fix the protocol spec and move on. Any objections to this?


    3. PANA PAA-EP Protocol: SNMP usage

    I-D: draft-ietf-pana-snmp-03.txt
    Yoshihiro Ohba presenting on behalf of Yacine.

    - Received feedback from MIB doctor.
    - Security section: Added several things based on review by the MIB doctor
    - Added PaC presence notification. Identified two ways: Reliable and unreliable.
    - Next steps
    1. Link layer protection - Better that it be described in a separate document since link layers have their own specific solutions.

    Alper: Is there a generic way to define encapsulation? Understand that there is a need for separate documents based on link layer.
    Yoshi: If we only have MAC address and generic identifier, then it is possible, but not sure if all link layers will be able to use such.
    Alper: What else do we need to push from PAA to EP? We would not define the format of the MAC address but a new TLV?
    Yoshi: We can consider.

    2. Current set of MIB objects is defined. If any additional objects are needed, please comment. Maybe one more rev of the ID is needed before WG LC.


    4. Context transfer for PANA
    I-D: draft-bournelle-pana-ctp-02.txt

    Julien Bournelle presenting:

    - Scope of presentation
    Problem statement: When PaC moves from one network to another and as a result changes PAAs, there is a need to transfer context from the previous PAA.

    - Example of use of CxTP between PAAs
    Explained the scenario and operation of CxTP in this scenario

    - Use of AAA in the context transfer process.

    Modified some aspects of CxTP as defined in this solution for PANA.

    Is there interest in making this a PANA WG item?

    Raj: CTP is an experimental RFC now. Is there really a need to define this protocol since it is a reuse of the existing RFC. Because the only change is the security token. It is basically an application of CTP to PANA.
    Julien: Agrees.

    Glen Zorn: AAA server identity. What does it mean?
    Julien: The new PAA needs to know what AAA server has been used.
    Glen: What does it mean? Does it mean the local AAA? Home AAA?
    Proxies? Which one?
    Julien: It is the AAA that has been used by the previous PAA.
    Glen: So that could be a proxy. So why do we care.

    Glen: So how does the PAA know. And why does it matter.
    Julien: Agrees.

    Jari Arkko: Slide showing the information transferred. Everything but the authorization rules. Says that it is probably more than the one that you show here. Wearing the EAP co-chair hat: Says that there is a need to
    Julien: Derivation of the key is described in the PANA-Mobopts document.
    Jari: Need to show that the mechanism conforms to the EAP WGs specification
    Alper: Understands that the EAP WG will simplify the keying framework document. Does it imply that other WGs can make modifications?
    Jari: There is still some need for control. But each WG will still need to specify how it is done for a protocol.

    James Kempf: Says that security people have this view of cryptographic boundaries. Of course this boundary definition is quite nebulous. However it seems that transferring keys between boundaries may be a cause of concern. If key transfer is what you are interested in, I wonder if context transfer is the right way to do it.
    Glen: Cryptographic boundary is where we define it. The crypto people like to keep this boundary quite small. Preferably on a chip.

    Glen Zorn: Session lifetime question. There is more to authorization than filters as Jari mentioned.

    Raj: So should we make this a WG document. Consensus call to the WG:

    1. How many people think that this document should be a PANA WG document?

    Thomas: Should this work be taken up the context transfer at all? Given that there was only one hand

    Rephrasing the question.

    There were about 8 hands in favor of and a couple of hands that were against this. We will take this up on the mailing list.

    Thomas: Are you chartered to take on such work? You may want to verify this before going forward on this.
    Raj: Agrees


    5. PANA state machine
    I-D: draft-ohba-pana-statemachine-01.txt

    Presented by: Victor Fajardo

    - Reviewed by a couple of people.
    - Several changes have been made to the FSM.

    - Miscellaneous fixes as well that were caught by the reviewers.
    - Editoroal fixes.
    Next step:
    Prefer to get some more reviews from the WG and from people who are implementing this protocol. Additionally make this a WG document.

    Raj: The state machine used to be a part of the PANA protocol spec. Hence it should be fine to go ahead and make this a WG document and publish it as an Informational RFC.


    6. PANA-RADIUS interworking
    I-D: draft-lior-pana-radius-00.txt

    Avi Lior

    - Document describes how you map PANA messages and AVPs to RADIUS.
    - Architecture description
    - The EP is considered to be colocated within the scope of this discussion.
    - PANAs discovery phase has no equivalent in RADIUS.
    - Access Phase in PANA maps to Accounting in RADIUS
    - Reauth in PANA is Auth in Radius.
    - In the case of multiple authentication, you may use one or more RADIUS servers. There are issues here with this model and it needs to be sorted out.

    - Should have a similar document like this for Diameter. It could also be in this document itself as well.
    - Request making this a WG document.

    Jyungoon Jee: PANA already assumes a backend AAA. Why do we need this specification?
    Avi: This document is purely informational. There are issues in mapping. Hence such a document will help the community. RFC3580 talks about how to interwork RADIUS with 802.1x

    Alper: It is the interworking of these protocols that is explained in this document.
    Jee: If company X makes PANA and anothetr makes RADIUS, then there is a problem if such a thing is standardized.

    Jari: 1. Supports the idea of defining clearly how PANA and RADIUS and Diameter interwork with each other. If you do not do this vendors end up interpreting things differently and interoperability becomes an issue.
    2. Would make sense to have Diameter in the same document.
    3. Q: What to put in the NAS-type attribute?
    Avi: No clear answer at this time.

    Yoshi: Access-Reject mapping issue. If one EAP fails while another succeeds, what is the problem?
    Avi: When the Home AAA sends an Access-Reject, the session is gone. But that is not necessarily the same in PANA. Causes confusion to the home network since an Accounting start request is generated even when the Home sents an Access-Reject.

    Yoshi: The accounting start should be sent only to the Radius server that did not reject. Hence it should not be a problem.
    Avi: Did not read it that way. However there is a debate in AAA land about a similar issue and hence more discussion is needed.

    Glen Zorn: Not sure how all this would ever work. Does not believe there is any debate about what an Access-Reject means. The Radius client obeys what it is told. And hence what does it mean if you interpret Access-Reject in other ways?
    Avi: Explaining.

    Joe Salowey: It is important to straighten out this issue and several others as well if all this is to work together.
    Avi: Agrees

    Raj: Document is intended to be Informational. Should we make this a WG document?
    Q: How many people think that we need to have this document which specifies how PANA and AAA(Radius/Diameter) interact?

    How many people think that there is no reason to have such a document and should be left to implementers?
    1 hand

    Glen: Why does this ID need to be just Informational as opposed to being standards track. Because if it is just informational then we can just ignore it. But if it is important

    Raj: Basically the ID is providing guidelines. Most implementers also understand the interaction. Hence does not think that it makes sense to make it standards track. But can be deferred to the ADs for how to pursue this.

    Dave Nelson: Thinks that the interop document should be closely specified in order to get interoperable behavior. Hence it should be a standards track document.
    Glen Zorn: Ditto.

    Raj: Thomas, do you want to comment on this.
    Mark Townsley: Believes there is consensus to make it a standards track document.
    Thomas: The WG at some level should decide this.

    Raj: We will pursue this on a standards track.


    7. Next steps
    Basavaraj Patil presenting

    1. Make the PANA-Radius interactions a WG document
    2. Revise the milestones
    3. Agreement to remove the limitation of the single hop. Recharter and make the modifications to the WG documents that are affected. The ones that are affected are framework and pana protocol spec. One these changes are done, we will submit the documents to the IESG. The PANA-IPsec ID is not affected by this change. But since the framework, PANA protocol and PANA-IPsec docs go hand in hand, they will be submitted to the IESG in a batch.
    4. Another rev of PANA-SNMP document needed before going to WG LC.

    Glen: What is the rationale for multi-hop PANA?
    Alper: No reason why the PAA must be on the same subnet. On the ML people have expressed interest in moving the PAA to a different location. Having the PAA
    Thomas: Do you have concerns with doing this? As long as there is no harm to doing so, there is not a problem? But if you have concerns then we should discuss.
    Glen: Not sure if there are issues. Security or otherwise.

    End of meeting.


    Multi-hop PANA
    SNMP for the PAA-EP protocol
    Use of CxTP for PANA
    State Machine for PANA