From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5192.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc5192.txt (limited to 'doc/rfc/rfc5192.txt') 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] + -- cgit v1.2.3