2.3.21 Protocol for carrying Authentication for Network Access (pana)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. 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-07-29

Chair(s):

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

Internet Area Director(s):

Mark Townsley <townsley@cisco.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Mark Townsley <townsley@cisco.com>

Technical Advisor(s):

Jari Arkko <Jari.Arkko@piuha.net>

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
Done  Submit IPsec-based access control to the IESG
Done  Submit PANA framework to the IESG
Done  Submit PANA protocol specification to the IESG
Oct 05  Submit PANA state machine specification to the IESG
Dec 05  Submit SNMP-based PAA-to-EP protocol specification to the IESG
Dec 05  Submit PANA-AAA interactions document to the IESG
Feb 06  Submit PANA mobility optimizations to the IESG
Mar 06  Submit MIB for PANA to the IESG

Internet-Drafts:

  • draft-ietf-pana-pana-10.txt
  • draft-ietf-pana-ipsec-07.txt
  • draft-ietf-pana-snmp-04.txt
  • draft-ietf-pana-framework-05.txt
  • draft-ietf-pana-mobopts-00.txt
  • draft-ietf-pana-statemachine-01.txt
  • draft-ieft-pana-aaa-interworking-00.txt

    Request For Comments:

    RFCStatusTitle
    RFC4016 I Protocol for Carrying Authentication and Network Access Threat Analysis and Security Requirements
    RFC4058 I Protocol for Carrying Authentication for Network Access (PANA)Requirements

    Current Meeting Report

    Meeting minutes of Protocol for carrying Authentication for Network
    Access (pana) WG from IETF63
    ====================================================================
    When: August 1st, 2005

    Credits for these minutes:
    1. Gerardo Giaretta (Gerardo.Giaretta@TILAB.COM)
    2. Subir Das (subir@research.telcordia.com) 
    Chairs: Alper Yegin <alper.yegin@samsung.com> 
	Basavaraj Patil <basavaraj.patil@nokia.com>


    0. Preliminaries, Agenda and Document Status (Chairs)
    .....................................................

    - Agenda bashing
    - drop one agenda item (pana-ipsec) because no author. Status to be sent on the mailing list

    - Status of various WG documents presented (See slides)

    1. PANA Framework
    .................
    Presenter: Yoshihiro Ohba
    I-D: -ietf-pana-framework-05.txt

    Yoshi presented the issue (such as Dual Stack) and there were no questions/comments on the floor

    2. PANA Protocol
    ................
    Presenter: Yoshihiro Ohba
    I-D: draft-ietf-pana-pana-10.txt

    Yoshi presented the technical issues and corresponding resolutions. e.g., Issues like Master key derivation algorithm, Dual Stack etc.. There were no questions on the floor.

    Raj: The PANA protocol specification is ready for AD review.

    3. SNMP usage for PAA-EP interface
    ..................................
    Presenter: Yacine El Mghazli
    I-D: draft-ietf-pana-snmp-04.txt

    Yacine presented the updated draft. Changes form ver 03:
    - Link layer access control, Accounting, Conformance section, IPSP MIB updates
    - Dependency w.r.t IPSP drafts:
    - PANA-SNMP re-uses from IPSP MIBs
    - PANA-specific objects extending the IPSP SPD-MIB

    Author Updates: IPSP authors updated the draft status: IESG will talk about

    Mark (AD): Alper has mentioned to me. Did you mention to the IESG?

    Authors: Yes, we have gave the info to IESG and no response from them

    Mark(AD): IESG is always flooded with info and may be but I will look into it.

    Avi Lior: I am a little bit confused:

    Q: Using SNMP for accounting? Don't know how scalable it is? Also SNMP's ability
    Q: Moving authorization info from PAA to EP. The question is there are Lot of info need to be moved from PAA to EP. Every time we transfer

    Yacine: The scope is only binary authorization. Other type such as pre-paid

    Alper: Is the SNMP extensible to cover other things?

    Yacine: Yes it can be done.

    Raj: Do you think SNMP can take care of other info such as pre-paid, per session info?


    Raj: Giving some background info: we did some studies on which protocol we should use.

    Yacine: We did some study such COPS, RADIUS

    Avi: Are you transferring accounting info back to PAA

    Yacine: Yes.

    Avi: Accounting should be outside of PANA

    Alper: You can use any protocol and it does not change the PANA framework.

    Avi: How is PANA involved with accounting?

    Yacine: If the WG thinks this is good we can delete that part. And people can use their own protocol for accounting.

    4. State machine for PANA
    .........................
    Presenter: Victor Fajardo
    I-D: draft-ietf-pana-statemachine-01.txt

    Victor presented the issues and corresponding resolutions:
    Issue 1: EAP-Restart()
    Issue 2: Nonce, PPAC, PCAP
    Issue 3: Obvious bug in the state machine
    Issue 4: PANA_PROTECTION_CAPABILITY
    Issue 5, Issue 6, Issue 7 etc…

    5. Interworking of PANA and Radius
    ..................................
    Presenter: Avi Lior
    I-D: draft-ietf-pana-aaa-interworking-00.txt

    Raj mentioned that this is a new WG item. Avi presented the draft. Next steps were also mentioned. Reviews of the document were sought for. There were no questions on the floor
    • PANA messages & AVPs to AAA messages & AVPs

    • simplifications

      • no AAA Proxy chains

      • EAP server is co-located with AAA server

      • NAS consists of PAA and AAA client

      • several AAA interactions: e.g. RADIUS client talking to Diameter server but also one authentication using Diameter and another using RADIUS

    • WG document standard and not informational

    • issues raised

      • multiple authentications, what if one fails?

        • issue with RADIUS: what happens if an Access-Reject is received?

        • rejection or rejection of what was authenticated

        • draft-aboba-radext-fixes-00 seems the right direction: Access Reject is a Reject of what you asked for and not tear down of the whole session

      • integration of Diameter
        • Diameter EAP was used

        • separate description, one for RADIUS and one for Diameter

    • what is next?

      • align with latest PANA

      • need a review (technical review first)

    6. DHCPv4 option for PANA Authentication Agents
    ...............................................
    Presenter: Suraj Kumar
    I-D: draft-suraj-dhcpv4-paa-option-00.txt

    Raj mentioned that this a new document for WG consideration. Suraj presented the draft. A new DHCPv4 option was proposed. Author asked for WG consensus:

    Raj clarified that this is not a PANA WG item. This needs to be discussed in Dhc WG.

    7. Pre-authentication Support for PANA
    ......................................
    Presenter: Yoshihiro Ohba
    I-D: draft-ohba-pana-preauth-00.txt
    • some kind of mobility support for PANA

    • FMIPv6-based and CTP-based are not applicable to cover the

    • inter-administrative domain handovers or heterogeneous handover in which authorization characteristics may differ

    • overview
      • proactively execute EAP authentication and PANA SA between PaC and the PAA in the new network

      • similar to 802.11i pre-suthentication

      • pre-authentication can be performed independently from the initial authentication, i.e. with different credential or with a different AAA server

      • terminology: pre-authentication, post-authorization

    • pre-authnetication operation (before handover)
      • pre-authentication can be initiated by preparing PAA or PaC

      • P-flag in PANA header to distinguish pre-authentication with normal one
    [Raj]: which is the trigger? the handover?
    [Yoshi]: pre-authentication can be started before the handover. Out of scope of this document how the host decides. E.g. additional thresold ofr signaling
    [Jari]: where to communicate with PANA?
    [Yoshi]: out of the scope also this. Triggers will depend on the technologies since it is a make before break approach
    • after handover
      • PaC performs a PANA-Update exchange (PUR/PUA)
    • authorization considerations

      • pre-authorization and post-authorization may have different policies

      • AAA protocol may need to carry additional attribute
    [Alper]: is part of standard document that specified how in .11i distinguish pre-authentication from authentication
    [Yoshi]: not sure if it is in the standard
    [Alper]: is part of RADIUS standard?
    [Avi]: we need to figure out what AAA server needs to know
    [Alper]: should it know that it is a pre-authentication? The AAA server needs to know it is a pre-authentication or not?
    [Avi]: I think so for example to manage resources or for billing
    [Raj]: whay would you care to have home AAA know that?
    [Jari]: start and stop accounting messages can be used to distinguish. If possible in the same way it is donw in 11i
    [Avi]: I may want to know if it is a pre-authentication for resources management

    [Vidya]: I guess what's different for .11i?
    [Avi]: I don't know
    [Vidya]: my understanding is now that the AAA server does not know anything about pre-authentication
    [Avi]: accounting can be used to understand if it was a pre-authentication or not

    [Subir]: is it a requirement for AAA to know that it is a pre-authentication?
    [Avi]: IMO it is a good idea for the AAA server. No technical but for business

    [Farouq]: one issue in 3GPP is how to distinguish sessions for the same ID
    [Jari}: it may be not wise to terminate the other session

    [Avi]: business reasons becuase of double authentication
    [Alper]: I think it is a AAA issue and it is orthogonal to PANA. Is there a block to distinguish them? Otherwise we should bring this problem to AAA
    • accounting: two options

      • PAA may start accounting immediatly after pre-authentication (like in MPA)

      • it may not start accounting before PaC starts
    [Avi]: are these optional or seeking for recomendation
    [Yoshi]: yes not mandated behaviuor but only recommendation
    [Jari]: wouldn't be good to mandate something?
    [Avi]: my recommendation is not start accoutnting until PaC active (second bullet)
    [Jari]: Agree

    - WG item?

    [Raj]: the objective is to enable mobility but there is CTP. Why do you need pre-auth is needed?
    [Yoshi]: CTP needs SA between PAAs and this is not possible
    [Raj]: in the same domain?
    [Yoshi]: authorization may differ in heterogeneous handovers with e.g. different link-layers
    [Raj]: isn't CTP

    [Gerardo]: when CTP is used a problem with authorization may arise. If links are different, you transfer some authorization state from PAA to another and the state may not be correct in the new PAA.
    [Raj]: PAA of the new can understand if auhorization is
    [Gerardo]: this is possible if PAA knows the user profile
    [Avi]: AAA server needs also to know where is the PaC and which is the PAA
    [Alper]: pre-authentication in this scenario can be a good fallback

    [Gerardo]: this solution solves the same problem of mobopt and ctp so we should understand which is needed

    Consensus to make it a WG item. Later we should discuss if this and mobility opts are needed.

    [Alper]: at the next step we will discuss if we need two solutions

    8. Use of Context Transfer Protocol (CxTP) for PANA
    ...................................................
    Presenter: Julien Bournelle
    I-D: draft-bournelle-pana-ctp-03

    Alper: In PANA Mobopts draft there are similar things and using the CTP protocol as context transfer. I think this should be an experimental draft

    Avi: Are you sending the termination message to old PAA?

    Julien: It is not described but it is possible.

    Avi: If you are doing this why are not using PANA Pre-Auth

    Julien: We are not using EAP.

    Yoshi:

    Jari: How many additional documents do we need to make this happen?

    AVi: May be how many more iteration do we need?

    Alper: What extra things do we need in AAA protocols to make this work?

    Julien: This is true for PANA-Mobopts not this one.

    Alper: I understand. We need to understand the big picture also.

    Raj: Do we need to go another round of iteration and address the AAA issues.

    Alper: Do we have a complete picture or

    Lionel: We should accept the WG item and address the issues.

    NOTE: Again I missed some interesting discussions here and I could not capture it..

    Alper: We can work proactively work on both options

    Lionel: How do we update the AAA authorization parameter.

    Raj: It is safe to assume that this document should be considered as WG Item and understand the AAA issues

    9. FPANA: combining PANA and FMIPv6 for fast authentication at handover
    ..............................................................
    Presenter: Humio Teraoka
    I-D: draft-hiko-pana-fpana-00.txt

    Humi presented the draft and described the problem space via a video.

    Raj: This is an important work and Mipshop can adopt this work and both PANA and Mipshop can jointly do this.

    Victor has mentioned the interop testing between Toshiba and Smsung implementations.

    10. Next Steps Chairs

    Raj: We have three documents under AD/IESG review. Mark has promised that he will give the review by September. As soon as we will receive the comments we will pass this to the mailing list.

    Mark: Who are the authors of IPSP draft? There are some miscommunications and pl. contact me after the meeting.

    Raj: We have now three WG documents and we will discuss the PANA-PreAuth and CTP drafts on the mailing list

    Slides

    Agenda
    PANA Framework Update
    PANA Specification Updates
    SNMP usage for PAA-EP
    PANA State Machine Issue Resolution
    PANA RADIUS
    DHCPv4 option for PANA Authentication Agents
    Pre-authentication Support for PANA
    Use of CxTP for PANA
    FPANA: Combining PANA and FMIPv6 for Fast Authentication at Handover