2.3.11 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 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-02

Basavaraj Patil <basavaraj.patil@nokia.com>
Alper Yegin <alper@docomolabs-usa.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: ftp://ftp.ietf.org/ietf-mail-archive/pana
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:
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
Dec 03  Submit IPsec-based access control to the IESG
Dec 03  Submit protocol specification to the IESG
Jan 04  Submit interaction of PANA with 802.1x and PPP document to the IESG
Apr 04  Submit MIB for PANA to the IESG
  • - draft-ietf-pana-usage-scenarios-06.txt
  • - draft-ietf-pana-requirements-07.txt
  • - draft-ietf-pana-threats-eval-04.txt
  • - draft-ietf-pana-pana-03.txt
  • - draft-ietf-pana-ipsec-01.txt
  • No Request For Comments

    Current Meeting Report

    Protocol for Carrying Authentication for Network Access WG (pana)
    Monday, March 1 at 1530-1730
      Basavaraj Patil 
      Alper Yegin 
    Note Takers: Hannes Tschofenig, Yacine El Mghazli
    # = conversations/comments/questions
    * = slides 
    Slides are available at 
    1. Preliminaries (bluesheets, minute takers, agenda bashing) : 5 min 
    2. PANA framework: 30 min, Alper Yegin
       draft-ohba-pana-framework-00.txt. This is a new I-D. The WG's opinion
       will be solicited for accepting this I-D as an official working group 
    * functional model
    * signaling flow
    * deployment env.
       a) secured phys netwk
            a1) crypto sec (cdma2000)
            a2) phys sec (dsl)
    * IP address conf
      pre-PANA address: PRPA
      post-PANA address: POPA
    * PRPA conf
      possible ways
        v4 link-local
        ipv6 address autoconf (global or link-local)
    * POPA conf (no IPSec)
        - POPA replaces PRPA (prevent address selection problem)
        - host route between PaC and PAA (preserve on-link 
        - use both PRPA and POPA at the same time
    # subir: once auth done with PRPA, when there is an EP. Which address the 
    PAA sends to the EP ? POPA or PRPA ?
    # alper: after binding (here is my new IP address POPA) POPA is sent to EP to 
    update the filter. 
    # lionel: if L2 protection is used, do we rely on mac address ?
    # alper: yes. 
    * POPA conf (IPsec)
      possible ways
    * Combinations
      table for recap
    # alper: the mac address is used when IPSec-based access control is not 
    used. no device id update is necessary in this case. 
    # subir: treatment between IPSec and non-IPSec case is different. IPsec 
    case: what PAA sends to EP ? PRPA ?
    # alper: yes. ipsec case: PRPA is configured and used during PANA. 
    # subir: what will the PaC send to the PAA ? 
    # alper: PRPA. alper: PRPA is used for outer header, POPA is used for 
    inner header. IPsec SA used to accept/drop packets.
    * additional approches (1) using PRPA as TIA
      requires SPD selection based on the name (session_ID) not the IP 
      address explicit support in RFC2401bis
      RFC2401? not clear
      should we include this ?
    # alper: do we include this case into the framework ?... maybe in the 
    * approach (2) using PRPA as TIA
      RFC2401: same considerations
      forwarding considerations
    # alper: should we include this ? any feedback regarding 
    * Data Traffic protection
        already available in type (a) environments
        enabled by PANA in type (b) environments
          EAP generated keys
          SA prototocol
    * PAA-2-EP
        EP closest IP capable acccess device to PaCs
        co-located with PAA or separate
        one or more EPs per PAA
        EP may detect presence of PaC and trigger PANA by notifying PAA
    * Net (ISP) discovery and select
        traditional select
          Port-number or L2 address based
        PANA-based discovery and select
          PAA advertises ISPs
          PaC explicitly picks one
    # jari: in pana you can also do nai based selection? 
    # alper: yes.
    # alper: there are two service providers here: access and isp
    # jari: how is this isp selected? 
    # jari: [question regarding his draft and network selection...]
    # hannes: known as EAP sequencing 
    # alper: this is not related to EAP sequencing. the client says only which 
    ISP he wants to be authenticated to.
    # hannes: can a client have separate NAIs ?
    # alper: yes
    # subir: the PAA receives the NAI. who does the mapping ?
    # alper: NAS does. PAA is on the NAS.
    # dan: how would exactly the routing work? 
    # alper: it heavily depends on the scenario. alper lists a few 
    scenarios. there may be roaming agreement.
    # dan: if NAS cannot map, we must specify what happens then
    # alper: this is like "unrecognized user" case.
    # dan: it's 2 different issues.
    # subir: do you consider scenarios where there is an access net using 
    several ISPs?
    # alper: AAA packets goes to the AAA backend. the home AAA server 
    athenticates and authz you. simple roaming.
    # farid: seems like there is both home-ISP and mediate-ISPs. why not using 
    NAI for both ? why don't you need jari's new nai scheme? 
    # alper: I look into details later. for me it looks like NAI 
    # yoshi: this ISP selection is independant of any intermediate ISPs. 
    similar to SSIDs.
    * Authentication method choice
        depends on the env.
      DSL deployment
        PANA needed when static IP or DHCP-based configuration is 
        used (instead
        of PPP)
        bridging mode
        address translation (NAPT) mode
        router mode
    # subir: how does the ppp & pana scenario looks like? 
    # alper: you don't need PANA if there is PPP in the stack.
    * dynamic ISP selection
        as part of the DHCP protocol or an attribute of DSL access line
          DHCP cient ID
          run DHCP, and PANA
          PRPA is the ultimate IP¨address
        as part of PANA auth
          temporary PRPA via zeroconf or DHCP with NAP
          run PANA for AAA
          POPA via DHCP, replace PRPA
    # subir: who runs the DHCP server ? managed by NAP or ISP ?
    # alper: it really depends. the NAP can run a DHCP relay for instance.
    * WLAN 
        net-layer per-packer sec (ipsec)
        link-layer per-packer sec (WPA-SK)
    * IPsec, IKEv2
          ipsec TOA= PRPA (dhcp)
          ipsecd TIA= POPA
        alternative RFC 3456
          ipsec-toa= prpa
    * bootstraping WPA/IEEE 802.11i
        PSK mode enabled
        MAC address used
    * Flow
    # subir: if the PaC gets an IP address, which address will the dhcp 
    server provide to the pac when the same mac address is provided ?
    # alper: dhcp always maintains a list of mac address 
    # yoshi: the requests appear on 2 different sub-nets. the server can give 
    different IP address. the interfaces are different. 
    # raj: let's get this discussion offline.
    * co-located PAA and AP(EP)
    * capability discovery
        types of network
        IEEE 802.1X-secured
          data driven PANA discovery
          client initiated discovery
    * The end.
    # lionel: about WLAN: in that case, we use the MAC address as DI. ip 
    address could also be used. could we mandate the case when we use 
    different auth ? this could be included in the draft.
    # alper: changing the IP address wont affect the whole framework
    # lionel: can this be clarified in the text ?
    # alper: should this become PANA wg item?
    # raj: how many read the draft? [13]
    # raj: among them, who says yes? [10]
    # raj: let's take this to the list.
    3. PANA protocol update and open issues: 30 min; Yoshihiro Ohba, 
    Basavaraj Patil
       draft-ietf-pana-pana-03.txt. See "Change History" section of the draft 
    for the list of issues closed in this revision.  Detailed issue 
    descriptions can be found at 
    http://danforsberg.info:8080/pana-issues/ Newly closed issues and 
    currently open issues will be covered in this presentation for 
    confirming/achieving consensus.
    * issue 52: details of double auth
    # jari: [concerns about how you avoid the MITM attack]. you need keys from 
    both eap methods. how it works ?
    # yoshi: combine keys.
    # jari: combine keys is fine.
    # lionel: I don't understand the need. I don't see the usefulness.
    # jari: I guess you don't have to have a combined key. you have to prove 
    possesion of the keys. it's a real issue.
    * issue 53: additional discovery information
    * issue 54: mandatory cookie
    # alper: I don't fully understand: if you want to make the discovery 
    stateless why cannot we mandate the cookie and allow the eap method 
    payload as a response?
    # yoshi: EAP creates state for the retransmission.
    # jari: something else: for a real auth to start, you have to have 
    identity request at the first message. do you? i am not sure that you need 
    state in all cases
    # yoshi: it seems to be according to the EAP draft. 
    # jari: to be exact: the EAP requires to have a state on this 
    transmission thing. from a technical view, maybe we dont need it...but 
    maybe we shouldn't go that far. 
    * issue 55: is client cookie useful?
    # jari: yes, a host can  be a malicious node claiming to be a PAA. it 
    would be good to provide this protection 
    # hannes: initially, we proposed also to use another solution.
    # alper: if we use that cookie, everyone on the same subnet will hear it, 
    and everyone can respond with the same cookie. this threa cannot be 
    prevented, since the discovery is broadcasted and hence also seen by the 
    adversary. a malicious can always act as if it were an 
    authenticator. for off-path adversaries we can simple do filtering. 
    * issue 56: AAA routing based on NAI vs. ISP choice clarification
    # yoshi: clarifications added in the next version of the draft.
    * issue 57: PSR retransmission strategy
    # yoshi: does it make sense ?
    # lionel: stateless or stateful discovery ? who creates the cookie, PaC or 
    PAA ?
    # yoshi: generated by PAA.
    # lionel: the PAA is not able to know if it's stateless or not.
    # yoshi: I don't understand
    # lionel: the PAA has to keep records
    # yoshi: no. the PAA does not have to keep record. let's discuss on the 
    * issue 58: fast-reauth and authz. CTP has some problems as described in the 
    eap-keying draft.
    # kempf: what's the CTP issue ? 
    # jari: [refers the eap-keying draft in detail]
    # hannes: deployment issue. nothing surprisly new. [issue in detail].
    # jari: [discussion whether a CT has to carry all authorization 
    parameters]. some authorization parameters are implicit and not 
    communicated to the nas such as the session limit they are only 
    enforced at the visited network. 
    # alper: move this to the ML please
    * issue 62: PAA discovery triggered by data traffic
    * issue 63: MAV AVP a SHOULD or a MUST now it is a should, it would be 
    better to meke it MUST
    * issue 64: 2 separate codes for session id
    * issue 65: clarification on simultaneous per-packet protection
    [raj for the closed issues:]
    * issue 28: PaC/PAA state machine
    # raj: should be included in the next version of the protocol draft. 
    * issue 35: EP information
    * issue 36: reauth race condition
    * minor issues
    # raj: questions to the ML.
    4. SNMP usage for PAA-2-EP interface: 20 min, Yacine El Mghazli
       draft-yacine-pana-snmp-01.txt. This is a new I-D. The WG's opinion will be 
    solicited for accepting this I-D as an official working group item.
    # alper: how many people have read the draft [9]
    # alper: how many thinks it should be a WG doc [8]
    # alper: not enough people. see on the ML.
    # raj: I think it's ok, it's a long time now that this is discussed.
    # alper: yes.
    5. PANA-IPsec I-D update and open issues: 15 min; Hannes Tschofenig, Mohan 
    www.yegin.org/IETF/draft-ietf-pana-ipsec-02.txt. Objective is to 
       discuss the latest changes (see Revision Log) and confirm 
    # yacine: the PSK is derived from the AAA-key, what if it changes? must we 
    re-provision the EP with the new one ?
    # hannes: it's close to the session_id problem.
    # alper: it is an issue.
    6. Next steps: 5 min, Chairs/Ads
    # alper: goal is to update the drafts as soon as possible and send them to wg 
    last call before the next ietf. for all drafts:
      - pana-pana
      - pana-ipsec
      - pana-fwk
      - pana-paa2ep


    Open issues with PANA Protocol
    PANA Framework
    SNMP for the PAA-2-EP protocol
    PANA enabling IPsec based Access control
    Next Steps