doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc5192.txt b/doc/rfc/rfc5192.txt
new file mode 100644
index 0000000..7ed6c37
--- /dev/null
+++ b/doc/rfc/rfc5192.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                          L. Morand
+Request for Comments: 5192                            France Telecom R&D
+Category: Standards Track                                       A. Yegin
+                                                                 Samsung
+                                                                S. Kumar
+                                                       Tech Mahindra Ltd
+                                                          S. Madanapalli
+                                                                 Samsung
+                                                                May 2008
+
+
+       DHCP Options for Protocol for Carrying Authentication for
+              Network Access (PANA) Authentication Agents
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This document defines new DHCPv4 and DHCPv6 options that contain a
+   list of IP addresses to locate one or more PANA (Protocol for
+   carrying Authentication for Network Access) Authentication Agents
+   (PAAs).  This is one of the methods that a PANA Client (PaC) can use
+   to locate PAAs.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   2.  Specification of Requirements . . . . . . . . . . . . . . . . . 2
+   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   4.  PANA Authentication Agent DHCPv4 Option . . . . . . . . . . . . 3
+   5.  PANA Authentication Agent DHCPv6 Option . . . . . . . . . . . . 4
+   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
+   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
+   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
+     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
+
+
+
+
+
+
+
+
+Morand, et al.              Standards Track                     [Page 1]
+
+RFC 5192                    PAA DHCP Options                    May 2008
+
+
+1.  Introduction
+
+   The Protocol for carrying Authentication for Network Access (PANA)
+   [RFC5191] defines a new Extensible Authentication Protocol (EAP)
+   [RFC3748] lower layer that uses IP between the protocol end-points.
+
+   The PANA protocol is run between a PANA Client (PaC) and a PANA
+   Authentication Agent (PAA) in order to perform authentication and
+   authorization for the network access service.
+
+   This document specifies DHCPv4 [RFC2131] and DHCPv6 [RFC3315] options
+   that allow PANA clients (PaCs) to discover PANA Authentication Agents
+   (PAAs).  This is one of the methods for locating PAAs.
+
+   The DHCP options defined in this document are used only as a PAA
+   discovery mechanism.  These DHCP options MUST NOT be used to perform
+   any negotiation of the use of PANA between the PaC and a PAA.
+
+2.  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].
+
+3.  Terminology
+
+   This document uses the DHCP terminology defined in [RFC2131],
+   [RFC2132], and [RFC3315].
+
+   This document uses the PANA terminology defined in [RFC5191].  In
+   particular, the following terms are defined:
+
+      PANA Client (PaC):
+
+         The client side of the protocol that resides in the access
+         device (e.g., laptop, PDA, etc.).  It is responsible for
+         providing the credentials in order to prove its identity
+         (authentication) for network access authorization.  The PaC and
+         the EAP peer are co-located in the same access device.
+
+      PANA Authentication Agent (PAA):
+
+         The protocol entity in the access network whose responsibility
+         it is to verify the credentials provided by a PANA client (PaC)
+         and authorize network access to the access device.  The PAA and
+
+
+
+
+Morand, et al.              Standards Track                     [Page 2]
+
+RFC 5192                    PAA DHCP Options                    May 2008
+
+
+         the EAP authenticator (and optionally the EAP server) are
+         colocated in the same node.
+
+4.  PANA Authentication Agent DHCPv4 Option
+
+   This DHCPv4 option carries a list of 32-bit (binary) IPv4 addresses
+   indicating PANA Authentication Agents (PAAs) available to the PANA
+   client (PaC).
+
+   The DHCPv4 option for PANA Authentication Agent has the format shown
+   in Figure 1.
+
+      0                   1
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  option-code  | option-length |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                               |
+      +      PAA IPv4 Address         +
+      |                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |             ...               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+         Figure 1: PAA DHCPv4 option
+
+      option-code:        OPTION_PANA_AGENT (136).
+
+      option-length:      Length of the 'options' field in octets;
+                          MUST be a multiple of four (4).
+
+      PAA IPv4 Address:   IPv4 address of a PAA for the client to use.
+                          The PAAs are listed in the order of preference
+                          for use by the client.
+
+
+   A PaC (DHCPv4 client) SHOULD request the PAA DHCPv4 Option in a
+   Parameter Request List, as described in [RFC2131] and [RFC2132].
+
+   If configured with a (list of) PAA address(es), a DHCPv4 server
+   SHOULD send a client the PAA DHCPv4 option, even if this option is
+   not explicitly requested by the client.
+
+   A PaC (DHCPv4 client) receiving the PAA DHCPv4 option SHOULD use the
+   (list of) IP address(es) to locate PAA(s).
+
+   The PaC (DHCPv4 client) MUST try the records in the order listed in
+   the PAA DHCPv4 option received from the DHCPv4 server.
+
+
+
+
+Morand, et al.              Standards Track                     [Page 3]
+
+RFC 5192                    PAA DHCP Options                    May 2008
+
+
+5.  PANA Authentication Agent DHCPv6 Option
+
+   This DHCPv6 option carries a list of 128-bit (binary) IPv6 addresses
+   indicating PANA Authentication Agents (PAAs) available to the PANA
+   client (PaC).
+
+   The DHCPv6 option for PANA Authentication Agent has the format shown
+   in Figure 2.
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |       option-code             |       option-length           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      +                                                               +
+      |                                                               |
+      +                         PAA IPv6 Address                      +
+      |                                                               |
+      +                                                               +
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          ....                                 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                        Figure 2: PAA DHCPv6 option
+
+      option-code:        OPTION_PANA_AGENT (40).
+
+      option-length:      Length of the 'options' field in octets;
+                          MUST be a multiple of sixteen (16).
+
+      PAA IPv6 Address:   IPv6 address of a PAA for the client to use.
+                          The PAAs are listed in the order of preference
+                          for use by the client.
+
+   A PaC DHCPv6 client SHOULD request the PAA DHCPv6 option in an
+   Options Request Option (ORO) as described in the DHCPv6 specification
+   [RFC3315].
+
+   If configured with a (list of) PAA address(es), a DHCPv6 server
+   SHOULD send a client the PAA DHCPv6 option, even if this option is
+   not explicitly requested by the client.
+
+   A PaC (DHCPv6 client) receiving the PAA DHCPv6 option SHOULD use the
+   (list of) IP address(es) to locate PAA(s).
+
+   The PaC (DHCPv6 client) MUST try the records in the order listed in
+   the PAA DHCPv6 option received from the DHCPv6 server.
+
+
+
+Morand, et al.              Standards Track                     [Page 4]
+
+RFC 5192                    PAA DHCP Options                    May 2008
+
+
+6.  IANA Considerations
+
+   The following DHCPv4 option code for PANA Authentication Agent
+   options has been assigned by IANA:
+
+      Option  Name           Value       Described in
+      -----------------------------------------------
+      OPTION_PANA_AGENT       136         Section 4
+
+   The following DHCPv6 option code for PANA Authentication Agent
+   options has been assigned by IANA:
+
+      Option  Name            Value       Described in
+      ------------------------------------------------
+      OPTION_PANA_AGENT        40         Section 5
+
+7.  Security Considerations
+
+   The security considerations in [RFC2131], [RFC2132], and [RFC3315]
+   apply.  If an adversary manages to modify the response from a DHCP
+   server or insert its own response, a PANA Client could be led to
+   contact a rogue PANA Authentication Agent, possibly one that then
+   intercepts authentication requests and/or denies network access to
+   the access device.
+
+   In most networks, the DHCP exchange that delivers the options prior
+   to network access authentication is neither integrity protected nor
+   origin authenticated.  Therefore, the options defined in this
+   document MUST NOT be used to perform any negotiation on the use of
+   PANA between the PANA Client and a PANA Authentication Agent.  Using
+   the presence (or absence) of these DHCP options as an indication of
+   network mandating PANA authentication (or not) is an example of such
+   a negotiation mechanism.  This negotiation would allow bidding-down
+   attacks by making the clients choose to use a lower-grade security
+   mechanism (or even no security at all).
+
+8.  Acknowledgements
+
+   We would like to thank Ralph Droms, Stig Venaas, Ted Lemon, Andre
+   Kostur and Bernie Volz for their valuable comments.  We would also
+   like to thank Jari Arkko, Thomas Narten and Bernard Aboba that
+   provided several reviews, as well as all members of the PANA and DHC
+   working groups that contribute to improve this document.
+
+
+
+
+
+
+
+
+Morand, et al.              Standards Track                     [Page 5]
+
+RFC 5192                    PAA DHCP Options                    May 2008
+
+
+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.
+
+   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
+              RFC 2131, March 1997.
+
+   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
+              Extensions", RFC 2132, March 1997.
+
+   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
+              and M. Carney, "Dynamic Host Configuration Protocol for
+              IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+   [RFC5191]  Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
+              Yegin, "Protocol for Carrying Authentication for Network
+              Access (PANA)", RFC 5191, May 2008.
+
+9.2.  Informative References
+
+   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
+              Levkowetz, "Extensible Authentication Protocol (EAP)",
+              RFC 3748, June 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Morand, et al.              Standards Track                     [Page 6]
+
+RFC 5192                    PAA DHCP Options                    May 2008
+
+
+Authors' Addresses
+
+   Lionel Morand
+   France Telecom R&D
+
+   EMail: lionel.morand@orange-ftgroup.com
+
+
+   Alper E. Yegin
+   Samsung
+
+   EMail: a.yegin@partner.samsung.com
+
+
+   Suraj Kumar
+   Tech Mahindra Ltd
+
+   EMail: surajk@techmahindra.com
+
+
+   Syam Madanapalli
+   Samsung
+
+   EMail: syam@samsung.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Morand, et al.              Standards Track                     [Page 7]
+
+RFC 5192                    PAA DHCP Options                    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.
+
+
+
+
+
+
+
+
+
+
+
+
+Morand, et al.              Standards Track                     [Page 8]
+