GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6345

Internet Engineering Task Force (IETF) P. Duffy Request for Comments: 6345 Cisco Category: Standards Track S. Chakrabarti ISSN: 2070-1721 Ericsson

                                                             R. Cragie
                                                                  PG&E
                                                          Y. Ohba, Ed.
                                                               Toshiba
                                                              A. Yegin
                                                               Samsung
                                                           August 2011
   Protocol for Carrying Authentication for Network Access (PANA)
                           Relay Element

Abstract

 This document specifies Protocol for carrying Authentication for
 Network Access (PANA) Relay Element functionality, which enables PANA
 messaging between a PANA Client (PaC) and a PANA Authentication Agent
 (PAA) where the two nodes cannot reach each other by means of regular
 IP routing.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6345.

Duffy, et al. Standards Track [Page 1] RFC 6345 PANA Relay Element August 2011

Copyright Notice

 Copyright (c) 2011 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1. Introduction ....................................................2
    1.1. Specification of Requirements ..............................3
 2. PANA Relay Element ..............................................3
 3. Security of Messages Sent between PRE and PAA ...................5
 4. PANA Messages for Relay Operation ...............................7
    4.1. PANA-Relay .................................................7
 5. PANA AVPs for Relay Operation ...................................7
    5.1. PaC-Information AVP ........................................7
    5.2. Relayed-Message AVP ........................................7
 6. Security Considerations .........................................8
 7. IANA Considerations ............................................10
 8. Acknowledgments ................................................10
 9. References .....................................................10
    9.1. Normative References ......................................10
    9.2. Informative References ....................................11

1. Introduction

 Protocol for carrying Authentication for Network Access (PANA)
 [RFC5191] is a UDP-based protocol to perform Extensible
 Authentication Protocol (EAP) authentication between a PANA Client
 (PaC) and a PANA Authentication Agent (PAA).
 This document specifies PANA Relay Element (PRE) functionality, which
 enables PANA messaging between a PaC and a PAA where the two nodes
 cannot reach each other by means of regular IP routing.  For example,
 in ZigBee IP [ZIGBEEIP] that uses 6LoWPAN [RFC4944], a joining node
 (PaC) can only use a link-local IPv6 address to communicate with a
 parent node prior to PANA authentication.  The PAA typically resides
 in a 6LowPAN Border Router (6LBR) [6LoWPAN-ND], which is often

Duffy, et al. Standards Track [Page 2] RFC 6345 PANA Relay Element August 2011

 multiple IP hops away from the PaC.  The PRE implemented on the
 parent node is used for relaying PANA messages between the PaC and
 the PAA in this scenario.

1.1. Specification of Requirements

 In this document, several words are used to signify the requirements
 of the specification.  These words are 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. PANA Relay Element

 A PANA Relay Element (PRE) is a node that is located between a PaC
 and a PAA.  It is responsible for relaying the PANA messages between
 the PaC and the PAA.  The PRE does not need to maintain per-PaC
 state.  From the PaC's perspective, the PRE appears as the PAA.
 Normal IP routing is performed between the PRE and the PAA.  A PAA
 can communicate with multiple PREs.  A PRE can communicate with
 multiple PAAs, and it will choose one PAA to communicate with for a
 given PaC.  By default, the PaC discovers the PRE using the normal
 mechanism for PAA discovery as defined in [RFC5192].  PREs are
 assumed to be configured with the IP address(es) of the PAA(s).
 Dynamic PAA discovery schemes for PREs are outside the scope of this
 document.
 The PRE and the PAA support the relay operation as follows.
 When the PRE receives a PANA message from the PaC, it creates a PANA-
 Relay (PRY) message (see Section 4.1) containing a Relayed-Message
 AVP (see Section 5.2) and a PaC-Information AVP (see Section 5.1).
 The Relayed-Message AVP encapsulates the entire PANA Message received
 from the PaC.  The PaC-Information AVP contains the PaC's IP address
 and UDP port number used for sending the PANA messages.  The PRY
 message is sent to the PAA.
 When the PAA receives the PRY message, it retrieves the PaC-
 originated PANA message from the Relayed-Message AVP and the PaC's IP
 address and UDP port number from the PaC-Information AVP.  The PaC-
 originated PANA message is processed in the same way as specified in
 [RFC5191], with the following exceptions:
 (a) The IP address and the port number contained in the PaC-
     Information AVP and the source IP address and UDP port number of
     the PRE are used to identify the PaC among multiple PANA-Client-
     Initiation messages sent from different PaCs through the same PRE

Duffy, et al. Standards Track [Page 3] RFC 6345 PANA Relay Element August 2011

     or sent from more than one PaC with the same the IP address and
     the port number through different PREs.
 (b) The IP address and the port number contained in the PaC-
     Information AVP are maintained by the PAA in the PANA session
     attribute "IP address and UDP port number of the PaC" [RFC5191].
 (c) The IP address and UDP port number of the PRE are maintained by
     the PAA in a new PANA session attribute "IP address and UDP port
     number of the PRE".  A PANA session is referred to as a relayed
     PANA session if this attribute has a non-null value.
 When the PAA originates a PANA message for a relayed PANA session, it
 sends a PRY message to the PRE's IP address and sets the destination
 UDP port number to the UDP port number of the PRE maintained in the
 PANA session attribute "IP address and UDP port number of the PRE".
 The PRY message includes a Relayed-Message AVP containing the PAA-
 originated PANA message and also includes a PaC-Information AVP
 containing the PaC's IP address and UDP port number.
 When the PRE receives the PRY message, it retrieves the PAA-
 originated PANA message from the Relayed-Message AVP and the PaC's IP
 address and UDP port number from and PaC-Information AVPs.  The PAA-
 originated PANA message is sent to the PaC's IP address with the
 source UDP port number set to the PANA port number (716) and the
 destination UDP port number set to the UDP port number contained in
 the Relayed-Message AVP.
 The Session Identifier and Sequence Number of any PRY message are set
 to zero.  PRY messages are never retransmitted by the PRE or the PAA.
 Note that the PANA message carried in a Relayed-Message AVP may be
 retransmitted by the PaC or PAA, leading to transmission of a new PRY
 message carrying the same Relayed-Message AVP.
 A PAA that supports this specification MUST be able to process PRY
 messages for PaC-initiated PANA sessions.
 This specification assumes there is at most one PRE between the PaC
 and the PAA.  Performing relay operation on a PANA message that is
 already relayed (i.e., carried inside a PRY message) is out of scope
 of this specification.
 Figure 1 is an example message flow with a PRE.

Duffy, et al. Standards Track [Page 4] RFC 6345 PANA Relay Element August 2011

  PaC        PRE                          PAA   srcIP:port->dstIP:port
 -----      -----                        -----  ----------------------

1. —PCI–> IP1:p1 → IP2a:716

2. —PRY[P{IP1:p1},R{PCI}]–> IP2b:p2 → IP3:716

3. ←-PRY[P{IP1:p1},R{PAR}]— IP3:716 → IP2b:p2

4. ←-PAR— IP2a:716 → IP1:p1

5. —PAN–> IP1:p1 → IP2a:716

6. —PRY[P{IP1:p1},R{PAN}]–> IP2b:p2 → IP3:716

7. ←-PRY[P{IP1:p1},R{PAR}]— IP3:716 → IP2b:p2

8. ←-PAR— IP2a:716 → IP1:p1

9. —PAN–> IP1:p1 → IP2a:716

10. —PRY[P{IP1:p1},R{PAN}]–> IP2b:p2 → IP3:716

IP1 is the IP address of PaC.
IP2a and IP2b are the IP addresses of PRE.
IP2a is used for communicating with PaC.
IP2b is used for communicating with PAA.
The two IP address may be the same.
IP3 is the IP address of PAA.
p1 is PaC-assigned UDP port number.
p2 is PRE-assigned UDP port number.
P: PaC-Information AVP
R: Relayed-Message AVP
             Figure 1: Example Call Message for PANA Relay

3. Security of Messages Sent between PRE and PAA

 PRE/PAA security is OPTIONAL since PANA messages are designed to be
 used in untrusted networks, but if a cryptographic mechanism is
 supported, it SHOULD be IPsec.  When the device characteristics
 preclude support for IPsec, an alternative mechanism such as DTLS
 [RFC4347], or link-layer cryptographic security, etc., may be used
 instead.  This section describes how IPsec [RFC4301] can be used for
 securing the PANA relay messages.

Duffy, et al. Standards Track [Page 5] RFC 6345 PANA Relay Element August 2011

 When IPsec is used, each PRE must have an established pairwise trust
 relationship with a PAA.  That is, if messages from a PaC will be
 relayed by a PRE to a PAA, the PRE and PAA must be configured to use
 IPsec for the messages they exchange.
 PREs and PAAs that support secure PRE to PAA communication use IPsec
 under the following conditions:
 Selectors        PREs are manually configured with the addresses of
                  the PAAs to which PANA messages are to be forwarded.
                  PAAs that will be using IPsec for securing PANA
                  messages must also be configured with a list of the
                  PREs to which messages will be returned.  The
                  selectors for the PREs and PAAs will be the pairs of
                  addresses defining PREs and PAAs that exchange PANA
                  messages on the PANA UDP port 716 in their source or
                  destination port.
 Mode             PREs and PAAs use transport mode and ESP.  The
                  information in PANA messages is not generally
                  considered confidential, so encryption need not be
                  used (i.e., NULL encryption can be used).
 Key management   Because the PREs and PAA must be manually
                  configured, manually configured key management may
                  suffice, but does not provide defense against
                  replayed messages.  Accordingly, IKE with preshared
                  secrets SHOULD be supported.  IKE with public keys
                  MAY be supported.
 Security policy  PANA messages between PREs and PAAs should only be
                  accepted from PANA peers as identified in the local
                  configuration.
 Authentication   Shared keys, indexed to the source IP address of the
                  received PANA message, are adequate in this
                  application.
 Availability     Appropriate IPsec implementations are likely to be
                  available for PAAs and for PREs in more featureful
                  devices used in enterprise and core ISP networks.
                  IPsec is less likely to be available for PREs in
                  low-end devices primarily used in the home or small
                  office markets.

Duffy, et al. Standards Track [Page 6] RFC 6345 PANA Relay Element August 2011

4. PANA Messages for Relay Operation

4.1. PANA-Relay

 The PANA-Relay (PRY) message is sent by the PRE to the PAA or by the
 PAA to the PRE.  It contains one PaC-Information AVP and one Relayed-
 Message AVP.  The PRY message SHOULD NOT carry other AVPs.
 In a PRE-originated PRY message, the PaC-Information AVP contains an
 IP address and the UDP port number of the PANA message that was
 originated by the PaC and is contained in the Relayed-Message AVP.
 In a PAA-originated PRY message, the information in the PaC-
 Information AVP MUST be copied from the "IP address and UDP port
 number of the PaC" attribute of the associated PANA session
 [RFC5191].
 The Session Identifier and Sequence Number field of any PRY message
 MUST be set to zero.  A PRY message MUST NOT be retransmitted by the
 PRE or the PAA.
    PANA-Relay ::= < PANA-Header: 5 >
                   { PaC-Information }
                   { Relayed-Message }
                  *[ AVP ]

5. PANA AVPs for Relay Operation

5.1. PaC-Information AVP

 The PaC-Information AVP (AVP Code 10) is of type OctetString and
 contains an IP address (16-octet for an IPv6 address or 4-octet for
 an IPv4 address) followed by a 2-octet UDP port number of the PaC,
 both encoded in network-byte order.

5.2. Relayed-Message AVP

 The Relayed-Message (AVP Code 11) is of type OctetString and contains
 a relayed PANA message excluding the UDP and IP headers.

Duffy, et al. Standards Track [Page 7] RFC 6345 PANA Relay Element August 2011

6. Security Considerations

 A PRE's main objective is to assist transport of PANA messages
 between the PaC and the PAA.  Relay operation performed between the
 PRE and the PAA forms an additional logical link for relaying the
 end-to-end PANA messages between the PaC and the PAA.  In that sense,
 a PRE resembles a bridge or a router that sits between the PaC and
 the PAA when non-relayed PANA [RFC5191] is used.
 A PRE can pose certain threats to the relayed PANA messages.  A PRE
 can delay or drop PANA messages sent by the PaC or the PAA.  It can
 also spoof or modify PANA messages sent towards the PaC or the PAA.
 These threats are similar to what an on-path bridge/router (i.e., a
 man-in-the-middle, MitM) can pose to non-relayed PANA.  EAP and PANA
 protocols are designed to operate over unsecure links where
 aforementioned threats can already exist.  Even though these threats
 cannot be leveraged to gain unauthorized network access, or
 compromise of cryptographic keys (e.g., MK, MSK, EMSK, etc.), other
 damages such as preventing authentication to complete, or denial-of
 service are still possible.
 Even though the PRE-to-PAA relay path appears to be a separate
 additional logical link for transporting the PANA messages, the PRE
 may pose a few additional risks versus traditional on-path bridges
 and routers.  The following explains the risks and mitigations of PRE
 as a relay device.
 The PRE inserts PaC-Information AVP as the PaC-generated PANA packet
 is encapsulated in a PRY packet to the PAA.  This AVP carries the IP
 address and the UDP port number values of the PANA packet as sent by
 the PAC.  These values are already carried inside the IP and UDP
 headers with non-relayed PANA and they are not necessarily secured.
 EAP and PANA are designed to work in the absence of their protection.
 Therefore, no additional PANA-layer security is needed when these
 values are carried as PANA AVPs between the PRE and the PAA.  If a
 future document defines additional payload AVPs for the PRY messages,
 there may be a need to define additional security for those messages.
 A rogue PRE can spoof PANA messages on behalf of a victim PaC and
 receive the PAA response irrespective of the location of the PRE with
 respect to the network topology.  Achieving the same threat with non-
 relayed PANA requires the rogue node be an MitM, otherwise the
 spoofed packets may be dropped by the ingress filtering network
 elements, or the responses would be directly sent to the victim PaC
 IP address and may not be received by the rogue node.  Nevertheless,
 such a rogue PRE cannot perform full initial authentication on behalf
 of the victim PaC unless it also holds the PaC's credentials

Duffy, et al. Standards Track [Page 8] RFC 6345 PANA Relay Element August 2011

 (including the master key).  Furthermore, any spoofed PANA messages
 after the initial authentication will fail the integrity checks at
 the PAA when a key-generating EAP method is used.
 The only state that can change on the PAA upon a rogue PRE sending a
 spoofed PRY is the IP address and UDP port number of the PRE stored
 as PANA session attributes, which impacts where the PAA sends the
 next PANA packet (i.e., to the rogue PRE instead of the legitimate
 PRE).  The PAA also needs to handle the PaC-Information AVP in
 addition to the PaC-originated PANA message carried in the Relayed-
 Message AVP, so use of the PRE may impose additional storage
 requirements on the PAA.  A rogue PRE generating a valid PANA packet
 requires it be a MitM in order to synch up with the PANA session
 state and attributes on the PaC.  Such a MitM can already disturb the
 EAP and PANA even without playing the role of a PRE.
 An unauthorized node pretending as PAA can spoof the relayed PANA
 messages to the PRE in order to get them delivered to the PaC.  While
 the harm caused by such spoofed packets are limited (due to the EAP
 and PANA design with unsecured network operation in mind), the
 processing of bogus packets can cause processing load on the PaC.
 Some of the risks stemming from the aforementioned threats are
 already handled by the EAP and PANA as described.  The residual risks
 shall be mitigated using additional physical or cryptographic
 security in the network hosting the PREs and the PAAs.  Access
 control lists implemented on the PRE, PAA, or intermediary firewalls
 supported by cryptographic or physical authentication/authorization
 are needed for protecting legitimate PRE and PAAs against rogue ones.
 Details of the cryptographic mechanisms using IPsec are specified in
 Section 3.  Use of manually configured preshared keys for IPsec
 between PREs and PAAs does not defend against replayed PANA messages.
 PREs do not need to maintain per-PaC state; therefore, they are
 robust against resource consumption DoS (Denial-of-Service) attacks.
 In the relay operation, the IP address of the PAA that is seen by the
 PaC (i.e., an IP address of the PRE) is different from the IP address
 of the PAA that is seen by the authentication server.  If an EAP
 channel binding solution uses the IP address of the PAA as part of
 channel binding parameters, such a solution must take this into
 account.  Note that the same issue arises even when non-relayed PANA
 is used and the PAA has one IP address configured on its interface
 facing the PaC and another IP address on the other interface facing
 the authentication server.

Duffy, et al. Standards Track [Page 9] RFC 6345 PANA Relay Element August 2011

7. IANA Considerations

 As described in Sections 4 and 5, and following the new IANA
 allocation policy on PANA messages [RFC5872], one Message Type and
 two PANA AVP Codes have been assigned.
 o  A Message Type of 5 for PANA-Relay (PRY) message with the 'R'
    (Request) bit cleared.
 o  A standard AVP Code of 10 for PaC-Information AVP.
 o  A standard AVP Code of 11 for Relayed-Message AVP.

8. Acknowledgments

 The authors would like to thank Vlad Gherghisan, Shohei Watanabe,
 Richard Kelsey, Rafa Marin Lopez, Margaret Wasserman, Alan DeKok,
 Ralph Droms, Jari Arkko, Yoshifumi Nishida and Stephen Farrell for
 their valuable comments.

9. References

9.1. Normative References

 [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC4301]     Kent, S. and K. Seo, "Security Architecture for the
               Internet Protocol", RFC 4301, December 2005.
 [RFC5191]     Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and
               A. Yegin, "Protocol for Carrying Authentication for
               Network Access (PANA)", RFC 5191, May 2008.
 [RFC5192]     Morand, L., Yegin, A., Kumar, S., and S. Madanapalli,
               "DHCP Options for Protocol for Carrying Authentication
               for Network Access (PANA) Authentication Agents",
               RFC 5192, May 2008.
 [RFC5872]     Arkko, J. and A. Yegin, "IANA Rules for the Protocol
               for Carrying Authentication for Network Access (PANA)",
               RFC 5872, May 2010.

Duffy, et al. Standards Track [Page 10] RFC 6345 PANA Relay Element August 2011

9.2. Informative References

 [RFC4347]     Rescorla, E. and N. Modadugu, "Datagram Transport Layer
               Security", RFC 4347, April 2006.
 [RFC4944]     Montenegro, G., Kushalnagar, N., Hui, J., and D.
               Culler, "Transmission of IPv6 Packets over IEEE
               802.15.4 Networks", RFC 4944, September 2007.
 [6LoWPAN-ND]  Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor
               Discovery Optimization for Low Power and Lossy Networks
               (6LoWPAN)", Work in Progress, June 2011.
 [ZIGBEEIP]    ZigBee Alliance, "ZigBee IP Specification",
               ZigBee 095023r10, Work in Progress, July 2010.

Duffy, et al. Standards Track [Page 11] RFC 6345 PANA Relay Element August 2011

Authors' Addresses

 Paul Duffy
 Cisco Systems
 200 Beaver Brook Road
 Boxborough, MA 01719
 USA
 EMail: paduffy@cisco.com
 Samita Chakrabarti
 Ericsson
 300 Holger Way
 San Jose, CA 95135
 USA
 EMail: samita.chakrabarti@ericsson.com
 Robert Cragie
 Pacific Gas & Electric
 Gridmerge Ltd., 89 Greenfield Crescent
 Wakefield, WF4 4WA
 UK
 EMail: robert.cragie@gridmerge.com
 Yoshihiro Ohba (editor)
 Toshiba Corporate Research and Development Center
 1 Komukai-Toshiba-cho
 Saiwai-ku, Kawasaki, Kanagawa  212-8582
 Japan
 Phone: +81 44 549 2127
 EMail: yoshihiro.ohba@toshiba.co.jp
 Alper Yegin
 Samsung
 Istanbul
 Turkey
 EMail: a.yegin@partner.samsung.com

Duffy, et al. Standards Track [Page 12]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6345.txt · Last modified: 2011/08/17 05:24 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki