idnits 2.17.1 draft-droms-agentopt-8021x-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 (Nov 2001) is 8198 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. '2' Summary: 3 errors (**), 0 flaws (~~), 2 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: May 2, 2002 Cisco Systems 5 Nov 2001 7 802.1X Credentials Sub-option for the DHCP Relay Agent Information 8 Option 9 draft-droms-agentopt-8021x-00.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 18 other groups may also distribute working documents as Internet- 19 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 27 http://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 May 2, 2002. 34 Copyright Notice 36 Copyright (C) The Internet Society (2001). All Rights Reserved. 38 Abstract 40 The IEEE 802.1X protocol provides authenticated layer 2 network 41 access. As part of the authentication for 802.1X, a device such as a 42 switch or a wireless LAN access point can receive credentials from 43 the authentication authority identifying the user of a device 44 requesting access. These credentials can then be used by a DHCP 45 server in the selection of an IP address for assignment to the device 46 through its DHCP client. The 802.1X Credentials sub-option allows an 47 access device that implements 802.1X and that can create DHCP Relay 48 Agent options to pass along credentials for the user of a device 49 received during 802.1X authentication to a DHCP server. 51 1. Introduction and Background 53 The 802.1X Credentials sub-option for the DHCP Relay Agent option 54 provides a way through which network elements can pass information 55 obtained through IEEE 802.1X [2] layer-2 authentication to a DHCP 56 server. IEEE 802.1X is a mechanism through which a device such as a 57 switch or a wireless LAN access point can authenticate the identity 58 of the user of a device before providing layer 2 network access. In 59 802.1X authenticated access, a device must first exchange some 60 authentication credentials with the network access device. The 61 access device then supplies these credentials to an authentication 62 server, which either confirms or denies the identity of the user of 63 the device requesting network access. The access device, based on 64 the reply of the authentication server, then allows or denies network 65 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 | Authentication | 93 | Service | 94 +-----------------+ 96 Figure 1: Message exchange in IEEE 802.1X 97 In the application described in this document, the access device acts 98 as an 802.1X authenticator and adds DHCP relay agent options to DHCP 99 messages. During 802.1X authentication, the reply message from the 100 authentication server carries additional identification information 101 or credentials to the access device. The access device stores these 102 credentials locally. When the access device subsequently forwards 103 DHCP messages from the network device, the access device adds the 104 identification information in an 802.1X Credentials sub-option. The 105 802.1X Credentials sub-option is another suboption of the Relay Agent 106 option [5]. 108 2. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [1]. 114 2.1 General Terminology 116 Authentication server Provides a service that confirms the 117 identity of a network entity; e.g., a RADIUS [3] server 119 Authentication credentials Data provided by a device to authenticate 120 its identity 122 Identity credentials Data from the authentication server that 123 can be used to identify an authenticated device 125 2.2 DHCP Terminology 127 The following terms are used in conjunction with DHCP [4]. 129 DHCP relay agent Forwards DHCP messages between DHCP 130 clients and servers 132 DHCP server Provides configuration parameters to 133 clients through DHCP messages 135 DHCP client Requests configuration parameters from 136 servers through DHCP messages 138 Relay agent option A DHCP message option used by DHCP relay 139 agents to pass information to DHCP servers [5] 141 2.3 802.1X Terminology 143 The following terms are used in conjunction with the IEEE 802.1X 144 protocol. 146 Authenticator Confirms the identity of the supplicant and 147 controls the access of the supplicant to the network 149 Supplicant A device attempting to obtain network service 150 through the authenticator 152 3. 802.1X Credentials sub-option format 154 The 802.1X Credentials Sub-option is a new sub-option for the DHCP 155 Relay Agent option. 157 The format of the 802.1X Credentials sub-option is: 159 SubOpt Len 802.1X Information 160 code 161 +-------+-----+------+------+------+------+--...-+------+ 162 | TBD | N | b1 | b2 | b3 | b4 | | bN | 163 +-------+-----+------+------+------+------+--...-+------+ 165 The 802.1X credentials are carried as opaque data bytes b1...bN. 167 4. Client Behavior 169 To enable the use of the 802.1X Credentials sub-option, the host must 170 use both 802.1X and DHCP. The host need not make any other special 171 provision for the use of the 802.1X Credentials sub-option. 173 5. DHCP Relay Agent Behavior 175 When the DHCP relay agent receives a DHCP message from the client, it 176 MAY append a DHCP Relay Agent option containing the 802.1X 177 Credentials sub-option, along with any other relay agent sub-options 178 it is configured to supply. The 802.1X Credentials sub-option MUST 179 contain the credentials from the 802.1X authentication service. The 180 DHCP relay agent MUST NOT add 802.1X Credentials sub-options beyond 181 one in a message. 183 The specification of the mechanism through which the authentication 184 service supplies the credentials to the 802.1X authenticator is 185 beyond the scope of this document. The 802.1X Credentials sub-option 186 may be used for any credentials supplied to the authenticator through 187 whatever protocol used to communicate with the authentication 188 service. 190 6. Server Behavior 192 When the DHCP server receives a message from an relay agent 193 containing an 802.1X Credentials sub-option, it extracts the contents 194 of the of the sub-option and uses that information in selecting 195 configuration parameters for the client. 197 7. Security Considerations 199 DHCP as currently defined provides no authentication or security 200 mechanisms. Potential exposures to attack are discussed in section 7 201 of the DHCP protocol specification in RFC 2131. 203 The DHCP Relay Agent option depends on a trusted relationship between 204 the DHCP relay agent and the server, as described in section 5 of RFC 205 3046. Because the 802.1X credentials are not encrypted or protected 206 against modification in any way, the contents can be spoofed or 207 modifed by hostile devices in an unsecured network. 209 8. IANA Considerations 211 IANA has assigned the value of TBD for the DHCP Relay Agent 212 Information option sub-option code for this sub-option. This 213 document does not define any new namespaces or other constants for 214 which IANA must maintain a registry. 216 9. Terms of Use 218 Cisco has a pending patent which relates to the subject matter of 219 this Internet Draft. If a standard relating to this subject matter 220 is adopted by IETF and any claims of any issued Cisco patents are 221 necessary for practicing this standard, any party will be able to 222 obtain a license from Cisco to use any such patent claims under 223 openly specified, reasonable, non-discriminatory terms to implement 224 and fully comply with the standard. 226 References 228 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 229 Levels", BCP 14, RFC 2119, March 1997. 231 [2] Institute of Electrical and Electronics Engineers, "Port based 232 Network Access Control", IEEE Standard 802.1X, March 2001. 234 [3] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 235 Authentication Dial In User Service (RADIUS)", RFC 2865, June 236 2000. 238 [4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 239 March 1997. 241 [5] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, 242 January 2001. 244 Authors' Addresses 246 Ralph Droms 247 Cisco Systems 248 250 Apollo Drive 249 Chelmsford, MA 01824 250 USA 252 EMail: rdroms@cisco.com 254 John Schnizlein 255 Cisco Systems 256 9123 Loughran Road 257 Fort Washington, MD 20744 258 USA 260 EMail: jschnizl@cisco.com 262 Full Copyright Statement 264 Copyright (C) The Internet Society (2001). All Rights Reserved. 266 This document and translations of it may be copied and furnished to 267 others, and derivative works that comment on or otherwise explain it 268 or assist in its implementation may be prepared, copied, published 269 and distributed, in whole or in part, without restriction of any 270 kind, provided that the above copyright notice and this paragraph are 271 included on all such copies and derivative works. However, this 272 document itself may not be modified in any way, such as by removing 273 the copyright notice or references to the Internet Society or other 274 Internet organizations, except as needed for the purpose of 275 developing Internet standards in which case the procedures for 276 copyrights defined in the Internet Standards process must be 277 followed, or as required to translate it into languages other than 278 English. 280 The limited permissions granted above are perpetual and will not be 281 revoked by the Internet Society or its successors or assigns. 283 This document and the information contained herein is provided on an 284 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 285 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 286 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 287 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 288 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 290 Acknowledgement 292 Funding for the RFC Editor function is currently provided by the 293 Internet Society.