2.3.20 Protocol for carrying Authentication for Network Access (pana)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. 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-09-28

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@ericsson.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. 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 transmitted between the
client (PaC) and the enforcement point (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 PaC
and the EP (a router) to enable access control. 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 a router (EP) subsequent to authentication for
securing the data packets.

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 2005  Submit PANA state machine specification to the IESG
Dec 2005  Submit SNMP-based PAA-to-EP protocol specification to the IESG
Dec 2005  Submit PANA-AAA interactions document to the IESG
Feb 2006  Submit PANA mobility optimizations to the IESG
Mar 2006  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-01.txt
  • draft-ietf-pana-statemachine-03.txt
  • draft-ieft-pana-aaa-interworking-00.txt
  • draft-ietf-pana-preauth-00.txt
  • draft-ietf-pana-cxtp-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

     
    Minutes of:
Protocol for Carrying Authentication for Network Access (PANA) WG
meeting at IETF64 

WEDNESDAY, November 9, 2005

Chairs: Basavaraj Patil , 
	Alper Yegin  

Credits for these minutes:
1. Julien Bournelle 
2. Jean-Michel Combes 

==================================================

1. WG Document status (B. Patil)

AD evalutation
   draft-ietf-pana-pana
   draft-ietf-pana-ipsec
AD reviewed
   draft-ietf-pana-fwk

Ready for wg lc
   draft-ietf-pana-state-machine
New wg I-Ds
    draft-ietf-pana-preauth
    draft-ietf-pana-cxtp

Dependency challenges
   draft-ietf-pana-snmp

Revision and discussion needed:
   draft-ietf-pana-aaa-interworking
   draft-ietf-pana-mobopts

.........................................

2. State machine for pana (presenter: Yoshihiro Ohba)
I-D: draft-ietf-pana-statemachine-03
- 3 issues
  #1 REmove UPDATE_POPA event variable
  #2 Added MAC AVP insertion
  #3 Remove USE_COOKIE checks in all exit events

No questions or discussion

.........................................

3. Pre-authentication Support for PANA (presenter: Yoshihiro Ohba)
I-D: draft-ietf-pana-preauth-00	  

New WG item; Consensus at IETF63

*distinguishing pre-auth from normal authentication
*default accounting behavior

ay: better if accounting starts after the pac moves to the new link.
    there might be mutliple paas at a given time
yo: the text covered this aspect. there should be only one SA ??

sd : network initiated by paa or pac ?
yo : both case. even if network initiates, trigger may come from
some functions outside
sd: i'm not saying that both cases handle in the same way ?
     seems different ?
yo : i think it's the same? there's some trigger. explicit from pac or
paa or some other trigger may come from the pac

sd: it's less unlikely that it comes from the pac. there may be some
SA established between this element ?

yo : ...
*more considerations on dos attack

.........................................

4. PANA Mobility Optimizations Analysis (presenter: J. Bournelle)
I-D: draft-bournelle-pana-mobopts-analysis-00 

- Provide an analysis of solutions specified in 
     pana mobopts
     pana cxtp

- Intermediary Key Transfer
Alper: Issue with "Domino Effect" in EAP framework draft ... wait for
feedbacks from saag 

- Differents scenarios
- AAA Considerations

? : Similaries between PANA and Kerberos
JB : Use Kerb instead of EAP ?
? : Yes ...
Patil : Just an optimization of PANA for mobility and hence kereberos
is not really an option here.

PANA Mobility Optimizations with Session Keys Context  (Presented by
J. Bournelle)
I-D: draft-forsberg-pana-skc-00

- Introduce KDC concept and SKC key
- KDC as AAA proxy
- SKC Context

Yoshi : How PaC knows such new architecture ?
JB : .. needs to update draft
? : Need to change KDC name if no links with KErberos
Alper : Needs of new protocols and so potential impact on PANA framework
JB : Agree

.........................................

5. DHCPv4 option for PANA Authentication Agents (presenter: Lionel Morand)
I-D: draft-suraj-dhcpv4-paa-option-01

- Document Status: approved as WG in DHC WG
- New version 01 will include IPv4 and IPV6 Options !
Sd : One or more PAA per request?
LM : Multiple PAAs sent in one request

.........................................

6. Next steps (Alper Yegin)
Captured in slides

##################################


ay: Alper Yegin
sd: Subir Das
yo: Yoshihiro Ohba
lm: Lionel Morand
jb: Julien Bournelle

    Slides

    Agenda, Document Status, Next steps
    PANA Mobility Optimizations Analysis
    PANA Mobility Optimizations with Session Keys Context
    DHCPv4 option for PANA Authentication Agents
    Pre-authentication Support for PANA
    PANA State Machine Issue Resolution