idnits 2.17.1 draft-ietf-dhc-agentopt-radius-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 7, 2003) is 7504 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: A later version (-05) exists of draft-ietf-dhc-auth-suboption-01 == Outdated reference: A later version (-02) exists of draft-ietf-dhc-relay-agent-ipsec-00 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Droms 3 Internet-Draft J. Schnizlein 4 Expires: April 6, 2004 Cisco Systems 5 October 7, 2003 7 RADIUS Attributes Sub-option for the DHCP Relay Agent Information 8 Option 9 draft-ietf-dhc-agentopt-radius-03.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 6, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 A network access device may choose to authenticate the identity of a 40 device before granting that device access to the network. The IEEE 41 802.1X protocol is an example of a mechanism for providing 42 authenticated layer 2 network access. A network element using RADIUS 43 as an authentication authority will receive attributes from a RADIUS 44 server that may be used by a DHCP server in the selection of an IP 45 address for assignment to the device through its DHCP client. The 46 RADIUS Attributes sub-option enables a network element to pass along 47 attributes for the user of a device received during RADIUS 48 authentication to a DHCP server. 50 1. Introduction and Background 52 The RADIUS Attributes sub-option for the DHCP Relay Agent option 53 provides a way through which network elements can pass information 54 obtained through layer 2 authentication to a DHCP server [2]. IEEE 55 802.1X [3] is an example of a mechanism through which a network 56 access device such as a switch or a wireless LAN access point can 57 authenticate the identity of the user of a device before providing 58 layer 2 network access using RADIUS [4] as the Authentication Service 59 specified in 802.1X. In 802.1X authenticated access, a device must 60 first exchange some authentication credentials with the network 61 access device. The access device then supplies these credentials to 62 a RADIUS server, which either confirms or denies the identity of the 63 user of the device requesting network access. The access device, 64 based on the reply of the RADIUS server, then allows or denies 65 network access to the requesting device. 67 Figure 1 summarizes the message exchange among the participants in 68 IEEE 802.1X authentication. 70 +-----------------+ 71 |Device requesting| 72 | network access | 73 +-----------------+ 74 | ^ 75 | | 76 (1) Request for access 77 | | 78 | (4) Access granted 79 v | 80 +-----------------+ 81 | Access Device | 82 |(802.1X and DHCP | 83 | relay agent} | 84 +-----------------+ 85 | ^ 86 | | 87 (2) Request for authentication 88 | | 89 | (3) Authentication confirm/deny 90 v | 91 +-----------------+ 92 | RADIUS | 93 | Service | 94 +-----------------+ 96 Figure 1 98 Figure 1 100 In the application described in this document, the access device acts 101 as an 802.1X authenticator and adds DHCP relay agent options to DHCP 102 messages. During 802.1X authentication, the reply message from the 103 RADIUS server carries additional identification information as 104 attributes to the access device. The access device stores these 105 attributes locally. When the access device subsequently forwards DHCP 106 messages from the network device, the access device adds the 107 identification information in an RADIUS Attributes sub-option. The 108 RADIUS Attributes sub-option is another suboption of the Relay Agent 109 Information option [5]. 111 This document uses IEEE 802.1X as an example to motivate the use of 112 RADIUS by an access device. The RADIUS Attributes sub-option 113 described in this document is not limited to use in conjunction with 114 IEEE 802.1X and can be used to carry RADIUS attributes obtained by 115 the relay agent for any reason. 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [1]. 123 2.1 General Terminology 125 Access device: A network element providing network access to a host 127 2.2 DHCP Terminology 129 The following terms are used as defined in RFC2131 and RFC3046: DHCP 130 relay agent, DHCP server, DHCP client. 132 2.3 RADIUS Terminology 134 The following terms are used in conjunction with RADIUS: 136 RADIUS server: An entity that provides 137 RADIUS service through the exchange of RADIUS protocol messages 139 Attribute: Data value carried in a RADIUS protocol message 141 2.4 802.1X Terminology 143 The following terms are used as defined in the IEEE 802.1X protocol: 144 Authenticator, Supplicant. 146 3. RADIUS Attributes sub-option format 148 The RADIUS Attributes Sub-option is a new sub-option for the DHCP 149 Relay Agent option. 151 The format of the RADIUS Attributes sub-option is: 153 SubOpt Len RADIUS attributes 154 code 155 +-------+-----+------+------+------+------+--...-+------+ 156 | TBD | N | b1 | b2 | b3 | b4 | | bN | 157 +-------+-----+------+------+------+------+--...-+------+ 159 The RADIUS attributes are encoded according to the encoding rules in 160 RFC 2865, in bytes b1...bN. 162 4. DHCP Relay Agent Behavior 164 When the DHCP relay agent receives a DHCP message from the client, it 165 MAY append a DHCP Relay Agent Information option containing the 166 RADIUS Attributes sub-option, along with any other sub-options it is 167 configured to supply. The RADIUS Attributes sub-option MUST contain 168 the attributes received in response to the client's authentication 169 with the RADIUS service. The DHCP relay agent MUST NOT add more than 170 one RADIUS Attributes sub-option in a message. 172 The relay agent SHOULD include the User-Name and Class attributes in 173 the RADIUS Attributes sub-option, and MAY include other attributes. 175 5. DHCP Server Behavior 177 When the DHCP server receives a message from an relay agent 178 containing a RADIUS Attributes sub-option, it extracts the contents 179 of the of the sub-option and uses that information in selecting 180 configuration parameters for the client. 182 6. DHCP Client Behavior 184 The host need not make any special provision for the use of the 185 RADIUS Attributes sub-option. 187 7. RADIUS Server Behavior 188 The RADIUS server MUST return the User-Name and Class attributes to 189 the access device, and MAY return other attributes. 191 8. Security Considerations 193 Message authentication in DHCP for intradomain use where the 194 out-of-band exchange of a shared secret is feasible is defined in RFC 195 3118 [6]. Potential exposures to attack are discussed in section 7 196 of the DHCP protocol specification in RFC 2131. 198 The DHCP Relay Agent option depends on a trusted relationship between 199 the DHCP relay agent and the server, as described in section 5 of RFC 200 3046. While the introduction of fraudulent relay-agent options can 201 be prevented by a perimeter defense that blocks these options unless 202 the relay agent is trusted, a deeper defense using the authentication 203 option for relay agent options [7] or IPsec [8] SHOULD be deployed as 204 well. 206 9. IANA Considerations 208 IANA has assigned the value of TBD for the DHCP Relay Agent 209 Information option sub-option code for this sub-option. This 210 document does not define any new namespaces or other constants for 211 which IANA must maintain a registry. 213 10. Terms of Use 215 Cisco has a pending patent which relates to the subject matter of 216 this Internet Draft. If a standard relating to this subject matter is 217 adopted by IETF and any claims of any issued Cisco patents are 218 necessary for practicing this standard, any party will be able to 219 obtain a license from Cisco to use any such patent claims under 220 openly specified, reasonable, non-discriminatory terms to implement 221 and fully comply with the standard. 223 Normative References 225 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 226 Levels", BCP 14, RFC 2119, March 1997. 228 [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 229 March 1997. 231 [3] Institute of Electrical and Electronics Engineers, "Port based 232 Network Access Control", IEEE Standard 802.1X, March 2001. 234 [4] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 235 Authentication Dial In User Service (RADIUS)", RFC 2865, June 236 2000. 238 [5] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, 239 January 2001. 241 Informative References 243 [6] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 244 RFC 3118, June 2001. 246 [7] Stapp, M., Lemon, T. and R. Droms, "The Authentication Suboption 247 for the DHCP Relay Agent Option", 248 draft-ietf-dhc-auth-suboption-01 (work in progress), November 249 2002. 251 [8] Droms, R., "Authentication of DHCP Relay Agent Options Using 252 IPsec", draft-ietf-dhc-relay-agent-ipsec-00 (work in progress), 253 September 2003. 255 Authors' Addresses 257 Ralph Droms 258 Cisco Systems 259 250 Apollo Drive 260 Chelmsford, MA 01824 261 USA 263 EMail: rdroms@cisco.com 265 John Schnizlein 266 Cisco Systems 267 9123 Loughran Road 268 Fort Washington, MD 20744 269 USA 271 EMail: jschnizl@cisco.com 273 Intellectual Property Statement 275 The IETF takes no position regarding the validity or scope of any 276 intellectual property or other rights that might be claimed to 277 pertain to the implementation or use of the technology described in 278 this document or the extent to which any license under such rights 279 might or might not be available; neither does it represent that it 280 has made any effort to identify any such rights. Information on the 281 IETF's procedures with respect to rights in standards-track and 282 standards-related documentation can be found in BCP-11. Copies of 283 claims of rights made available for publication and any assurances of 284 licenses to be made available, or the result of an attempt made to 285 obtain a general license or permission for the use of such 286 proprietary rights by implementors or users of this specification can 287 be obtained from the IETF Secretariat. 289 The IETF invites any interested party to bring to its attention any 290 copyrights, patents or patent applications, or other proprietary 291 rights which may cover technology that may be required to practice 292 this standard. Please address the information to the IETF Executive 293 Director. 295 Full Copyright Statement 297 Copyright (C) The Internet Society (2003). All Rights Reserved. 299 This document and translations of it may be copied and furnished to 300 others, and derivative works that comment on or otherwise explain it 301 or assist in its implementation may be prepared, copied, published 302 and distributed, in whole or in part, without restriction of any 303 kind, provided that the above copyright notice and this paragraph are 304 included on all such copies and derivative works. However, this 305 document itself may not be modified in any way, such as by removing 306 the copyright notice or references to the Internet Society or other 307 Internet organizations, except as needed for the purpose of 308 developing Internet standards in which case the procedures for 309 copyrights defined in the Internet Standards process must be 310 followed, or as required to translate it into languages other than 311 English. 313 The limited permissions granted above are perpetual and will not be 314 revoked by the Internet Society or its successors or assignees. 316 This document and the information contained herein is provided on an 317 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 318 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 319 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 320 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 321 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 323 Acknowledgment 325 Funding for the RFC Editor function is currently provided by the 326 Internet Society.