idnits 2.17.1 draft-ietf-dhc-authentication-00.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 is 1 instance of too long lines in the document, the longest one being 2 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. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 1996) is 10114 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 1531 (ref. '1') (Obsoleted by RFC 1541) Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Droms (Editor) 3 INTERNET DRAFT Bucknell University 4 Obsoletes: February 1996 5 Expires August 1996 7 Authentication for DHCP Messages 8 10 Status of this memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 The Dynamic Host Configuration Protocol (DHCP) [1] provides a 31 framework for passing configuration information to hosts on a TCP/IP 32 network. In some situations, network administrators may wish to 33 constrain the allocation of addresses to authorized hosts. 34 Additionally, some network administrators may wish to provide for 35 client authentication of DHCP messages from DHCP servers. The goal of 36 this proposal is to suggest a technique through which authorization 37 tickets can be easily generated and newly attached hosts with proper 38 authorization can be automatically configured from an authenticated 39 DHCP server. 41 Introduction 43 DHCP transports protocol stack configuration parameters from 44 centrally administered servers to TCP/IP hosts. Among those 45 parameters are an IP address. DHCP servers can be configured to 46 dynamically allocate addresses from a pool of addresses, eliminating 47 a manual step in configuration of TCP/IP hosts. 49 DRAFT Authentication for DHCP Messages February 1996 51 In some situations, network administrators may wish to constrain the 52 allocation of addresses to authorized hosts. Such constraint may be 53 desirable in "hostile" environments where the network medium is not 54 physically secured, such as wireless networks or college residence 55 halls. 57 Additionally, some network administrators may wish to provide 58 authentication of DHCP messages from DHCP servers. In some 59 environments, clients may be subject to denial of service attacks 60 through the use of bogus DHCP servers, or may simply be misconfigured 61 due to unintentionally instantiated DHCP servers. 63 The goal of this proposal is to suggest a technique through which 64 authorization tickets can be easily generated and newly attached 65 hosts with proper authorization can be automatically configured from 66 an authenticated DHCP server. 68 Overview 70 The idea behind this proposal is to use well-known techniques to 71 authenticate the source and contents of DHCP messages. Each 72 authenticated DHCP message will include an encrypted value generated 73 by the source as a message authentication code (MAC), and will 74 contain a message digest confirming that the message contents have 75 not been altered in transit. 77 There is one "feature" of DHCP that complicates the authentication of 78 DHCP messages. DHCP clients use limited broadcast for all messages. 79 To allow for delivery of DHCP messages to servers that are not on the 80 same subnet, a DHCP relay agent on the same subnet as the client 81 receives the initial message and forwards the message on to the DHCP 82 server. The relay agent changes the contents of one field - 'giaddr' 83 - in the DHCP message. Thus, the message digest, which is to be 84 computed by the client and confirmed by the server, cannot include 85 the 'giaddr' field. 87 Message authentication 89 Suppose the sender, S, and receiver, R, share a secret key, K, where 90 K is unique to any messages exchanged between S and R. S and R are a 91 DHCP client/server pair. S forms the MAC by encoding a counter value 92 with K. This counter should be monotonically increasing and large 93 enough to hold an NTP-format timestamp. The MAC: 95 counter, f(K, MD(message + counter)) 97 (where MD is a message digest function as specified below) is 98 included in the DHCP message generated by S. Encoding function f 100 DRAFT Authentication for DHCP Messages February 1996 102 must have the characteristics that K cannot be deduced from the MAC 103 and f(K, MD(message + counter)) can't be guessed. R can then compute 104 f(K, MD(message + counter)) to verify that S must have known K. 105 Using a counter value such as the current time of day can reduce the 106 danger of replay attacks. 108 Key management 110 Assume that the shared key, K, is distributed to the client through 111 some out-of-band mechanism. The client must store K locally for use 112 in all authenticated DHCP messages. The server must know the Ks for 113 all authorized clients. 115 To avoid centralized management of a list of random keys, suppose K 116 for each client is generated from some value unique to that client. 117 That is, K = f(MK, unique-id), where MK is a secret master key and f 118 is an encoding function as described above. 120 Each DHCP client must have a unique "client-id" through which its 121 interactions with the DHCP server (specifically, the address 122 currently allocated to the client) can be identified. This client-id 123 may be a MAC address or a manufacturer's serial number; the specific 124 choice of client-id is left to the network administrator. The 125 client-id meets the requirements of the unique-id used to generate K 126 in the previous paragraph. 128 Without knowledge of the master key MK, an unauthorized client cannot 129 generate its own key K. The server can quickly validate an incoming 130 message from a new client by regenerating K from the client-id. For 131 known clients, the server can choose to recover the client's K 132 dynamically from the client-id in the DHCP message, or can choose to 133 precompute and cache all of the Ks a priori. 135 Selection of encoding function 137 The exact encoding function is TBD. One suggestion is to borrow from 138 DNSSEC, in which the encoding function is designated by an identifier 139 in the message. The identifier then selects no encoding, a default 140 encoding (using the Public Key Cryptographic Standard as specified in 141 DNSSEC) which must be provided, or one of several other optional 142 encodings. 144 Message contents verification 146 MD5 is a well-known mechanism for generating a digest that can 147 confirm the the contents of a message have not been altered in 148 transit. The only modification to MD5 for use in DHCP is to require 149 that the 'giaddr' field be set to all 0s for the MD5 computation. 151 DRAFT Authentication for DHCP Messages February 1996 153 Message contents 155 Putting all of this together, S builds: 157 DHCP message, counter, f(K, MD5(message - 'giaddr' + counter)) 159 where K is the client's key. R can then verify the contents of the 160 message from the MD5 digest value, and verify that S must have held 161 the shared secret key from the value of f(K, MD5(message - 'giaddr' + 162 counter)) 164 Applicability and Specification 166 This scheme is equally applicable to authentication of both DHCPv4 167 and DHCPv6 messages. If this mechanism is adopted as part of the 168 DHCPv4 or DHCPv6 specification, the authentication data will be 169 encoded as an option. 171 Acknowledgments 173 Jeff Schiller and Christian Huitema developed this scheme during a 174 terminal room BOF at the Dallas IETF meeting, December 1996. The 175 editor of this document transcribed the notes from that discussion. 176 Thanks to John Wilkins, Ran Atkinson and Thomas Narten for reviewing 177 a draft of this proposal. 179 References 181 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1531, 182 Bucknell University, October 1993. 184 Security Considerations 186 This memo describes authentication and verification mechanisms for DHCP 188 Author's Address 190 Ralph Droms 191 Computer Science Department 192 323 Dana Engineering 193 Bucknell University 194 Lewisburg, PA 17837 196 Phone: (717) 524-1145 197 EMail: droms@bucknell.edu