doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc4014.txt b/doc/rfc/rfc4014.txt
new file mode 100644
index 0000000..eed3095
--- /dev/null
+++ b/doc/rfc/rfc4014.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                           R. Droms
+Request for Comments: 4014                                 J. Schnizlein
+Category: Standards Track                                  Cisco Systems
+                                                           February 2005
+
+
+          Remote Authentication Dial-In User Service (RADIUS)
+                     Attributes Suboption for the
+              Dynamic Host Configuration Protocol (DHCP)
+                     Relay Agent Information Option
+
+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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   The RADIUS Attributes suboption enables a network element to pass
+   identification and authorization attributes received during RADIUS
+   authentication to a DHCP server.  When the DHCP server receives a
+   message from a relay agent containing a RADIUS Attributes suboption,
+   it extracts the contents of the suboption and uses that information
+   in selecting configuration parameters for the client.
+
+1.  Introduction and Background
+
+   The RADIUS Attributes suboption for the DHCP Relay Agent option
+   provides a way in which a NAS can pass attributes obtained from a
+   RADIUS server to a DHCP server [1].  IEEE 802.1X [2] is an example of
+   a mechanism through which a NAS such as a switch or a wireless LAN
+   access point can authenticate the identity of the user of a device
+   before providing layer 2 network access with RADIUS as the
+   Authentication Service, as specified in RFC 3580 [8].  In IEEE 802.1X
+   authenticated access, a device must first exchange some
+   authentication credentials with the NAS.  The NAS then supplies these
+   credentials to a RADIUS server, which eventually sends either an
+   Access-Accept or an Access-Reject in response to an Access-Request.
+   The NAS, based on the reply of the RADIUS server, then allows or
+   denies network access to the requesting device.
+
+
+
+
+Droms & Schnizlein          Standards Track                     [Page 1]
+
+RFC 4014              RADIUS Attributes Suboption          February 2005
+
+
+   Figure 1 summarizes the message exchange among the participants in
+   IEEE 802.1X authentication.
+
+                        +-----------------+
+                        |Device requesting|
+                        | network access  |
+                        +-----------------+
+                         |         ^
+                         |         |
+                        (1) Request for access
+                         |         |
+                         |        (4) Success/Failure
+                         v         |
+                        +-----------------+
+                        |       NAS       |
+                        |(IEEE 802.1X and |
+                        |DHCP relay agent}|
+                        +-----------------+
+                           |     ^
+                           |     |
+                          (2) Request for authentication
+                           |     |
+                           |    (3) Access-Accept/Reject
+                           v     |
+                        +-----------------+
+                        |     RADIUS      |
+                        |     Server      |
+                        +-----------------+
+
+                             Figure 1
+
+   The access device acts as an IEEE 802.1X Authenticator and adds a
+   DHCP relay agent option that includes a RADIUS Attributes suboption
+   to DHCP messages.  At the successful conclusion of IEEE 802.1X
+   authentication, a RADIUS Access-Accept provides attributes for
+   service authorizations to the NAS.  The NAS stores these attributes
+   locally.  When the NAS subsequently relays DHCP messages from the
+   network device, the NAS adds these attributes in a RADIUS Attributes
+   suboption.  The RADIUS Attributes suboption is another suboption of
+   the Relay Agent Information option [5].
+
+   The RADIUS Attributes suboption described in this document is not
+   limited to use in conjunction with IEEE 802.1X and can be used to
+   carry RADIUS attributes obtained by the relay agent for any reason.
+   That is, the option is not limited to use with IEEE 802.1X but is
+   constrained by RADIUS semantics (see Section 4).
+
+
+
+
+
+Droms & Schnizlein          Standards Track                     [Page 2]
+
+RFC 4014              RADIUS Attributes Suboption          February 2005
+
+
+   The scope of applicability of this specification is such that robust
+   interoperability is only guaranteed for RADIUS service
+   implementations that exist within the same scope as does the DHCP
+   service implementation, i.e., within a single, localized
+   administrative domain.  Global interoperability of this
+   specification, across administrative domains, is not required.
+
+2.  Terminology
+
+   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 RFC 2119 [3].
+
+   Within this specification, the use of the key words "MUST", "MUST
+   NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
+   "RECOMMENDED", "MAY", and "OPTIONAL" is with respect to RADIUS
+   clients and servers that implement the optional features of this
+   specification.  The use of these key words does not create any
+   normative requirements outside of that scope, and does not modify the
+   base RADIUS specifications, such as RFC 2865 [4].
+
+2.1.  DHCP Terminology
+
+   The following terms are used as defined in RFC 2131 and RFC 3046:
+   DHCP relay agent, DHCP server, DHCP client.
+
+2.2.  RADIUS Terminology
+
+   The following terms are used in conjunction with RADIUS:
+
+   RADIUS server: A RADIUS server is responsible for receiving user
+      connection requests, authenticating the user, and then returning
+      all configuration information necessary for the client to deliver
+      service to the user.
+
+   Attribute: A Type-Length-Value tuple encapsulating data elements as
+      defined in RFC 2865 [4].
+
+   NAS:  A Network Access Server (NAS) provides access to the network
+      and operates as a client of RADIUS.  The client is responsible for
+      passing user information to designated RADIUS servers and then
+      acting on the response that is returned.  Unlike a traditional
+      dial NAS, the NAS considered here may not have a protocol such as
+      PPP through which it can pass configuration information from the
+      RADIUS attributes to the client.
+
+
+
+
+
+
+Droms & Schnizlein          Standards Track                     [Page 3]
+
+RFC 4014              RADIUS Attributes Suboption          February 2005
+
+
+2.3.  IEEE 802.1X Terminology
+
+   The following terms are used as defined in the IEEE 802.1X protocol:
+   Authenticator, Supplicant.
+
+3.  RADIUS Attributes Suboption Format
+
+   The RADIUS Attributes suboption is a new suboption for the DHCP Relay
+   Agent option.
+
+   The format of the RADIUS Attributes suboption is as follows:
+
+        SubOpt   Len     RADIUS attributes
+         code
+       +-------+-----+------+------+------+------+--...-+------+
+       |   7   |  N  |  o1  |  o2  |  o3  |  o4  |      |  oN  |
+       +-------+-----+------+------+------+------+--...-+------+
+
+   The RADIUS attributes are encoded according to the encoding rules in
+   RFC 2865, in octets o1...oN.
+
+   The DHCP relay agent truncates the RADIUS attributes to fit in the
+   RADIUS Attributes suboption.
+
+4.  DHCP Relay Agent Behavior
+
+   When the DHCP relay agent receives a DHCP message from the client, it
+   MAY append a DHCP Relay Agent Information option containing the
+   RADIUS Attributes suboption, along with any other suboptions it is
+   configured to supply.  The RADIUS Attributes suboption MUST only
+   contain the attributes provided in the RADIUS Access/Accept message.
+   The DHCP relay agent MUST NOT add more than one RADIUS Attributes
+   suboption in a message.
+
+   The relay agent MUST include the User-Name and Framed-Pool attributes
+   in the RADIUS Attributes suboption, if they are available, and MAY
+   include other attributes.
+
+   To avoid dependencies between the address allocation and other state
+   information between the RADIUS server and the DHCP server, the DHCP
+   relay agent SHOULD include only the attributes in the table below in
+   an instance of the RADIUS Attributes suboption.  The table, based on
+   the analysis in RFC 3580 [8], lists attributes that MAY be included:
+
+
+
+
+
+
+
+
+Droms & Schnizlein          Standards Track                     [Page 4]
+
+RFC 4014              RADIUS Attributes Suboption          February 2005
+
+
+           #   Attribute
+         ---   ---------
+           1   User-Name (RFC 2865 [3])
+           6   Service-Type (RFC 2865)
+          26   Vendor-Specific (RFC 2865)
+          27   Session-Timeout (RFC 2865)
+          88   Framed-Pool (RFC 2869)
+         100   Framed-IPv6-Pool (RFC 3162 [7])
+
+5.  DHCP Server Behavior
+
+   When the DHCP server receives a message from a relay agent containing
+   a RADIUS Attributes suboption, it extracts the contents of the
+   suboption and uses that information in selecting configuration
+   parameters for the client.  If the relay agent relays RADIUS
+   attributes not included in the table in Section 4, the DHCP server
+   SHOULD ignore them.  If the DHCP server uses attributes not specified
+   here, it might result in side effects not anticipated in the existing
+   RADIUS specifications.
+
+6.  DHCP Client Behavior
+
+   Relay agent options are exchanged only between relay agents and the
+   DHCP server, so DHCP clients are never aware of their use.
+
+7.  Security Considerations
+
+   Message authentication in DHCP for intradomain use where the
+   out-of-band exchange of a shared secret is feasible is defined in RFC
+   3118 [6].  Potential exposures to attack are discussed in section 7
+   of the DHCP protocol specification in RFC 2131 [1].
+
+   The DHCP Relay Agent option depends on a trusted relationship between
+   the DHCP relay agent and the server, as described in section 5 of RFC
+   3046 [5].  Although the introduction of fraudulent relay-agent
+   options can be prevented by a perimeter defense that blocks these
+   options unless the relay agent is trusted, a deeper defense using the
+   authentication option for relay agent options [9] or IPsec [10]
+   SHOULD be deployed as well.
+
+8.  IANA Considerations
+
+   IANA has assigned the value of 7 for the DHCP Relay Agent Information
+   option suboption code for this suboption.  This document does not
+   define any new namespaces or other constants for which IANA must
+   maintain a registry.
+
+
+
+
+
+Droms & Schnizlein          Standards Track                     [Page 5]
+
+RFC 4014              RADIUS Attributes Suboption          February 2005
+
+
+9.  Acknowledgements
+
+   Expert advice from Bernard Aboba, Paul Funk, David Nelson, Ashwin
+   Palekar, and Greg Weber on avoiding RADIUS entanglements is
+   gratefully acknowledged.
+
+10.  References
+
+10.1.  Normative References
+
+   [1]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+        March 1997.
+
+   [2]  Institute of Electrical and Electronics Engineers, "Local and
+        Metropolitan Area Networks: Port based Network Access Control",
+        IEEE Standard 802.1X, March 2001.
+
+   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [4]  Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
+        Authentication Dial In User Service (RADIUS)", RFC 2865, June
+        2000.
+
+   [5]  Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
+        January 2001.
+
+10.2.  Informative References
+
+   [6]  Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
+        RFC 3118, June 2001.
+
+   [7]  Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162,
+        August 2001.
+
+   [8]  Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE
+        802.1X Remote Authentication Dial In User Service (RADIUS) Usage
+        Guidelines", RFC 3580, September 2003.
+
+   [9]  Stapp, M. and T. Lemon, "The Authentication Suboption for the
+        DHCP Relay Agent Option", Work in Progress, October 2003.
+
+   [10] Droms, R., "Authentication of DHCP Relay Agent Options Using
+        IPsec", Work in Progress, September 2003.
+
+
+
+
+
+
+
+Droms & Schnizlein          Standards Track                     [Page 6]
+
+RFC 4014              RADIUS Attributes Suboption          February 2005
+
+
+Authors' Addresses
+
+   Ralph Droms
+   Cisco Systems
+   1414 Massachusetts Avenue
+   Boxborough, MA  01719
+   USA
+
+   EMail: rdroms@cisco.com
+
+
+   John Schnizlein
+   Cisco Systems
+   9123 Loughran Road
+   Fort Washington, MD  20744
+   USA
+
+   EMail: jschnizl@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms & Schnizlein          Standards Track                     [Page 7]
+
+RFC 4014              RADIUS Attributes Suboption          February 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   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 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 IETF's procedures with respect to rights in IETF 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.
+
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+Droms & Schnizlein          Standards Track                     [Page 8]
+