2.3.16 Protocol for carrying Authentication for Network Access (pana)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       http://www.toshiba.com/tari/pana/pana.htm -- Additional PANA Web Page
NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-07-01

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

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-usage-scenarios-06.txt
  • - draft-ietf-pana-requirements-08.txt
  • - draft-ietf-pana-threats-eval-06.txt
  • - draft-ietf-pana-pana-05.txt
  • - draft-ietf-pana-ipsec-03.txt
  • - draft-ietf-pana-snmp-01.txt
  • - draft-ietf-pana-framework-01.txt
  • No Request For Comments

    Current Meeting Report

    Protocol for Carrying Authentication for Network Access WG (pana)

    August 4th, Wednesday; 1300-1500

    Thanks to Subir Das and Mohan Parthasarathy for volunteering to take the meeting minutes.


    1. Preliminaries (bluesheets, minute takers, agenda bashing, document status) : 5 min, Chairs

    - Chairs mentioned that charter has been updated
    - Requirements and threats drafts are ready for last call
    - The usage scenarios I-D has been deprectaed. The scenarios are now included as an appendix in the Requirements I-D
    - Received Expert reviews for pana protocol, pana framework, pana Ipsec draft.
    - pana snmp needs more reviews.


    2. PANA protocol update and open issues: 30 min, Alper Yegin
    Discussion of recently closed and currently open issues on draft-ietf-pana-pana-05.txt. See "Change History" section of the draft for the list of issues closed in this revision. Additional issues may be discussed on the mailing list prior to the meeting.
    Detailed issue descriptions can be found at http://danforsberg.info:8080/pana-issues/

    Alper presented the update and issues, Expert reviews have been received. Several issues are resolved and some are still open
    Issues resolved:
    - Issue 71, Post-PANA address AVP
    Resolution: No config, DHCP, RFC2462 etc
    - Issue 72: Capability discovery is not accomplished
    Resolution: PSR now includes PPAC and protection Capability AVP
    - Issue 73: What type of DI will be used on DSL networks?
    Resolution: Locally significant identifiers are ok
    DI does not have to be carried in an AVP.

    Mohan: Is DI carried by the packet
    Alper: Yes, it can be carried by the packet

    - Issue 74: Using PRAR and PRAA for mobility feature. We can use PBR and PBA instead
    Resolution: Use PBR/PBA instead
    Yoshihiro: May be it is related to other issue. For mobility, we can change the DI
    Alper: There is no text that conflicts your assertion
    Mohan: Is it optional?
    Alper: you can use as is. However the question is interface switching
    - Issue 78: EAP pass-through

    - Issue 79: Should PANA support the case where EAP
    authentication succeeds?
    Resolution: PBR results codes: PANA_SUCCESS

    - Issue 85: If PRPA is replaced by POPA, PAA needs to be notified
    Resolution: PaC sends PANA-Update-Request with IP-address AVP

    Sidefix: PANA-reauth MUST include MAC AVP only when PANA SA is available

    - Issue 98: PANA answers may be lsot. PaC/PAA should be ready to respond to retransmitted requests
    Resolution: PANA-auth-req responses are driven by EAP
    May respond to duplicate PANA-termination-req
    Section 4.7 and 4.11 are duplicates

    - Issue 100: Due to retransmissions and window of acceptable seq. numbers, ISN_* on PAA and PaC may differ. ISNs are used in
    PANA-MAC_key computation
    Resolution: Carry nonce values in PSR and PSA
    Use nonce values instead of nonce

    - Issue 107: Current seq no scheme does not accommodate rexmited rseq PaC drops msg 3 because "y" was already acknowledges

    Issue 75, 76, 77, 80,83, 84,91,92,93,96,97,99,103 are mostly editorial and clarification. Excpet 97 which are still open for further inputs.

    Next steps: Fix the open issues, Publish.

    Lionel: Is there any plan to have the distinction of different errors.

    Alper: Currently we have some messages. But I don't know whether they distinguish it or not

    Raj: Do you want to change the state machine behaviour depending upon the error message

    Lionel: Something like that but not to change the state machine
    Alper: It is hard to specifiy it
    Raj: He has a valid point since client may take some other steps depending upon partial information
    Alper: If PaC receives failure, PaC is out of PANA and it is an architectural decision
    Ra: It seems that issue 79 does not resolve the complete scenario and may be we should look it again.

    Resolution: Relax the expected rseq window to allow rexmot of seq


    3. PANA framework update and open issues: 5 min, Yoshihiro Ohba
    Discussion of recently closed and currently open issues on

    - Issue: AP hopping was needed when PAA and AP(EP) are separated
    Resolution: Text for AP hopping was removed A single solution for both co-located and separated PAA-EP cases
    Misc fix: Added explicit text that IEEE802.11i 4-Way handshake by AP
    - Issue: Simplifying DSL section:
    CPE acting as router (Router mode)
    CPE acting as a NATPT
    Resolution: Two modes can be combined
    - Issue: Revising Introduction section
    Missing info on overview and other documents
    Resolution: Introduction section will be revised and other document references will be added

    Next step: WG last call?


    4. SNMP usage for PAA-2-EP interface: 5 min, Yacine El Mghazli
    Discussion of recently closed and currently open issues on

    Yacine: PANA Wg mandates SNMP for PAA-EP
    In last IETF this was accepted as WG item

    IPSec config MIP splitted into 3 separate modules:
    Reuse of existing IPSEc configuration MIBs IP level access control
    Rule/Filter/action policy structure MIB module
    ID-KEY_ID config
    IpSEc IKE config

    PANA-secific objects extends the SPD-MIB
    L2 filters
    L2 protection

    Changes in this draft:
    Terminology section updated
    PAA/EP separation context section
    Feedback on SNMPv3:
    -A MIB doctor to act as a technical advisor for the PANA WG?
    - Careful use of SNMP terminology

    Raj: Generally for new MIB, we use MIB doctor and that's the IETF practice
    Yacine: Yes I agree

    Security issue: New PaC notification could lead to DoS attacks on the PAA.

    Alper: With SNMPv3, PAA

    Attack not clear...

    Alper: Attack pretty common...might be a general

    Open issues:

    - link layer filters: Do we support everything ? 802, DSL, What more ?
    - L2 protection : Some additional objects needed ?

    Alper: No need for enumerate all link layers. Define generic container.

    Yacine: Use existing objects to configure EP. Some are lacking..

    Security: Details the use of snmpv3 security.
    Depends on MIB objects definition.


    5. PANA-IPsec I-D update and open issues: 5 min, Mohan Parthasarathy
    Discussion of recently closed and currently open issues on

    Mohan: Version 03 updates
    Clarification of Key-ID in IKE pre-shared key derivation for
    reauthentication case
    Address Config has been simplified
    - Pre-PANA address can be link local
    Double IPsc section has been removed
    Dual stack operation section has been added
    How is IKE pre-shared key derived ahen there are multriple
    authentication schemes
    Raj: Is the document ready for last call?
    Mohan: Yes I think so. But is there are expert review pending?


    6. PANA state machine: 20 min, Victor Fajardo
    New I-D presentation for draft-ohba-pana-statemachine-00.txt.

    Victor: This is included in PANA base protocol documents
    Important in implementation
    - gives PANA internal details
    - insights of PANA
    PaC State Diagram overview has been presented. The intention is to show the difference with the previous presentation. The main differences is the introduction of EAP Interaction states. More details are available on the web site. In PAA state diagram the main difference are EAP interaction and result indication states. Also included issue 7 and 8.
    Details retransmissions descriptions are also available.
    Next Steps: Want to get the feedback from other implementers, verification of state machine Accommodate EP interface
    Raj: This document is a result from the protocol document. Because of the details, we decided to put it in a separate document and next steps should be to proceed with this since the State machine is very valuable.


    7. Context transfer for PANA: 20 min, Julien Bournelle New I-D presentation for draft-bournelle-pana-ctp-00.txt.
    Julien: Problem: Reauthentication from scratch ahen it moves to new PAA and that's hwy we need CTP (context transfer). The base PANA draft mentions that we need CTP for supporting mobility.
    Two cases were discussed: Reactive and predictive:
    Various uses were discussed: for example, CTP mentions use of CTAR message to trigger the transfer
    - seems necessary in predictive case
    Who enables the transfer?
    In CTP: MN and pAR shares a key. The pAR validate an authentication token
    -if PAA: can we still talk about CTP?

    ALper: Answering the 2nd question: it is the inclusion of session ID. Unless CTP does not mandate in CTAR format, it should be fine
    Raj: Session ID is not enough for CTP transfer
    Julien: Can we do that?
    Gerado: in CTP, CTAR is always required?

    Raj: We need to consider how do we do CTP? I agree that it may be necessary

    Gerado: CTP in Seamoby is not useful here.

    Vijay: Triggers should not be given by PANA

    Hannes: Mobility protocols should give the trigger

    Alper: If you know what to transfer, that's fine.

    Raj: CTP is protocol

    Raj: We should discuss in mailing list or offline.

    Issue: Do we need to introduce new state in state machine

    PAAs are not ARs (CTP mentions ARs)

    Should we handle inter-domain scenario?

    Vijay: If PAA is AR then 2nd point does not apply

    Alper: Regarding the state machine can we accommodate this?

    Yoshi: In case of mobility optimization, pAA is alwys stateful

    Hannes: Regarding the last bullet, for domain handover we need to consider something more and not beeen discussed in seamoby since multipartes are involved.

    Alper: Is it a protocol issue or operational issue

    Hannes: No it may be a protocol issue

    Raj: I don't know how important is to consider CTP here in context of PANA protocol and tight schedule


    8. Next steps: 5 min, Chairs

    We need to do the WG last call with requirements and threats with next few weeks

    Proceed to WG last call on Pana protocol, pana framework

    SNMP draft is not ready for WG last call. Chairs will find MIB doctor for this.


    PANA Protocol Update and Open Issues
    PANA Framework Update and Open Issues
    SNMP for the PAA-EP protocol
    PANA enabling IPsec based Access control
    State Machine for PANA
    CTP for PANA
    Next Steps