summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5192.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5192.txt')
-rw-r--r--doc/rfc/rfc5192.txt451
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]
+