File: rfc3118.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (955 lines) | stat: -rw-r--r-- 35,536 bytes parent folder | download | duplicates (5)
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
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955






Network Working Group                                   R. Droms, Editor
Request for Comments: 3118                                 Cisco Systems
Category: Standards Track                             W. Arbaugh, Editor
                                                  University of Maryland
                                                               June 2001


                    Authentication for DHCP Messages

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This document defines a new Dynamic Host Configuration Protocol
   (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.  DHCP
   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.

1. Introduction

   DHCP [1] 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.

   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



Droms & Arbaugh             Standards Track                     [Page 1]

RFC 3118            Authentication for DHCP Messages           June 2001


   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.  The current protocol
   combines the original Schiller-Huitema-Droms authentication mechanism
   defined in a previous work in progress with the "delayed
   authentication" proposal developed by Bill Arbaugh.

1.1 DHCP threat model

   The threat to DHCP is inherently an insider threat (assuming a
   properly configured network where BOOTP ports are blocked on the
   enterprise's perimeter gateways.)  Regardless of the gateway
   configuration, however, the potential attacks by insiders and
   outsiders are the same.

   The attack specific to a DHCP client is the possibility of the
   establishment of a "rogue" server with the intent of providing
   incorrect configuration information to the client.  The motivation
   for doing so may be to establish a "man in the middle" attack or it
   may be for a "denial of service" attack.

   There is another threat to DHCP clients from mistakenly or
   accidentally configured DHCP servers that answer DHCP client requests
   with unintentionally incorrect configuration parameters.

   The threat specific to a DHCP server is an invalid client
   masquerading as a valid client.  The motivation for this may be for
   "theft of service", or to circumvent auditing for any number of
   nefarious purposes.

   The threat common to both the client and the server is the resource
   "denial of service" (DoS) attack.  These attacks typically involve
   the exhaustion of valid addresses, or the exhaustion of CPU or
   network bandwidth, and are present anytime there is a shared
   resource.  In current practice, redundancy mitigates DoS attacks the
   best.

1.2 Design goals

   These are the goals that were used in the development of the
   authentication protocol, listed in order of importance:

   1. Address the threats presented in Section 1.1.
   2. Avoid changing the current protocol.





Droms & Arbaugh             Standards Track                     [Page 2]

RFC 3118            Authentication for DHCP Messages           June 2001


   3. Limit state required by the server.
   4. Limit complexity (complexity breeds design and implementation
      errors).

1.3 Requirements Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [5].

1.4 DHCP 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 or "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:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |    Length     |  Protocol     |   Algorithm   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     RDM       | Replay Detection (64 bits)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont.                                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont. |                                               |
   +-+-+-+-+-+-+-+-+                                               |
   |                                                               |
   |           Authentication Information                          |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The code for the authentication option is 90, and the length field
   contains the length of the protocol, RDM, algorithm, Replay Detection
   fields and authentication information fields in octets.



Droms & Arbaugh             Standards Track                     [Page 3]

RFC 3118            Authentication for DHCP Messages           June 2001


   The protocol field defines the particular technique for
   authentication used in the option.  New protocols are defined as
   described in Section 6.

   The algorithm field defines the specific algorithm within the
   technique identified by the protocol field.

   The Replay Detection field is per the RDM, and the authentication
   information field is per the protocol in use.

   The Replay Detection Method (RDM) field determines the type of replay
   detection used in the Replay Detection field.

   If the RDM field contains 0x00, the replay detection field MUST be
   set to the value of a monotonically increasing counter.  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.  This method
   MUST be supported by all protocols.

3. Interaction with Relay Agents

   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 be set to zero for the computation of any hash function over the
   message header.  Additionally, a relay agent may append the DHCP
   relay agent information option 82 [7] as the last option in a message
   to servers.  If a server finds option 82 included in a received
   message, the server MUST compute any hash function as if the option
   were NOT included in the message without changing the order of
   options.  Whenever the server sends back option 82 to a relay agent,
   the server MUST not include the option in the computation of any hash
   function over the message.

4. Configuration token

   If the protocol field is 0, the authentication information field
   holds a simple configuration token:














Droms & Arbaugh             Standards Track                     [Page 4]

RFC 3118            Authentication for DHCP Messages           June 2001


   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |    Length     |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0| Replay Detection (64 bits)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont.                                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont. |                                               |
   |-+-+-+-+-+-+-+-+                                               |
   |                                                               |
   |           Authentication Information                          |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The configuration token is an opaque, unencoded value known to both
   the sender and receiver.  The sender inserts the configuration token
   in the DHCP message and the receiver matches the token from the
   message to the shared token.  If the configuration option is present
   and the token from the message does not match the shared token, the
   receiver MUST discard the message.

   Configuration token may be used to pass a plain-text configuration
   token and provides only weak entity authentication and no message
   authentication.  This protocol is only useful for rudimentary
   protection against 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.

5. Delayed authentication

   If the protocol field is 1, the message is using the "delayed
   authentication" mechanism.  In delayed authentication, the client
   requests authentication in its DHCPDISCOVER message and the server
   replies with a DHCPOFFER message that includes authentication
   information.  This authentication information contains a nonce value
   generated by the source as a message authentication code (MAC) to
   provide message authentication and entity authentication.

   This document defines the use of a particular technique based on the
   HMAC protocol [3] using the MD5 hash [2].




Droms & Arbaugh             Standards Track                     [Page 5]

RFC 3118            Authentication for DHCP Messages           June 2001


5.1 Management Issues

   The "delayed authentication" protocol does not attempt to address
   situations where a client may roam from one administrative domain to
   another, i.e., interdomain roaming.  This protocol is focused on
   solving the intradomain problem where the out-of-band exchange of a
   shared secret is feasible.

5.2 Format

   The format of the authentication request in a DHCPDISCOVER or a
   DHCPINFORM message for delayed authentication is:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |    Length     |0 0 0 0 0 0 0 1|   Algorithm   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     RDM       | Replay Detection (64 bits)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont.                                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont. |
   +-+-+-+-+-+-+-+-+

   The format of the authentication information in a DHCPOFFER,
   DHCPREQUEST or DHCPACK message for delayed authentication is:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |    Length     |0 0 0 0 0 0 0 1|   Algorithm   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     RDM       | Replay Detection (64 bits)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont.                                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont. | Secret ID (32 bits)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | secret id cont| HMAC-MD5 (128 bits) ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The following definitions will be used in the description of the
   authentication information for delayed authentication, algorithm 1:







Droms & Arbaugh             Standards Track                     [Page 6]

RFC 3118            Authentication for DHCP Messages           June 2001


   Replay Detection    - as defined by the RDM field
   K                   - a secret value shared between the source and
                         destination of the message; each secret has a
                         unique identifier (secret ID)
   secret ID           - the unique identifier for the secret value
                         used to generate the MAC for this message
   HMAC-MD5            - the MAC generating function [3, 2].

   The sender computes the MAC using the HMAC generation algorithm [3]
   and the MD5 hash function [2].  The entire DHCP message (except as
   noted below), including the DHCP message header and the options
   field, is used as input to the HMAC-MD5 computation function.  The
   'secret ID' field MUST be set to the identifier of the secret used to
   generate the MAC.

   DISCUSSION:

      Algorithm 1 specifies the use of HMAC-MD5.  Use of a different
      technique, such as HMAC-SHA, will be specified as a separate
      protocol.

      Delayed authentication requires a shared secret key for each
      client on each DHCP server with which that client may wish to use
      the DHCP protocol.  Each secret key has a unique identifier that
      can be used by a receiver to determine which secret was used to
      generate the MAC in the DHCP message.  Therefore, delayed
      authentication may not scale well in an architecture in which a
      DHCP client connects to multiple administrative domains.

5.3 Message validation

   To validate an incoming message, the receiver first checks that the
   value in the replay detection field is acceptable according to the
   replay detection method specified by the RDM field.  Next, the
   receiver computes the MAC as described in [3].  The receiver MUST set
   the 'MAC' field of the authentication option to all 0s for
   computation of the MAC, and 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 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.

   Section 3 provides additional information on handling messages that
   include option 82 (Relay Agents).






Droms & Arbaugh             Standards Track                     [Page 7]

RFC 3118            Authentication for DHCP Messages           June 2001


5.4 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 SHOULD be
   initially distributed to the client through some out-of-band
   mechanism, and SHOULD be stored locally on the client for use in all
   authenticated DHCP messages.  Once the client has been given its key,
   it SHOULD 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, or be able to obtain in a secure manner,
   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.  However, the sharing of keys is
   strongly discouraged as it allows for unauthorized clients to
   masquerade as authorized clients by obtaining a copy of the shared
   key.  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.5 Client considerations

   This section describes the behavior of a DHCP client using delayed
   authentication.

5.5.1 INIT state

   When in INIT state, the client uses delayed authentication as
   follows:

   1. The client MUST include the authentication request option in its
      DHCPDISCOVER message along with a client identifier option [6] to
      identify itself uniquely to the server.

   2. The client MUST perform the validation test described in section
      5.3 on any DHCPOFFER messages that include authentication
      information.  If one or more DHCPOFFER messages pass the
      validation test, the client chooses one of the offered
      configurations.

      Client behavior if no DHCPOFFER messages include authentication
      information or pass the validation test is controlled by local
      policy in the client.  According to client policy, the client MAY
      choose to respond to a DHCPOFFER message that has not been
      authenticated.




Droms & Arbaugh             Standards Track                     [Page 8]

RFC 3118            Authentication for DHCP Messages           June 2001


      The decision to set local policy to accept unauthenticated
      messages should be made with care.  Accepting an unauthenticated
      DHCPOFFER message can make the client vulnerable to spoofing and
      other attacks.  If local users are not explicitly informed that
      the client has accepted an unauthenticated DHCPOFFER message, the
      users may incorrectly assume that the client has received an
      authenticated address and is not subject to DHCP attacks through
      unauthenticated messages.

      A client MUST be configurable to decline unauthenticated messages,
      and SHOULD be configured by default to decline unauthenticated
      messages.  A client MAY choose to differentiate between DHCPOFFER
      messages with no authentication information and DHCPOFFER messages
      that do not pass the validation test; for example, a client might
      accept the former and discard the latter.  If a client does accept
      an unauthenticated message, the client SHOULD inform any local
      users and SHOULD log the event.

   3. The client replies with a DHCPREQUEST message that MUST include
      authentication information encoded with the same secret used by
      the server in the selected DHCPOFFER message.

   4. If the client authenticated the DHCPOFFER it accepted, the client
      MUST validate the DHCPACK message from the server.  The client
      MUST discard the DHCPACK if the message fails to pass validation
      and MAY log the validation failure.  If the DHCPACK fails to pass
      validation, the client MUST revert to INIT state and returns to
      step 1.  The client MAY choose to remember which server replied
      with a DHCPACK message that failed to pass validation and discard
      subsequent messages from that server.

      If the client accepted a DHCPOFFER message that did not include
      authentication information or did not pass the validation test,
      the client MAY accept an unauthenticated DHCPACK message from the
      server.

5.5.2 INIT-REBOOT state

   When in INIT-REBOOT state, the client MUST use the secret it used in
   its DHCPREQUEST message to obtain its current configuration to
   generate authentication information for the DHCPREQUEST message.  The
   client MAY choose to accept unauthenticated DHCPACK/DHCPNAK messages
   if no authenticated messages were received.  The client MUST treat
   the receipt (or lack thereof) of any DHCPACK/DHCPNAK messages as
   specified in section 3.2 of [1].






Droms & Arbaugh             Standards Track                     [Page 9]

RFC 3118            Authentication for DHCP Messages           June 2001


5.5.3 RENEWING state

   When in RENEWING state, the client uses the secret it used in its
   initial DHCPREQUEST message to obtain its current configuration to
   generate authentication information for the DHCPREQUEST message.  If
   client receives no DHCPACK messages or none of the DHCPACK messages
   pass validation, the client behaves as if it had not received a
   DHCPACK message in section 4.4.5 of the DHCP specification [1].

5.5.4 REBINDING state

   When in REBINDING state, the client uses the secret it used in its
   initial DHCPREQUEST message to obtain its current configuration to
   generate authentication information for the DHCPREQUEST message.  If
   client receives no DHCPACK messages or none of the DHCPACK messages
   pass validation, the client behaves as if it had not received a
   DHCPACK message in section 4.4.5 of the DHCP specification [1].

5.5.5 DHCPINFORM message

   Since the client already has some configuration information, the
   client may also have established a shared secret value, K, with a
   server.  Therefore, the client SHOULD use the authentication request
   as in a DHCPDISCOVER message when a shared secret value exists.  The
   client MUST treat any received DHCPACK messages as it does DHCPOFFER
   messages, see section 5.5.1.

5.5.6 DHCPRELEASE message

   Since the client is already in the BOUND state, the client will have
   a security association already established with the server.
   Therefore, the client MUST include authentication information with
   the DHCPRELEASE message.

5.6 Server considerations

   This section describes the behavior of a server in response to client
   messages using delayed authentication.

5.6.1 General considerations

   Each server maintains a list of secrets and identifiers for those
   secrets that it shares with clients and potential clients.  This
   information must be maintained in such a way that the server can:

   *  Identify an appropriate secret and the identifier for that secret
      for use with a client that the server may not have previously
      communicated with



Droms & Arbaugh             Standards Track                    [Page 10]

RFC 3118            Authentication for DHCP Messages           June 2001


   *  Retrieve the secret and identifier used by a client to which the
      server has provided previous configuration information

   Each server MUST save the counter from the previous authenticated
   message.  A server MUST discard any incoming message which fails the
   replay detection check as defined by the RDM avoid replay attacks.

   DISCUSSION:

      The authenticated DHCPREQUEST message from a client in INIT-REBOOT
      state can only be validated by servers that used the same secret
      in their DHCPOFFER messages.  Other servers will discard the
      DHCPREQUEST messages.  Thus, only servers that used the secret
      selected by the client will be able to determine that their
      offered configuration information was not selected and the offered
      network address can be returned to the server's pool of available
      addresses.  The servers that cannot validate the DHCPREQUEST
      message will eventually return their offered network addresses to
      their pool of available addresses as described in section 3.1 of
      the DHCP specification [1].

5.6.2 After receiving a DHCPDISCOVER message

   The server selects a secret for the client and includes
   authentication information in the DHCPOFFER message as specified in
   section 5, above.  The server MUST record the identifier of the
   secret selected for the client and use that same secret for
   validating subsequent messages with the client.

5.6.3 After receiving a DHCPREQUEST message

   The server uses the secret identified in the message and validates
   the message as specified in section 5.3.  If the message fails to
   pass validation or the server does not know the secret identified by
   the 'secret ID' field, the server MUST discard the message and MAY
   choose to log the validation failure.

   If the message passes the validation procedure, the server responds
   as described in the DHCP specification.  The server MUST include
   authentication information generated as specified in section 5.2.

5.6.4 After receiving a DHCPINFORM message

   The server MAY choose to accept unauthenticated DHCPINFORM messages,
   or only accept authenticated DHCPINFORM messages based on a site
   policy.





Droms & Arbaugh             Standards Track                    [Page 11]

RFC 3118            Authentication for DHCP Messages           June 2001


   When a client includes the authentication request in a DHCPINFORM
   message, the server MUST respond with an authenticated DHCPACK
   message.  If the server does not have a shared secret value
   established with the sender of the DHCPINFORM message, then the
   server MAY respond with an unauthenticated DHCPACK message, or a
   DHCPNAK if the server does not accept unauthenticated clients based
   on the site policy, or the server MAY choose not to respond to the
   DHCPINFORM message.

6. IANA Considerations

   Section 2 defines a new DHCP option called the Authentication Option,
   whose option code is 90.

   This document specifies three new name spaces associated with the
   Authentication Option, which are to be created and maintained by
   IANA:  Protocol, Algorithm and RDM.

   Initial values assigned from the Protocol name space are 0 (for the
   configuration token Protocol in section 4) and 1 (for the delayed
   authentication Protocol in section 5).  Additional values from the
   Protocol name space will be assigned through IETF Consensus, as
   defined in RFC 2434 [8].

   The Algorithm name space is specific to individual Protocols.  That
   is, each Protocol has its own Algorithm name space.  The guidelines
   for assigning Algorithm name space values for a particular protocol
   should be specified along with the definition of a new Protocol.

   For the configuration token Protocol, the Algorithm field MUST be 0.
   For the delayed authentication Protocol, the Algorithm value 1 is
   assigned to the HMAC-MD5 generating function as defined in section 5.
   Additional values from the Algorithm name space for Algorithm 1 will
   be assigned through IETF Consensus, as defined in RFC 2434.

   The initial value of 0 from the RDM name space is assigned to the use
   of a monotonically increasing value as defined in section 2.
   Additional values from the RDM name space will be assigned through
   IETF Consensus, as defined in RFC 2434.

7. References

   [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March
       1997.

   [2] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
       1992.




Droms & Arbaugh             Standards Track                    [Page 12]

RFC 3118            Authentication for DHCP Messages           June 2001


   [3] Krawczyk H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for
       Message Authentication", RFC 2104, February 1997.

   [4] Mills, D., "Network Time Protocol (Version 3)", RFC 1305, March
       1992.

   [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", RFC 2219, March 1997.

   [6] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
       Extensions", RFC 2132, March 1997.

   [7] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
       January 2001.

   [8] Narten, T. and H. Alvestrand, "Guidelines for Writing and IANA
       Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

8. Acknowledgments

   Jeff Schiller and Christian Huitema developed the original version of
   this authentication protocol in a terminal room BOF at the Dallas
   IETF meeting, December 1995.  One of the editors (Droms) transcribed
   the notes from that discussion, which form the basis for this
   document.  The editors appreciate Jeff's and Christian's patience in
   reviewing this document and its earlier drafts.

   The "delayed authentication" mechanism used in section 5 is due to
   Bill Arbaugh.  The threat model and requirements in sections 1.1 and
   1.2 come from Bill's negotiation protocol proposal.  The attendees of
   an interim meeting of the DHC WG held in June, 1998, including Peter
   Ford, Kim Kinnear, Glenn Waters, Rob Stevens, Bill Arbaugh, Baiju
   Patel, Carl Smith, Thomas Narten, Stewart Kwan, Munil Shah, Olafur
   Gudmundsson, Robert Watson, Ralph Droms, Mike Dooley, Greg Rabil and
   Arun Kapur, developed the threat model and reviewed several
   alternative proposals.

   The replay detection method field is due to Vipul Gupta.

   Other input from Bill Sommerfield is gratefully acknowledged.

   Thanks also to John Wilkins, Ran Atkinson, Shawn Mamros and Thomas
   Narten for reviewing earlier drafts of this document.








Droms & Arbaugh             Standards Track                    [Page 13]

RFC 3118            Authentication for DHCP Messages           June 2001


9. Security Considerations

   This document describes authentication and verification mechanisms
   for DHCP.

9.1 Protocol vulnerabilities

   The configuration token authentication mechanism is vulnerable to
   interception and provides only the most rudimentary protection
   against inadvertently instantiated DHCP servers.

   The delayed authentication mechanism described in this document is
   vulnerable to a denial of service attack through flooding with
   DHCPDISCOVER messages, which are not authenticated by this protocol.
   Such an attack may overwhelm the computer on which the DHCP server is
   running and may exhaust the addresses available for assignment by the
   DHCP server.

   Delayed authentication may also be vulnerable to a denial of service
   attack through flooding with authenticated messages, which may
   overwhelm the computer on which the DHCP server is running as the
   authentication keys for the incoming messages are computed.

9.2 Protocol limitations

   Delayed authentication does not support interdomain authentication.

   A real digital signature mechanism such as RSA, while currently
   computationally infeasible, would provide better security.






















Droms & Arbaugh             Standards Track                    [Page 14]

RFC 3118            Authentication for DHCP Messages           June 2001


10. Editors' Addresses

   Ralph Droms
   Cisco Systems
   300 Apollo Drive
   Chelmsford, MA 01824

   Phone: (978) 244-4733
   EMail: rdroms@cisco.com


   Bill Arbaugh
   Department of Computer Science
   University of Maryland
   A.V. Williams Building
   College Park, MD 20742

   Phone: (301) 405-2774
   EMail: waa@cs.umd.edu
































Droms & Arbaugh             Standards Track                    [Page 15]

RFC 3118            Authentication for DHCP Messages           June 2001


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 [6],
   subnet address, e.g., 192.168.1.0), which must be unique to that
   client.  That is, K = MAC(MK, unique-id), where MK is a secret master
   key and MAC is a keyed one-way function such as HMAC-MD5.

   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.

   By deriving all keys from a single master key, the DHCP server does
   not need access to clear text passwords, and can compute and verify
   the keyed MACs without requiring help from a centralized
   authentication server.

   To avoid compromise of this key management system, the master key,
   MK, MUST NOT be stored by any clients.  The client SHOULD only be
   given its key, K.  If MK is compromised, a new MK SHOULD be chosen
   and all clients given new individual keys.



























Droms & Arbaugh             Standards Track                    [Page 16]

RFC 3118            Authentication for DHCP Messages           June 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Droms & Arbaugh             Standards Track                    [Page 17]