idnits 2.17.1 draft-ietf-dhc-agentopt-radius-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 354. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 333. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 339. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 360), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 : ---------------------------------------------------------------------------- No issues found here. 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 (August 18, 2004) is 7189 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '6' is defined on line 276, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 278, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 284, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-05) exists of draft-ietf-dhc-auth-suboption-02 == Outdated reference: A later version (-02) exists of draft-ietf-dhc-relay-agent-ipsec-00 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Droms 2 Internet-Draft J. Schnizlein 3 Expires: February 16, 2005 Cisco Systems 4 August 18, 2004 6 RADIUS Attributes Sub-option for the DHCP Relay Agent Information 7 Option 8 draft-ietf-dhc-agentopt-radius-08.txt 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3667. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on February 16, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 A NAS (network access server) may choose to authenticate the identity 41 of a device before granting that device access to the network. The 42 IEEE 802.1X protocol is an example of a mechanism for providing 43 authenticated layer 2 network access. A network element using RADIUS 44 as an authentication authority will receive attributes from a RADIUS 45 server that may be used by a DHCP server in the selection of 46 configuration parameters to be delivered to the device through its 47 DHCP client. The RADIUS Attributes sub-option enables a network 48 element to pass along attributes for the user of a device received 49 during RADIUS authentication to a DHCP server. 51 1. Introduction and Background 53 The RADIUS Attributes sub-option for the DHCP Relay Agent option 54 provides a way in which a NAS can pass attributes obtained from a 55 RADIUS server to a DHCP server [1]. IEEE 802.1X [2] is an example of 56 a mechanism through which a NAS such as a switch or a wireless LAN 57 access point can authenticate the identity of the user of a device 58 before providing layer 2 network access using RADIUS as the 59 Authentication Service specified in RFC3580 [10]. In IEEE 802.1X 60 authenticated access, a device must first exchange some 61 authentication credentials with the NAS. The NAS then supplies these 62 credentials to a RADIUS server, which eventually sends either an 63 Access-Accept or an Access-Reject in response to an Access-Request. 64 The NAS, based on the reply of the RADIUS server, then allows or 65 denies 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) Success/Failure 79 v | 80 +-----------------+ 81 | NAS | 82 |(IEEE 802.1X and | 83 |DHCP relay agent}| 84 +-----------------+ 85 | ^ 86 | | 87 (2) Request for authentication 88 | | 89 | (3) Access-Accept/Reject 90 v | 91 +-----------------+ 92 | RADIUS | 93 | Server | 94 +-----------------+ 95 Figure 1 97 In the application described in this document, the access device acts 98 as an IEEE 802.1X Authenticator and adds a DHCP relay agent option 99 which includes a RADIUS Attributes sub-option to DHCP messages. At 100 the successful conclusion of IEEE 802.1X authentication, a RADIUS 101 Access-Accept provides attributes for service authorizations to the 102 NAS. The NAS stores these attributes locally. When the NAS 103 subsequently forwards DHCP messages from the network device, the NAS 104 adds these attributes in a RADIUS Attributes sub-option. The RADIUS 105 Attributes sub-option is another suboption of the Relay Agent 106 Information option [5]. 108 This document uses IEEE 802.1X as an example to motivate the use of 109 RADIUS by a NAS. The RADIUS Attributes sub-option described in this 110 document is not limited to use in conjunction with IEEE 802.1X and 111 can be used to carry RADIUS attributes obtained by the relay agent 112 for any reason. That is, the option is not limited to use with IEEE 113 802.1X, but is constrained by RADIUS semantics (see Section 4). 115 The scope of applicability of this specification is such that robust 116 interoperability is only guaranteed for RADIUS service 117 implementations that exist within the same scope as the DHCP service 118 implementation, i.e. within a single, localized administrative 119 domain. Global interoperability of this specification, across 120 administrative domains, is not required. 122 2. Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [3]. 128 The use of the standard keywords MUST, SHOULD, MUST NOT and SHOULD 129 NOT within this specification are with respect to RADIUS clients and 130 servers that implement the optional features of this specification, 131 do not create any normative requirements outside of that scope and do 132 not modify the base RADIUS specifications, such as RFC2865 or 133 RFC2866. 135 2.1 DHCP Terminology 137 The following terms are used as defined in RFC2131 and RFC3046: DHCP 138 relay agent, DHCP server, DHCP client. 140 2.2 RADIUS Terminology 142 The following terms are used in conjunction with RADIUS: 144 RADIUS server: A RADIUS server is responsible for receiving user 145 connection requests, authenticating the user, and then returning 146 all configuration information necessary for the client to deliver 147 service to the user. 148 Attribute: A Type-Length-Value tuple encapsulating data elements as 149 defined in RFC 2865 [4]. 150 NAS: A Network Access Server (NAS) provides access to the network 151 and operates as a client of RADIUS. The client is responsible for 152 passing user information to designated RADIUS servers, and then 153 acting on the response which is returned. Unlike a traditional 154 dial NAS, the NAS considered here may not have a protocol like PPP 155 through which it can pass configuration information from the 156 RADIUS attributes to the client 158 2.3 IEEE 802.1X Terminology 160 The following terms are used as defined in the IEEE 802.1X protocol: 161 Authenticator, Supplicant. 163 3. RADIUS Attributes sub-option format 165 The RADIUS Attributes Sub-option is a new sub-option for the DHCP 166 Relay Agent option. 168 The format of the RADIUS Attributes sub-option is: 170 SubOpt Len RADIUS attributes 171 code 172 +-------+-----+------+------+------+------+--...-+------+ 173 | TBD | N | o1 | o2 | o3 | o4 | | oN | 174 +-------+-----+------+------+------+------+--...-+------+ 176 The RADIUS attributes are encoded according to the encoding rules in 177 RFC 2865, in octets o1...oN. 179 The DHCP relay agent truncates the RADIUS attributes to fit in the 180 RADIUS Attributes sub-option. 182 4. DHCP Relay Agent Behavior 184 When the DHCP relay agent receives a DHCP message from the client, it 185 MAY append a DHCP Relay Agent Information option containing the 186 RADIUS Attributes sub-option, along with any other sub-options it is 187 configured to supply. The RADIUS Attributes sub-option MUST only 188 contain the attributes provided in the RADIUS Access/Accept message. 189 The DHCP relay agent MUST NOT add more than one RADIUS Attributes 190 sub-option in a message. 192 The relay agent MUST include the User-Name and Framed-Pool attributes 193 in the RADIUS Attributes sub-option if available, and MAY include 194 other attributes. 196 To avoid dependencies between the address allocation and other state 197 information between the RADIUS server and the DHCP server, the DHCP 198 relay agent SHOULD include only the attributes in the table below an 199 instance of the RADIUS Attributes sub-option. The table, based on 200 the analysis in RFC 3580 [10], lists attributes that MAY be included: 202 # Attribute 203 --- --------- 204 1 User-Name (RFC 2865 [3]) 205 6 Service-Type (RFC 2865) 206 26 Vendor-Specific (RFC 2865) 207 27 Session-Timeout (RFC 2865) 208 88 Framed-Pool (RFC 2869) 209 100 Framed-IPv6-Pool (RFC 3162 [8]) 211 5. DHCP Server Behavior 213 When the DHCP server receives a message from a relay agent containing 214 a RADIUS Attributes sub-option, it extracts the contents of the 215 sub-option and uses that information in selecting configuration 216 parameters for the client. If the relay agent forwards RADIUS 217 attributes not included in the table in Section 4, the DHCP server 218 SHOULD ignore them. If the DHCP server uses attributes not specified 219 here, it might result in side effects not anticipated in the existing 220 RADIUS specifications. 222 6. DHCP Client Behavior 224 Relay agent options are exchanged only between relay agents and DHCP 225 server, so DHCP clients are never aware of their use. 227 7. Security Considerations 229 Message authentication in DHCP for intradomain use where the 230 out-of-band exchange of a shared secret is feasible is defined in RFC 231 3118 [8]. Potential exposures to attack are discussed in section 7 232 of the DHCP protocol specification in RFC 2131 [1]. 234 The DHCP Relay Agent option depends on a trusted relationship between 235 the DHCP relay agent and the server, as described in section 5 of RFC 236 3046 [5]. While the introduction of fraudulent relay-agent options 237 can be prevented by a perimeter defense that blocks these options 238 unless the relay agent is trusted, a deeper defense using the 239 authentication option for relay agent options [11] or IPsec [12] 240 SHOULD be deployed as well. 242 8. IANA Considerations 244 IANA has assigned the value of TBD for the DHCP Relay Agent 245 Information option sub-option code for this sub-option. This 246 document does not define any new namespaces or other constants for 247 which IANA must maintain a registry. 249 9. Acknowledgments 251 Expert advice from Bernard Aboba, Paul Funk, David Nelson, Ashwin 252 Palekar and Greg Weber on avoiding RADIUS entanglements is gratefully 253 acknowledged. 255 Normative References 257 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 258 March 1997. 260 [2] Institute of Electrical and Electronics Engineers, "Local and 261 Metropolitan Area Networks: Port based Network Access Control", 262 IEEE Standard 802.1X, March 2001. 264 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 265 Levels", BCP 14, RFC 2119, March 1997. 267 [4] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 268 Authentication Dial In User Service (RADIUS)", RFC 2865, June 269 2000. 271 [5] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, 272 January 2001. 274 Informative References 276 [6] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 278 [7] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", 279 RFC 2869, June 2000. 281 [8] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 282 RFC 3118, June 2001. 284 [9] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, 285 August 2001. 287 [10] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, "IEEE 288 802.1X Remote Authentication Dial In User Service (RADIUS) 289 Usage Guidelines", RFC 3580, September 2003. 291 [11] Stapp, M. and T. Lemon, "The Authentication Suboption for the 292 DHCP Relay Agent Option", draft-ietf-dhc-auth-suboption-02 293 (work in progress), October 2003. 295 [12] Droms, R., "Authentication of DHCP Relay Agent Options Using 296 IPsec", draft-ietf-dhc-relay-agent-ipsec-00 (work in progress), 297 September 2003. 299 Authors' Addresses 301 Ralph Droms 302 Cisco Systems 303 1414 Massachusetts Avenue 304 Boxborough, MA 01719 305 USA 307 EMail: rdroms@cisco.com 309 John Schnizlein 310 Cisco Systems 311 9123 Loughran Road 312 Fort Washington, MD 20744 313 USA 315 EMail: jschnizl@cisco.com 317 Intellectual Property Statement 319 The IETF takes no position regarding the validity or scope of any 320 Intellectual Property Rights or other rights that might be claimed to 321 pertain to the implementation or use of the technology described in 322 this document or the extent to which any license under such rights 323 might or might not be available; nor does it represent that it has 324 made any independent effort to identify any such rights. Information 325 on the IETF's procedures with respect to rights in IETF Documents can 326 be found in BCP 78 and BCP 79. 328 Copies of IPR disclosures made to the IETF Secretariat and any 329 assurances of licenses to be made available, or the result of an 330 attempt made to obtain a general license or permission for the use of 331 such proprietary rights by implementers or users of this 332 specification can be obtained from the IETF on-line IPR repository at 333 http://www.ietf.org/ipr. 335 The IETF invites any interested party to bring to its attention any 336 copyrights, patents or patent applications, or other proprietary 337 rights that may cover technology that may be required to implement 338 this standard. Please address the information to the IETF at 339 ietf-ipr@ietf.org. 341 The IETF has been notified of intellectual property rights claimed in 342 regard to some or all of the specification contained in this 343 document. For more information consult the online list of claimed 344 rights. 346 Disclaimer of Validity 348 This document and the information contained herein are provided on an 349 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 350 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 351 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 352 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 353 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 354 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 356 Copyright Statement 358 Copyright (C) The Internet Society (2004). This document is subject 359 to the rights, licenses and restrictions contained in BCP 78, and 360 except as set forth therein, the authors retain all their rights. 362 Acknowledgment 364 Funding for the RFC Editor function is currently provided by the 365 Internet Society.