1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
|
Network Working Group R. Droms, Editor
INTERNET DRAFT Bucknell University
Obsoletes: draft-ietf-dhc-authentication-02.txt November 1996
Expires May 1997
Authentication for DHCP Messages
<draft-ietf-dhc-authentication-03.txt>
Status of this memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
The Dynamic Host Configuration Protocol (DHCP) [1] provides a
framework for passing configuration information to hosts on a TCP/IP
network. In some situations, network administrators may wish to
constrain the allocation of addresses to authorized hosts.
Additionally, some network administrators may wish to provide for
authentication of the source and contents of DHCP messages. This
document defines a new DHCP option through which authorization
tickets can be easily generated and newly attached hosts with proper
authorization can be automatically configured from an authenticated
DHCP server.
1. Introduction
DHCP transports protocol stack configuration parameters from
centrally administered servers to TCP/IP hosts. Among those
parameters are an IP address. DHCP servers can be configured to
dynamically allocate addresses from a pool of addresses, eliminating
a manual step in configuration of TCP/IP hosts.
Droms [Page 1]
DRAFT Authentication for DHCP Messages November 1996
Some network administrators may wish to provide authentication of the
source and contents of DHCP messages. For example, clients may be
subject to denial of service attacks through the use of bogus DHCP
servers, or may simply be misconfigured due to unintentionally
instantiated DHCP servers. Network administrators may wish to
constrain the allocation of addresses to authorized hosts to avoid
denial of service attacks in "hostile" environments where the network
medium is not physically secured, such as wireless networks or
college residence halls.
This document defines a technique that can provide both entity
authentication and message authentication.
1.1 Requirements
Throughout this document, the words that are used to define the
significance of particular requirements are capitalized. These words
are:
o "MUST"
This word or the adjective "REQUIRED" means that the
item is an absolute requirement of this specification.
o "MUST NOT"
This phrase means that the item is an absolute prohibition
of this specification.
o "SHOULD"
This word or the adjective "RECOMMENDED" means that there
may exist valid reasons in particular circumstances to ignore
this item, but the full implications should be understood and
the case carefully weighed before choosing a different course.
o "SHOULD NOT"
This phrase means that there may exist valid reasons in
particular circumstances when the listed behavior is acceptable
or even useful, but the full implications should be understood
and the case carefully weighed before implementing any behavior
described with this label.
Droms [Page 2]
DRAFT Authentication for DHCP Messages November 1996
o "MAY"
This word or the adjective "OPTIONAL" means that this item is
truly optional. One vendor may choose to include the item
because a particular marketplace requires it or because it
enhances the product, for example; another vendor may omit the
same item.
1.2 Terminology
This document uses the following terms:
o "DHCP client"
A DHCP client or "client" is an Internet host using DHCP to obtain
configuration parameters such as a network address.
o "DHCP server"
A DHCP server of "server"is an Internet host that returns
configuration parameters to DHCP clients.
2. Format of the authentication option
The following diagram defines the format of the DHCP
authentication option:
+----------+----------+----------+
| Code | Length | Protocol |
+----------+----------+----------+-----------+---
| Authentication information ...
+----------+----------+----------+-----------+---
The code for the authentication option is TBD, and the length field
contains the length of the protocol and authentication information
fields in octets. The protocol field defines the particular
technique for authentication used in the option.
This document defines two protocols in sections 3 and 4, encoded with
protocol field values 0 and 1. Protocol field values 2-254 are
reserved for future use. Other protocols may be defined according to
the procedure described in section 5.
3. Protocol 0
If the protocol field is 0, the authentication information field
Droms [Page 3]
DRAFT Authentication for DHCP Messages November 1996
holds a simple authentication token:
+----------+----------+----------+
| Code | n+1 | 0 |
+----------+----------+----------+-----------+------
| Authentication token (n octets) ...
+----------+----------+----------+-----------+------
The authentication token is an opaque, unencoded value known to both
the sender and receiver. The sender inserts the authentication token
in the DHCP message and the receiver matches the token from the
message to the shared token. If the authentication option is present
and the token from the message does not match the shared token, the
receiver MUST discard the message.
Protocol 0 may be used to pass a plain-text password and provides
only weak entity authentication and no message authentication. This
protocol is useful for rudimentary protection against, e.g.,
inadvertently instantiated DHCP servers.
DISCUSSION:
The intent here is to pass a constant, non-computed token such as
a plain-text password. Other types of entity authentication using
computed tokens such as Kerberos tickets or one-time passwords
will be defined as separate protocols.
4. Protocol 1
If the protocol field is 1, the authentication information contains
an encrypted value generated by the source as a message
authentication code (MAC) to provide message authentication and
entity authentication.
This technique is based on the HMAC protocol [3] using the MD5 hash
{2].
Droms [Page 4]
DRAFT Authentication for DHCP Messages November 1996
4.1 Format
The format of the authentication information for protocol 1 is:
+----------+----------+----------+
| Code | n | 1 |
+----------+----------+----------+----------+-
| Counter (8 octets) ...
+----------+----------+----------+----------+-
| MAC ...
+----------+----------+----------+----------+-
The following definitions will be used in the description of the
authentication information for protocol 1:
K - a secret value shared between the source and destination
of the message
Counter - the value of a 64-bit monotonically increasing counter
HMAC-MD5 - the MAC generating function as defined by [3] and [2]
The sender computes the MAC as described in [3]. The 'counter' field
of the authentication option MUST be set to the value of a
monotonically increasing counter and the 'MAC' field of the
authentication option MUST be set to all 0s for the computation of
the MAC. Because a DHCP relay agent may alter the values of the
'giaddr' and 'hops' fields in the DHCP message, the contents of those
two fields MUST also be set to zero for the computation of the
message digest. Using a counter value such as the current time of
day (e.g., an NTP-format timestamp [4]) can reduce the danger of
replay attacks.
DISCUSSION:
Protocol 1 specifies the use of HMAC-MD5. Use of a different
technique, such as HMAC-SHA, will be specified as a separate
protocol.
4.2 Message validation
To validate an incoming message, the receiver checks the 'counter'
field and computes the MAC as described in [3]. If the 'counter'
field does not contain a value larger than the last value of
'counter' used by the sender, the receiver MUST discard the incoming
message. The receiver MUST set the 'MAC' field of the authentication
option to all 0s for computation of the MAC. Because a DHCP relay
agent may alter the values of the 'giaddr' and 'hops' fields in the
DHCP message, the contents of those two fields MUST also be set to
Droms [Page 5]
DRAFT Authentication for DHCP Messages November 1996
zero for the computation of the MAC. If the MAC computed by the
receiver does not match the MAC contained in the authentication
option, the receiver MUST discard the DHCP message.
4.3 Key utilization
Each DHCP client has a key, K. The client uses its key to encode any
messages it sends to the server and to authenticate and verify any
messages it receives from the server. The client's key must be
initially distributed to the client through some out-of-band
mechanism, and must be stored locally on the client for use in all
authenticated DHCP messages. Once the client has been given its key,
it may use that key for all transactions even if the client's
configuration changes; e.g., if the client is assigned a new network
address.
Each DHCP server must know the keys for all authorized clients. If
all clients use the same key, clients can perform both entity and
message authentication for all messages received from servers.
Servers will be able to perform message authentication. To
authenticate the identity of individual clients, each client must be
configured with a unique key. Appendix A describes a technique for
key management.
5. Definition of new authentication protocols
The author of a new DHCP option will follow these steps to obtain
acceptance of the option as a part of the DHCP Internet Standard:
1. The author devises the new authentication protocol.
2. The author documents the new protocol as an Internet Draft.
3. The author submits the Internet Draft for review through the IETF
standards process as defined in "Internet Official Protocol
Standards" (STD 1). The new protocol will be submitted for
eventual acceptance as an Internet Standard.
4. The new protocol progresses through the IETF standards process;
the new option will be reviewed by the Dynamic Host Configuration
Working Group (if that group still exists), or as an Internet
Draft not submitted by an IETF working group.
This procedure for defining new authentication protocols will ensure
that:
* new options are reviewed for technical correctness and
appropriateness, and
* documentation for new options is complete and published.
Droms [Page 6]
DRAFT Authentication for DHCP Messages November 1996
6. References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541,
Bucknell University, October 1993.
[2] Rivest, R., "The MD5 Message-Digest Algorithm",
RFC-1321, April 1992.
[3] Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for
Message Authentication" <draft-ietf-ipsec-hmac-md5-01.txt> (work in
progress), August 1996.
[4] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March
1992.
7. Acknowledgments
Jeff Schiller and Christian Huitema developed this scheme during a
terminal room BOF at the Dallas IETF meeting, December 1995. The
author transcribed the notes from that discussion, which form the
basis for this document. The editor appreciates Jeff's and
Christian's patience in reviewing this document and its earlier
drafts.
Thanks also to John Wilkins, Ran Atkinson and Shawn Mamros for
reviewing this document, and to Thomas Narten for reviewing earlier
drafts of this document.
8. Security considerations
This document describes authentication and verification mechanisms
for DHCP.
9. Author's address
Ralph Droms
Computer Science Department
323 Dana Engineering
Bucknell University
Lewisburg, PA 17837
Phone: (717) 524-1145
EMail: droms@bucknell.edu
Droms [Page 7]
DRAFT Authentication for DHCP Messages November 1996
Appendix A - Key Management Technique
To avoid centralized management of a list of random keys, suppose K for
each client is generated from the pair (client identifier, subnet
address), which must be unique to that client. That is, K = MD5(MK,
unique-id), where MK is a secret master key and MD5 is some encoding
function.
Without knowledge of the master key MK, an unauthorized client cannot
generate its own key K. The server can quickly validate an incoming
message from a new client by regenerating K from the client-id. For known
clients, the server can choose to recover the client's K dynamically from
the client-id in the DHCP message, or can choose to precompute and cache
all of the Ks a priori.
Droms [Page 8]
|