doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc6345.txt b/doc/rfc/rfc6345.txt
new file mode 100644
index 0000000..53ddc54
--- /dev/null
+++ b/doc/rfc/rfc6345.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+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]
+