idnits 2.17.1 draft-ietf-dhc-authentication-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 158: '... receiver MUST discard the message....' RFC 2119 keyword, line 205: '...ntication option MUST be set to the va...' RFC 2119 keyword, line 207: '...ntication option MUST be set to all 0s...' RFC 2119 keyword, line 210: '... two fields MUST also be set to zero...' RFC 2119 keyword, line 226: '...er, the receiver MUST discard the inco...' (3 more instances...) -- The draft header indicates that this document obsoletes draft-ietf-dhc-authentication-02.txt, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- -- No information found for rfcdraft-ietf-dhc-authentication-02.txt - is the name correct? -- 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 (May 1997) is 9841 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) ** Obsolete normative reference: RFC 1541 (ref. '1') (Obsoleted by RFC 2131) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 1305 (ref. '4') (Obsoleted by RFC 5905) Summary: 14 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Droms, Editor 2 INTERNET DRAFT Bucknell University 3 Obsoletes: draft-ietf-dhc-authentication-02.txt November 1996 4 Expires May 1997 6 Authentication for DHCP Messages 7 9 Status of this memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Abstract 29 The Dynamic Host Configuration Protocol (DHCP) [1] provides a 30 framework for passing configuration information to hosts on a TCP/IP 31 network. In some situations, network administrators may wish to 32 constrain the allocation of addresses to authorized hosts. 33 Additionally, some network administrators may wish to provide for 34 authentication of the source and contents of DHCP messages. This 35 document defines a new DHCP option through which authorization 36 tickets can be easily generated and newly attached hosts with proper 37 authorization can be automatically configured from an authenticated 38 DHCP server. 40 1. Introduction 42 DHCP transports protocol stack configuration parameters from 43 centrally administered servers to TCP/IP hosts. Among those 44 parameters are an IP address. DHCP servers can be configured to 45 dynamically allocate addresses from a pool of addresses, eliminating 46 a manual step in configuration of TCP/IP hosts. 48 DRAFT Authentication for DHCP Messages November 1996 50 Some network administrators may wish to provide authentication of the 51 source and contents of DHCP messages. For example, clients may be 52 subject to denial of service attacks through the use of bogus DHCP 53 servers, or may simply be misconfigured due to unintentionally 54 instantiated DHCP servers. Network administrators may wish to 55 constrain the allocation of addresses to authorized hosts to avoid 56 denial of service attacks in "hostile" environments where the network 57 medium is not physically secured, such as wireless networks or 58 college residence halls. 60 This document defines a technique that can provide both entity 61 authentication and message authentication. 63 1.1 Requirements 65 Throughout this document, the words that are used to define the 66 significance of particular requirements are capitalized. These words 67 are: 69 o "MUST" 71 This word or the adjective "REQUIRED" means that the 72 item is an absolute requirement of this specification. 74 o "MUST NOT" 76 This phrase means that the item is an absolute prohibition 77 of this specification. 79 o "SHOULD" 81 This word or the adjective "RECOMMENDED" means that there 82 may exist valid reasons in particular circumstances to ignore 83 this item, but the full implications should be understood and 84 the case carefully weighed before choosing a different course. 86 o "SHOULD NOT" 88 This phrase means that there may exist valid reasons in 89 particular circumstances when the listed behavior is acceptable 90 or even useful, but the full implications should be understood 91 and the case carefully weighed before implementing any behavior 92 described with this label. 94 DRAFT Authentication for DHCP Messages November 1996 96 o "MAY" 98 This word or the adjective "OPTIONAL" means that this item is 99 truly optional. One vendor may choose to include the item 100 because a particular marketplace requires it or because it 101 enhances the product, for example; another vendor may omit the 102 same item. 104 1.2 Terminology 106 This document uses the following terms: 108 o "DHCP client" 110 A DHCP client or "client" is an Internet host using DHCP to obtain 111 configuration parameters such as a network address. 113 o "DHCP server" 115 A DHCP server of "server"is an Internet host that returns 116 configuration parameters to DHCP clients. 118 2. Format of the authentication option 120 The following diagram defines the format of the DHCP 121 authentication option: 123 +----------+----------+----------+ 124 | Code | Length | Protocol | 125 +----------+----------+----------+-----------+--- 126 | Authentication information ... 127 +----------+----------+----------+-----------+--- 129 The code for the authentication option is TBD, and the length field 130 contains the length of the protocol and authentication information 131 fields in octets. The protocol field defines the particular 132 technique for authentication used in the option. 134 This document defines two protocols in sections 3 and 4, encoded with 135 protocol field values 0 and 1. Protocol field values 2-254 are 136 reserved for future use. Other protocols may be defined according to 137 the procedure described in section 5. 139 3. Protocol 0 141 If the protocol field is 0, the authentication information field 143 DRAFT Authentication for DHCP Messages November 1996 145 holds a simple authentication token: 147 +----------+----------+----------+ 148 | Code | n+1 | 0 | 149 +----------+----------+----------+-----------+------ 150 | Authentication token (n octets) ... 151 +----------+----------+----------+-----------+------ 153 The authentication token is an opaque, unencoded value known to both 154 the sender and receiver. The sender inserts the authentication token 155 in the DHCP message and the receiver matches the token from the 156 message to the shared token. If the authentication option is present 157 and the token from the message does not match the shared token, the 158 receiver MUST discard the message. 160 Protocol 0 may be used to pass a plain-text password and provides 161 only weak entity authentication and no message authentication. This 162 protocol is useful for rudimentary protection against, e.g., 163 inadvertently instantiated DHCP servers. 165 DISCUSSION: 167 The intent here is to pass a constant, non-computed token such as 168 a plain-text password. Other types of entity authentication using 169 computed tokens such as Kerberos tickets or one-time passwords 170 will be defined as separate protocols. 172 4. Protocol 1 174 If the protocol field is 1, the authentication information contains 175 an encrypted value generated by the source as a message 176 authentication code (MAC) to provide message authentication and 177 entity authentication. 179 This technique is based on the HMAC protocol [3] using the MD5 hash 180 {2]. 182 DRAFT Authentication for DHCP Messages November 1996 184 4.1 Format 186 The format of the authentication information for protocol 1 is: 188 +----------+----------+----------+ 189 | Code | n | 1 | 190 +----------+----------+----------+----------+- 191 | Counter (8 octets) ... 192 +----------+----------+----------+----------+- 193 | MAC ... 194 +----------+----------+----------+----------+- 196 The following definitions will be used in the description of the 197 authentication information for protocol 1: 199 K - a secret value shared between the source and destination 200 of the message 201 Counter - the value of a 64-bit monotonically increasing counter 202 HMAC-MD5 - the MAC generating function as defined by [3] and [2] 204 The sender computes the MAC as described in [3]. The 'counter' field 205 of the authentication option MUST be set to the value of a 206 monotonically increasing counter and the 'MAC' field of the 207 authentication option MUST be set to all 0s for the computation of 208 the MAC. Because a DHCP relay agent may alter the values of the 209 'giaddr' and 'hops' fields in the DHCP message, the contents of those 210 two fields MUST also be set to zero for the computation of the 211 message digest. Using a counter value such as the current time of 212 day (e.g., an NTP-format timestamp [4]) can reduce the danger of 213 replay attacks. 215 DISCUSSION: 217 Protocol 1 specifies the use of HMAC-MD5. Use of a different 218 technique, such as HMAC-SHA, will be specified as a separate 219 protocol. 221 4.2 Message validation 223 To validate an incoming message, the receiver checks the 'counter' 224 field and computes the MAC as described in [3]. If the 'counter' 225 field does not contain a value larger than the last value of 226 'counter' used by the sender, the receiver MUST discard the incoming 227 message. The receiver MUST set the 'MAC' field of the authentication 228 option to all 0s for computation of the MAC. Because a DHCP relay 229 agent may alter the values of the 'giaddr' and 'hops' fields in the 230 DHCP message, the contents of those two fields MUST also be set to 232 DRAFT Authentication for DHCP Messages November 1996 234 zero for the computation of the MAC. If the MAC computed by the 235 receiver does not match the MAC contained in the authentication 236 option, the receiver MUST discard the DHCP message. 238 4.3 Key utilization 240 Each DHCP client has a key, K. The client uses its key to encode any 241 messages it sends to the server and to authenticate and verify any 242 messages it receives from the server. The client's key must be 243 initially distributed to the client through some out-of-band 244 mechanism, and must be stored locally on the client for use in all 245 authenticated DHCP messages. Once the client has been given its key, 246 it may use that key for all transactions even if the client's 247 configuration changes; e.g., if the client is assigned a new network 248 address. 250 Each DHCP server must know the keys for all authorized clients. If 251 all clients use the same key, clients can perform both entity and 252 message authentication for all messages received from servers. 253 Servers will be able to perform message authentication. To 254 authenticate the identity of individual clients, each client must be 255 configured with a unique key. Appendix A describes a technique for 256 key management. 258 5. Definition of new authentication protocols 260 The author of a new DHCP option will follow these steps to obtain 261 acceptance of the option as a part of the DHCP Internet Standard: 263 1. The author devises the new authentication protocol. 264 2. The author documents the new protocol as an Internet Draft. 265 3. The author submits the Internet Draft for review through the IETF 266 standards process as defined in "Internet Official Protocol 267 Standards" (STD 1). The new protocol will be submitted for 268 eventual acceptance as an Internet Standard. 269 4. The new protocol progresses through the IETF standards process; 270 the new option will be reviewed by the Dynamic Host Configuration 271 Working Group (if that group still exists), or as an Internet 272 Draft not submitted by an IETF working group. 274 This procedure for defining new authentication protocols will ensure 275 that: 277 * new options are reviewed for technical correctness and 278 appropriateness, and 279 * documentation for new options is complete and published. 281 DRAFT Authentication for DHCP Messages November 1996 283 6. References 285 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541, 286 Bucknell University, October 1993. 288 [2] Rivest, R., "The MD5 Message-Digest Algorithm", 289 RFC-1321, April 1992. 291 [3] Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for 292 Message Authentication" (work in 293 progress), August 1996. 295 [4] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March 296 1992. 298 7. Acknowledgments 300 Jeff Schiller and Christian Huitema developed this scheme during a 301 terminal room BOF at the Dallas IETF meeting, December 1995. The 302 author transcribed the notes from that discussion, which form the 303 basis for this document. The editor appreciates Jeff's and 304 Christian's patience in reviewing this document and its earlier 305 drafts. 307 Thanks also to John Wilkins, Ran Atkinson and Shawn Mamros for 308 reviewing this document, and to Thomas Narten for reviewing earlier 309 drafts of this document. 311 8. Security considerations 313 This document describes authentication and verification mechanisms 314 for DHCP. 316 9. Author's address 318 Ralph Droms 319 Computer Science Department 320 323 Dana Engineering 321 Bucknell University 322 Lewisburg, PA 17837 324 Phone: (717) 524-1145 325 EMail: droms@bucknell.edu 327 DRAFT Authentication for DHCP Messages November 1996 329 Appendix A - Key Management Technique 331 To avoid centralized management of a list of random keys, suppose K for 332 each client is generated from the pair (client identifier, subnet 333 address), which must be unique to that client. That is, K = MD5(MK, 334 unique-id), where MK is a secret master key and MD5 is some encoding 335 function. 337 Without knowledge of the master key MK, an unauthorized client cannot 338 generate its own key K. The server can quickly validate an incoming 339 message from a new client by regenerating K from the client-id. For known 340 clients, the server can choose to recover the client's K dynamically from 341 the client-id in the DHCP message, or can choose to precompute and cache 342 all of the Ks a priori.