GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5193

Network Working Group P. Jayaraman Request for Comments: 5193 Net.Com Category: Informational R. Lopez

                                                       Univ. of Murcia
                                                          Y. Ohba, Ed.
                                                               Toshiba
                                                      M. Parthasarathy
                                                                 Nokia
                                                              A. Yegin
                                                               Samsung
                                                              May 2008

Protocol for Carrying Authentication for Network Access (PANA) Framework

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Abstract

 This document defines the general Protocol for Carrying
 Authentication for Network Access (PANA) framework functional
 elements, high-level call flow, and deployment environments.

Table of Contents

 1. Introduction ....................................................2
    1.1. Specification of Requirements ..............................2
 2. General PANA Framework ..........................................2
 3. Call Flow .......................................................5
 4. Environments ....................................................6
 5. Security Considerations .........................................8
 6. Acknowledgments .................................................8
 7. References ......................................................8
    7.1. Normative References .......................................8
    7.2. Informative References .....................................9

Jayaraman, et al. Informational [Page 1] RFC 5193 PANA Framework May 2008

1. Introduction

 PANA (Protocol for carrying Authentication for Network Access) is a
 link-layer agnostic network access authentication protocol that runs
 between a client that wants to gain access to the network and a
 server on the network side.  PANA defines a new Extensible
 Authentication Protocol (EAP) [RFC3748] lower layer that uses IP
 between the protocol end points.
 The motivation to define such a protocol and the requirements are
 described in [RFC4058].  Protocol details are documented in
 [RFC5191].  Upon following a successful PANA authentication, per-
 data-packet security can be achieved by using physical security,
 link-layer ciphering, or IPsec [PANA-IPSEC].  The server
 implementation of PANA may or may not be colocated with the entity
 enforcing the per-packet access control function.  When the server
 for PANA and per-packet access control entities are separate, a
 protocol (e.g., [ANCP-PROTO]) may be used to carry information
 between the two nodes.
 PANA is intended to be used in any access network regardless of the
 underlying security.  For example, the network might be physically
 secured, or secured by means of cryptographic mechanisms after the
 successful client-network authentication.  While it is mandatory for
 a PANA deployment to implement behavior that ensures the integrity of
 PANA messages when the EAP method produces MSK, it is not mandatory
 to implement support for network security at the link-layer or
 network-layer.
 This document defines the general framework for describing how these
 various PANA and other network access authentication elements
 interact with each other, especially considering the two basic types
 of deployment environments (see Section 4).

1.1. Specification of Requirements

 In this document, several words are used to signify the requirements
 of the specification.  These words are often capitalized.  The key
 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
 are to be interpreted as described in [RFC2119].

2. General PANA Framework

 PANA is designed to facilitate the authentication and authorization
 of clients in access networks.  PANA is an EAP [RFC3748] lower layer
 that carries EAP authentication methods encapsulated inside EAP
 between a client node and a server in the access network.  While PANA

Jayaraman, et al. Informational [Page 2] RFC 5193 PANA Framework May 2008

 enables the authentication process between the two entities, it is
 only a part of an overall AAA (Authentication, Authorization and
 Accounting) and access control framework.  A AAA and access control
 framework using PANA is comprised of four functional entities.
 Figure 1 illustrates these functional entities and the interfaces
 (protocols, APIs) among them.
                                               RADIUS,
                                               Diameter,
         +-----+       PANA        +-----+     LDAP, API, etc. +-----+
         | PaC |<----------------->| PAA |<------------------->| AS  |
         +-----+                   +-----+                     +-----+
            ^                         ^
            |                         |
            |         +-----+         |
    IKE,    +-------->| EP  |<--------+ ANCP, API, etc.
    4-way handshake,  +-----+
    etc.                 .
                         .
                         .
                         v
                    Data traffic
                     Figure 1: PANA Functional Model
 PANA Client (PaC):
    The PaC is the client implementation of PANA.  This entity resides
    on the node that is requesting network access.  PaCs can be end
    hosts, such as laptops, PDAs, cell phones, desktop PCs, or routers
    that are connected to a network via a wired or wireless interface.
    A PaC is responsible for requesting network access and engaging in
    the authentication process using PANA.
 PANA Authentication Agent (PAA):
    The PAA is the server implementation of PANA.  A PAA is in charge
    of interfacing with the PaCs for authenticating and authorizing
    them for the network access service.
    The PAA consults an authentication server in order to verify the
    credentials and rights of a PaC.  If the authentication server
    resides on the same node as the PAA, an API is sufficient for this
    interaction.  When they are separated (a much more common case in
    public access networks), a protocol needs to run between the two.
    AAA protocols like RADIUS [RFC2865] and Diameter [RFC3588] are
    commonly used for this purpose.

Jayaraman, et al. Informational [Page 3] RFC 5193 PANA Framework May 2008

    The PAA is also responsible for updating the access control state
    (i.e., filters) depending on the creation and deletion of the
    authorization state.  The PAA communicates the updated state to
    the Enforcement Points (EPs) in the network.  If the PAA and EP
    are residing on the same node, an API is sufficient for this
    communication.  Otherwise, a protocol is required to carry the
    authorized client attributes from the PAA to the EP.
    The PAA resides on a node that is typically called a NAS (network
    access server) in the access network.  For example, on a BRAS
    (Broadband Remote Access Server) [DSL] in DSL networks, or PDSN
    (Packet Data Serving Node) [3GPP2] in 3GPP2 networks.  The PAA may
    be one or more IP hops away from the PaCs.
 Authentication Server (AS):
    The server implementation that is in charge of verifying the
    credentials of a PaC that is requesting the network access
    service.  The AS receives requests from the PAA on behalf of the
    PaCs, and responds with the result of verification together with
    the authorization parameters (e.g., allowed bandwidth, IP
    configuration, etc).  This is the server that terminates the EAP
    and the EAP methods.  The AS might be hosted on the same node as
    the PAA, on a dedicated node on the access network, or on a
    central server somewhere in the Internet.
 Enforcement Point (EP):
    The access control implementation that is in charge of allowing
    access (data traffic) of authorized clients while preventing
    access by others.  An EP learns the attributes of the authorized
    clients from the PAA.
    The EP uses non-cryptographic or cryptographic filters to
    selectively allow and discard data packets.  These filters may be
    applied at the link layer or the IP layer [PANA-IPSEC].  When
    cryptographic access control is used, a secure association
    protocol [RFC3748] needs to run between the PaC and EP.  After
    completion of the secure association protocol, link- or network-
    layer per-packet security (for example TKIP, IPsec ESP) is enabled
    for integrity protection, data origin authentication, replay
    protection, and optionally confidentiality protection.
    An EP is located between the access network (the topology within
    reach of any client) and the accessed network (the topology within
    reach of only authorized clients).  It must be located
    strategically in a local area network to minimize the access of
    unauthorized clients.  It is recommended but not mandated that the

Jayaraman, et al. Informational [Page 4] RFC 5193 PANA Framework May 2008

    EP be on the path between the PaC and the PAA for the
    aforementioned reason.  For example, the EP can be hosted on the
    switch that is directly connected to the clients in a wired
    network.  That way the EP can drop unauthorized packets before
    they reach any other client node or nodes beyond the local area
    network.
 Some of the entities may be colocated depending on the deployment
 scenario.  For example, the PAA and EP would be on the same node
 (BRAS) in DSL networks.  In that case, a simple API is sufficient
 between the PAA and EP.  In small enterprise deployments, the PAA and
 AS may be hosted on the same node (access router) that eliminates the
 need for a protocol run between the two.  The decision to colocate
 these entities or otherwise, and their precise location in the
 network topology, are deployment decisions that are out of the scope
 of this document.

3. Call Flow

 Figure 2 illustrates the signaling flow for authorizing a client for
 network access.
                PaC             EP               PAA              AS
                 |               |                |                |
    IP address ->|               |                |                |
    config.      |       PANA    |                |      AAA       |
                 |<------------------------------>|<-------------->|
                 |               |  Provisioning  |                |
    (Optional)   |               |<-------------->|                |
    IP address ->|               |                |                |
    reconfig.    |   Sec.Assoc.  |                |                |
                 |<------------->|                |                |
                 |               |                |                |
                 |  Data traffic |                |                |
                 |<----------------->             |                |
                 |               |                |                |
                     Figure 2: PANA Signaling Flow
 The EP on the access network allows general data traffic from any
 authorized PaC, whereas it allows only a limited type of traffic
 (e.g., PANA, DHCP, router discovery, etc.) for the unauthorized PaCs.
 This ensures that the newly attached clients have the minimum access
 service to engage in PANA and get authorized for the unlimited
 service.
 The PaC dynamically or statically configures an IP address prior to
 running PANA.  After the successful PANA authentication, depending on

Jayaraman, et al. Informational [Page 5] RFC 5193 PANA Framework May 2008

 the deployment scenario, the PaC may need to re-configure its IP
 address or configure additional IP address(es).  For example, a
 link-local IPv6 address may be used for PANA and the PaC may be
 allowed to configure additional global IPv6 address(es) upon
 successful authentication.  Another example: A PaC may be limited to
 using an IPv4 link-local address during PANA, and allowed to
 reconfigure its interface with a non-link-local IPv4 address after
 the authentication.  General-purpose applications cannot use the
 interface until PANA authentication succeeds and appropriate IP
 address configuration takes place.
 An initially unauthorized PaC starts PANA authentication by
 discovering the PAA, followed by the EAP exchange over PANA.  The PAA
 interacts with the AS during this process.  Upon receiving the
 authentication and authorization result from the AS, the PAA informs
 the PaC about the result of its network access request.
 If the PaC is authorized to gain access to the network, the PAA also
 sends the PaC-specific attributes (e.g., IP address, cryptographic
 keys, etc.) to the EP by using another protocol.  The EP uses this
 information to alter its filters to allow data traffic from and to
 the PaC to pass through.
 In case cryptographic access control needs to be enabled after PANA
 authentication, a secure association protocol runs between the PaC
 and the EP.  Dynamic parameters required for that protocol (e.g.,
 endpoint identity, shared secret) are derived from successful PANA
 authentication; these parameters are used to authenticate the PaC to
 the EP and vice-versa as part of creating the security association.
 For example, see [PANA-IPSEC] for how it is done for IKE [RFC2409]
 [RFC4306] based on using a key-generating EAP method for PANA between
 the PaC and PAA.  The secure association protocol exchange produces
 the required security associations between the PaC and the EP to
 enable cryptographic data traffic protection.  Per-packet
 cryptographic data traffic protection introduces additional per-
 packet overhead but the overhead exists only between the PaC and EP
 and will not affect communications beyond the EP.
 Finally, filters that are installed at the EP allow general purpose
 data traffic to flow between the PaC and the intranet/Internet.

4. Environments

 PANA can be used on any network environment whether there is a
 lower-layer secure channel between the PaC and the EP prior to PANA,
 or one has to be enabled upon successful PANA authentication.

Jayaraman, et al. Informational [Page 6] RFC 5193 PANA Framework May 2008

 With regard to network access authentication, two types of networks
 need to be considered:
 a. Networks where a secure channel is already available prior to
    running PANA
    This type of network is characterized by the existence of
    protection against spoofing and eavesdropping.  Nevertheless, user
    authentication and authorization is required for network
    connectivity.
    a.1. One example is a DSL network where lower-layer security is
         provided by a physical means.  Physical protection of the
         network wiring ensures that practically there is only one
         client that can send and receive IP packets on the link.
    a.2. Another example is a cdma2000 network where the lower-layer
         security is provided by means of cryptographic protection.
         By the time the client requests access to the network-layer
         services, it is already authenticated and authorized for
         accessing the radio channel, and link-layer ciphering is
         enabled.
    The presence of a secure channel before the PANA exchange
    eliminates the need for executing a secure association protocol
    after PANA.  The PANA session can be associated with the
    communication channel it was carried over.  Also, the choice of
    EAP authentication method depends on the presence of this security
    while PANA is running.
 b. Networks where a secure channel is created after running PANA
    These are the networks where there is no lower-layer protection
    prior to running PANA.  Successful PANA authentication enables the
    generation of cryptographic keys that are used with a secure
    association protocol to enable per-packet cryptographic
    protection.
    PANA authentication is run on an insecure channel that is
    vulnerable to eavesdropping and spoofing.  The choice of EAP
    method must be resilient to the possible attacks associated with
    such an environment.  Furthermore, the EAP method must be able to
    create cryptographic keys that will later be used by the secure
    association protocol.

Jayaraman, et al. Informational [Page 7] RFC 5193 PANA Framework May 2008

    Whether to use
    b.1. link-layer per-packet security or
    b.2. network-layer per-packet security
    is a deployment decision and outside the scope of this document.
    This decision also dictates the choice of the secure association
    protocol.  If link-layer protection is used, the protocol would be
    link-layer specific.  If IP-layer protection is used, the secure
    association protocol would be IKE and the per-packet security
    would be provided by IPsec AH/ESP regardless of the underlying
    link-layer technology.

5. Security Considerations

 Security is discussed throughout this document.  For protocol-
 specific security considerations, refer to [RFC4016] and [RFC5191].

6. Acknowledgments

 We would like to thank Bernard Aboba, Yacine El Mghazli, Randy
 Turner, Hannes Tschofenig, Lionel Morand, Mark Townsley, Jari Arkko,
 Pekka Savola, Tom Yu, Joel Halpern, Lakshminath Dondeti, David Black,
 and IEEE 802.11 Working Group for their valuable comments.

7. References

7.1. Normative References

 [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC3748]    Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
              H. Levkowetz, Ed., "Extensible Authentication Protocol
              (EAP)", RFC 3748, June 2004.
 [RFC2409]    Harkins, D. and D. Carrel, "The Internet Key Exchange
              (IKE)", RFC 2409, November 1998.
 [RFC4306]    Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
              Protocol", RFC 4306, December 2005.
 [RFC4058]    Yegin, A., Ed., Ohba, Y., Penno, R., Tsirtsis, G., and
              C. Wang, "Protocol for Carrying Authentication for
              Network Access (PANA) Requirements", RFC 4058, May 2005.

Jayaraman, et al. Informational [Page 8] RFC 5193 PANA Framework May 2008

 [RFC5191]    Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
              and A. Yegin, "Protocol for Carrying Authentication for
              Network Access (PANA)", RFC 5191, May 2008.
 [DSL]        DSL Forum Architecture and Transport Working Group, "DSL
              Forum TR-059 DSL Evolution - Architecture Requirements
              for the Support of QoS-Enabled IP Services", September
              2003.

7.2. Informative References

 [RFC2865]    Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.
 [RFC3588]    Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September
              2003.
 [RFC4016]    Parthasarathy, M., "Protocol for Carrying Authentication
              and Network Access (PANA) Threat Analysis and Security
              Requirements", RFC 4016, March 2005.
 [ANCP-PROTO] Wadhwa, S., Moisand, J., Subramanian, S., Haag, T., and
              N. Voigt, "Protocol for Access Node Control Mechanism in
              Broadband Networks", Work in Progress, November 2007.
 [PANA-IPSEC] Parthasarathy, M., "PANA Enabling IPsec based Access
              Control", Work in Progress, July 2005.
 [3GPP2]      3rd Generation Partnership Project 2, "cdma2000 Wireless
              IP Network Standard", 3GPP2 P.S0001-B/v2.0, September
              2004.

Jayaraman, et al. Informational [Page 9] RFC 5193 PANA Framework May 2008

Authors' Addresses

 Prakash Jayaraman
 Network Equipment Technologies, Inc.
 6900 Paseo Padre Parkway
 Fremont, CA  94555
 USA
 Phone: +1 510 574 2305
 EMail: prakash_jayaraman@net.com
 Rafa Marin Lopez
 University of Murcia
 30100 Murcia
 Spain
 Phone: +34 968 398 501
 EMail: rafa@um.es
 Yoshihiro Ohba
 Toshiba America Research, Inc.
 1 Telcordia Drive
 Piscateway, NJ  08854
 USA
 Phone: +1 732 699 5305
 EMail: yohba@tari.toshiba.com
 Mohan Parthasarathy
 Nokia
 313 Fairchild Drive
 Mountain View, CA  94043
 USA
 Phone: +1 408 734 8820
 EMail: mohanp@sbcglobal.net
 Alper E. Yegin
 Samsung
 Istanbul,
 Turkey
 EMail: a.yegin@partner.samsung.com

Jayaraman, et al. Informational [Page 10] RFC 5193 PANA Framework May 2008

Full Copyright Statement

 Copyright (C) The IETF Trust (2008).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Jayaraman, et al. Informational [Page 11]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5193.txt · Last modified: 2008/05/12 17:54 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki