crypto/heimdal-0.6.3/doc/standardisation/draft-hornstein-dhc-kerbauth-02.txt

   1
   2 DHC Working Group                                          Ken Hornstein
   3 INTERNET-DRAFT                                                       NRL
   4 Category: Standards Track                                      Ted Lemon
   5 <draft-hornstein-dhc-kerbauth-02.txt>             Internet Engines, Inc.
   6 20 February 2000                                           Bernard Aboba
   7 Expires: September 1, 2000                                     Microsoft
   8                                                         Jonathan Trostle
   9                                                            Cisco Systems
  10
  11                    DHCP Authentication Via Kerberos V
  12
  13 This document is an Internet-Draft and is in full conformance with all
  14 provisions of Section 10 of RFC2026.
  15
  16 Internet-Drafts are working documents of the Internet Engineering Task
  17 Force (IETF), its areas, and its working groups.  Note that other groups
  18 may also distribute working documents as Internet- Drafts.
  19
  20 Internet-Drafts are draft documents valid for a maximum of six months
  21 and may be updated, replaced, or obsoleted by other documents at any
  22 time.  It is inappropriate to use Internet-Drafts as reference material
  23 or to cite them other than as "work in progress."
  24
  25 The list of current Internet-Drafts can be accessed at
  26 http://www.ietf.org/ietf/1id-abstracts.txt
  27
  28 The list of Internet-Draft Shadow Directories can be accessed at
  29 http://www.ietf.org/shadow.html.
  30
  31 The distribution of this memo is unlimited.
  32
  33 1.  Copyright Notice
  34
  35 Copyright (C) The Internet Society (2000).  All Rights Reserved.
  36
  37 2.  Abstract
  38
  39 The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for
  40 host configuration. In some circumstances, it is useful for the DHCP
  41 client and server to be able to mutually authenticate as well as to
  42 guarantee the integrity of DHCP packets in transit.  This document
  43 describes how Kerberos V may be used in order to allow a DHCP client and
  44 server to mutually authenticate as well as to protect the integrity of
  45 the DHCP exchange. The protocol described in this document is capable of
  46 handling both intra-realm and inter-realm authentication.
  47
  48
  49
  50
  51
  52
  53 Hornstein, et al.            Standards Track                    [Page 1]
  54
  55
  56 INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
  57
  58
  59 3.  Introduction
  60
  61 The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for
  62 host configuration. In some circumstances, it is useful for the DHCP
  63 client and server to be able to mutually authenticate as well as to
  64 guarantee the integrity of DHCP packets in transit.  This document
  65 describes how Kerberos V may be used in order to allow a DHCP client and
  66 server to mutually authenticate as well as to protect the integrity of
  67 the DHCP exchange.  The protocol described in this document is capable
  68 of handling both intra-realm and inter-realm authentication.
  69
  70 3.1.  Terminology
  71
  72 This document uses the following terms:
  73
  74 DHCP client
  75           A DHCP client or "client" is an Internet host using DHCP to
  76           obtain configuration parameters such as a network address.
  77
  78 DHCP server
  79           A DHCP server or "server" is an Internet host that returns
  80           configuration parameters to DHCP clients.
  81
  82 Home KDC  The KDC corresponding to the DHCP client's realm.
  83
  84 Local KDC The KDC corresponding to the DHCP server's realm.
  85
  86 3.2.  Requirements language
  87
  88 In this document, the key words "MAY", "MUST,  "MUST  NOT",  "optional",
  89 "recommended",  "SHOULD",  and  "SHOULD  NOT",  are to be interpreted as
  90 described in [1].
  91
  92 4.  Protocol overview
  93
  94 In DHCP authentication via Kerberos V, DHCP clients and servers utilize
  95 a Kerberos session key in order to compute a message integrity check
  96 value included within the DHCP authentication option. The message
  97 integrity check serves to authenticate as well as integrity protect the
  98 messages, while remaining compatible with the operation of a DHCP relay.
  99 Replay protection is also provided by a replay counter within the
 100 authentication option, as described in [3].
 101
 102 Each server maintains a list of session keys and identifiers for
 103 clients, so that the server can retrieve the session key and identifier
 104 used by a client to which the server has provided previous configuration
 105 information.  Each server MUST save the replay counter from the previous
 106 authenticated message. To avoid replay attacks, the server MUST discard
 107
 108
 109
 110 Hornstein, et al.            Standards Track                    [Page 2]
 111
 112
 113 INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
 114
 115
 116 any incoming message whose replay counter is not strictly greater than
 117 the replay counter from the previous message.
 118
 119 DHCP authentication, described in [3], must work within the existing
 120 DHCP state machine described in [4].  For a client in INIT state, this
 121 means that the client must obtain a valid TGT, as well as a session key,
 122 within the two round-trips provided by the
 123 DHCPDISCOVER/OFFER/REQUEST/ACK sequence.
 124
 125 In INIT state, the DHCP client submits an incomplete AS_REQ to the DHCP
 126 server within the DHCPDISCOVER message.  The DHCP server then completes
 127 the AS_REQ using the IP address to be assigned to the client, and
 128 submits this to the client's home KDC in order to obtain a TGT on the
 129 client's behalf. Once the home KDC responds with an AS_REP, the DHCP
 130 server extracts the client TGT and submits this along with its own TGT
 131 to the home KDC, in order to obtain a user-to-user ticket to the DHCP
 132 client. The AS_REP as well as the AP_REQ are included by the DHCP server
 133 in the DHCPOFFER. The DHCP client can then decrypt the AS_REP to obtain
 134 a home realm TGT and TGT session key, using the latter to decrypt the
 135 user-to-user ticket to obtain the user-to-user session key. It is the
 136 user-to-user session key that is used to authenticate and integrity
 137 protect the client's DHCPREQUEST, and DHCPDECLINE messages. Similarly,
 138 this same session key is used to compute the integrity attribute in the
 139 server's DHCPOFFER, DHCPACK and DHCPNAK messages, as described in [3].
 140
 141 In the INIT-REBOOT, REBINDING, or RENEWING states, the server can submit
 142 the home realm TGT in the DHCPREQUEST, along with authenticating and
 143 integrity protecting the message using an integrity attribute within the
 144 authentication option. The integrity attribute is computed using the
 145 existing session key.  The DHCP server can then return a renewed user-
 146 to-user ticket within the DHCPACK message. The authenticated DHCPREQUEST
 147 message from a client in INIT-REBOOT state can only be validated by
 148 servers that used the same session key to compute the integrity
 149 attribute in their DHCPOFFER messages.
 150
 151 Other servers will discard the DHCPREQUEST messages. Thus, only servers
 152 that used the user-to-user session key selected by the client will be
 153 able to determine that their offered configuration information was not
 154 selected, returning the offered network address to the server's pool of
 155 available addresses.  The servers that cannot validate the DHCPREQUEST
 156 message will eventually return their offered network addresses to their
 157 pool of available addresses as described in section 3.1 of the DHCP
 158 specification [4].
 159
 160 When sending a DHCPINFORM, there are two possible procedures.  If the
 161 client knows the DHCP server it will be interacting with, then it can
 162 obtain a ticket to the DHCP server from the local realm KDC. This will
 163 require obtaining a TGT to its home realm, as well as possibly a cross-
 164
 165
 166
 167 Hornstein, et al.            Standards Track                    [Page 3]
 168
 169
 170 INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
 171
 172
 173 realm TGT to the local realm if the local and home realms differ. Once
 174 the DHCP client has a local realm TGT, it can then request a DHCP server
 175 ticket in a TGS_REQ. The DHCP client can then include AP_REQ and
 176 integrity attributes within the DHCPINFORM. The integrity attribute is
 177 computed as described in [3], using the session key obtained from the
 178 TGS_REP. The DHCP server replies with a DHCPACK/DHCPNAK, authenticated
 179 using the same session key.
 180
 181 If the DHCP client does not know the DHCP server it is interacting with
 182 then it will not be able to obtain a ticket to it and a different
 183 procedure is needed.  In this case, the client will include in the
 184 DHCPINFORM an authentication option with a ticket attribute containing
 185 its home realm TGT. The DHCP server will then use this TGT in order to
 186 request a user-to-user ticket from the home KDC in a TGS_REQ.  The DHCP
 187 server will return the user-to-user ticket and will authenticate and
 188 integrity protect the DHCPACK/DHCPNAK message. This is accomplished by
 189 including AP_REQ and integrity attributes within the authentication
 190 option included with the DHCPACK/DHCPNAK messages.
 191
 192 In order to support the DHCP client's ability to authenticate the DHCP
 193 server in the case where the server name is unknown, the Kerberos
 194 principal name for the DHCP server must be of type KRB_NT_SRV_HST with
 195 the service name component equal to 'dhcp'. For example, the DHCP server
 196 principal name for the host srv.foo.org would be of the form
 197 dhcp/srv.foo.org.  The client MUST validate that the DHCP server
 198 principal name has the above format. This convention requires that the
 199 administrator ensure that non-DHCP server principals do not have names
 200 that match the above format.
 201
 202 4.1.  Authentication Option Format
 203
 204 A summary of the authentication option  format for DHCP authentication
 205 via Kerberos V is shown below.  The fields are transmitted from left to
 206 right.
 207
 208 0                   1                   2                   3
 209 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
 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 211 |     Code      |     Length    |   Protocol    | Algorithm     |
 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 213 |                      Global Replay Counter                    |
 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 215 |                      Global Replay Counter                    |
 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 217 |                           Attributes...
 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 219
 220 Code
 221
 222
 223
 224 Hornstein, et al.            Standards Track                    [Page 4]
 225
 226
 227 INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
 228
 229
 230    TBD - DHCP Authentication
 231
 232 Length
 233
 234    The length field is a single octet and indicates the length of the
 235    Protocol, Algorith, and Authentication Information fields.  Octets
 236    outside the range of the length field should be ignored on reception.
 237
 238 Protocol
 239
 240    TBD - DHCP Kerberos V authentication
 241
 242 Algorithm
 243
 244    The algorithm field is a single octet and defines the specific
 245    algorithm to be used for computation of the authentication option.
 246    Values for the field are as follows:
 247
 248    0 - reserved
 249    1 - HMAC-MD5
 250    2 - HMAC-SHA
 251    3 - 255 reserved
 252
 253 Global Replay Counter
 254
 255    As described in [3], the global replay counter field is 8 octets in
 256    length. It MUST be set to the value of a monotonically increasing
 257    counter. Using a counter value such as the current time of day (e.g.,
 258    an NTP-format timestamp [10]) can reduce the danger of replay
 259    attacks.
 260
 261 Attributes
 262
 263    The attributes field consists of type-length-value attributes of the
 264    following format:
 265
 266    0                   1                   2                   3
 267    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
 268    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 269    |     Type      |  Reserved     |       Payload Length          |
 270    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 271    |                           Attribute value...
 272    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 273
 274 Type
 275    The type field is a single octet and is defined as follows:
 276
 277    0  - Integrity check
 278
 279
 280
 281 Hornstein, et al.            Standards Track                    [Page 5]
 282
 283
 284 INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
 285
 286
 287    1  - TICKET
 288    2  - Authenticator
 289    3  - EncTicketPart
 290    10 - AS_REQ
 291    11 - AS_REP
 292    12 - TGS_REQ
 293    13 - TGS_REP
 294    14 - AP_REQ
 295    15 - AP_REP
 296    20 - KRB_SAFE
 297    21 - KRB_PRIV
 298    22 - KRB_CRED
 299    25 - EncASRepPart
 300    26 - EncTGSRepPart
 301    27 - EncAPRepPart
 302    28 - EncKrbPrvPart
 303    29 - EncKrbCredPart
 304    30 - KRB_ERROR
 305
 306    Note that the values of the Type field are the same as in the
 307    Kerberos MSG-TYPE field. As a result, no new number spaces are
 308    created for IANA administration.
 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 Hornstein, et al.            Standards Track                    [Page 6]
 339
 340
 341 INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
 342
 343
 344    The following attribute types are allowed within the following
 345    messages:
 346
 347    DISCOVER  OFFER  REQUEST  DECLINE   #    Attribute
 348    --------------------------------------------------------
 349       0        1       1        1      0    Integrity check
 350       0        0      0-1       0      1    Ticket
 351       1        0       0        0     10    AS_REQ
 352       0        1       0        0     11    AS_REP
 353       0        1       0        0     14    AP_REQ
 354       0       0-1      0        0     30    KRB_ERROR
 355
 356    RELEASE   ACK   NAK    INFORM   INFORM      #    Attribute
 357                           w/known  w/unknown
 358                           server   server
 359    ---------------------------------------------------------------
 360       1       1     1        1        0        0    Integrity check
 361       0       0     0        0        1        1    Ticket
 362       0       0     0        0        0       10    AS_REQ
 363       0       0     0        0        0       11    AS_REP
 364       0      0-1    0        1        0       14    AP_REQ
 365       0       0    0-1       0        0       30    KRB_ERROR
 366
 367 4.2.  Client behavior
 368
 369 The following section, which incorporates material from [3], describes
 370 client behavior in detail.
 371
 372 4.2.1.  INIT state
 373
 374 When in INIT state, the client behaves as follows:
 375
 376
 377 [1]  As described in [3], the client MUST include the authentication
 378      request option in its DHCPDISCOVER message along with option 61
 379      [11] to identify itself uniquely to the server. An AS_REQ attribute
 380      MUST be included within the authentication request option. This
 381      (incomplete) AS_REQ will set the FORWARDABLE and RENEWABLE flags
 382      and MAY include pre-authentication data (PADATA) if the client
 383      knows what PADATA its home KDC will require. The ADDRESSES field in
 384      the AS_REQ will be ommitted since the client does not yet know its
 385      IP address. The ETYPE field will be set to an encryption type that
 386      the client can accept.
 387
 388 [2]  The client MUST validate DHCPOFFER messages that include an
 389      authentication option. Messages including an authentication option
 390      with a KRB_ERROR attribute and no integrity attribute are treated
 391      as though they are unauthenticated. More typically, authentication
 392
 393
 394
 395 Hornstein, et al.            Standards Track                    [Page 7]
 396
 397
 398 INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
 399
 400
 401      options within the DHCPOFFER message will include AS_REP, AP_REQ,
 402      and integrity attributes. To validate the authentication option,
 403      the client decrypts the enc-part of the AS_REP in order to obtain
 404      the TGT session key. This is used to decrypt the enc-part of the
 405      AP_REQ in order to obtain the user-to-user session key. The user-
 406      to-user session key is then used to compute the message integrity
 407      check as described in [3], and the computed value is compared to
 408      the value within the integrity attribute. The client MUST discard
 409      any messages which fail to pass validation and MAY log the
 410      validation failure.
 411
 412      As described in [3], the client selects one DHCPOFFER message as
 413      its selected configuration. If none of the DHCPOFFER messages
 414      received by the client include an authentication option, the client
 415      MAY choose an unauthenticated message as its selected
 416      configuration.  DHCPOFFER messages including an authentication
 417      option with a KRB_ERROR attribute and no integrity attribute are
 418      treated as though they are unauthenticated.  The client SHOULD be
 419      configurable to accept or reject unauthenticated DHCPOFFER
 420      messages.
 421
 422 [3]  The client replies with a DHCPREQUEST message that MUST include an
 423      authentication option. The authentication option MUST include an
 424      integrity attribute, computed as described in [3], using the user
 425      to user session key recovered in step 2.
 426
 427 [4]  As noted in [3], the client MUST validate a DHCPACK message from
 428      the server that includes an authentication option. DHCPACK or
 429      DHCPNAK messages including an authentication option with a
 430      KRB_ERROR attribute and no integrity attribute are treated as
 431      though they are unauthenticated. The client MUST silently discard
 432      the DHCPACK if the message fails to pass validation and MAY log the
 433      validation failure. If the DHCPACK fails to pass validation, the
 434      client MUST revert to the INIT state and return to step 1. The
 435      client MAY choose to remember which server replied with an invalid
 436      DHCPACK message and discard subsequent messages from that server.
 437
 438 4.2.2.  INIT-REBOOT state
 439
 440 When in INIT-REBOOT state, if the user-to-user ticket is still valid,
 441 the client MUST re-use the session key from the DHCP server user-to-user
 442 ticket in its DHCPREQUEST message. This is used to generate the
 443 integrity attribute contained within the authentication option, as
 444 described in [3]. In the DHCPREQUEST, the DHCP client also includes its
 445 home realm TGT in a ticket attribute in the authentication option in
 446 order to assist the DHCP server in renewing the user-to-user ticket.  To
 447 ensure that the user-to-user ticket remains valid throughout the DHCP
 448 lease period so that the renewal process can proceed, the Kerberos
 449
 450
 451
 452 Hornstein, et al.            Standards Track                    [Page 8]
 453
 454
 455 INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
 456
 457
 458 ticket lifetime SHOULD be set to exceed the DHCP lease time.  If the
 459 user-to-user ticket is expired, then the client MUST return to the INIT
 460 state.
 461
 462 The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK messages
 463 if no authenticated messages were received. DHCPACK/DHCPNAK messages
 464 with an authentication option containing a KRB_ERROR attribute and no
 465 integrity attribute are treated as though they are unauthenticated. The
 466 client MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK
 467 messages as specified in section 3.2 of the DHCP specification [4].
 468
 469 4.2.3.  RENEWING state
 470
 471 When in RENEWING state, the DHCP client can be assumed to have a valid
 472 IP address, as well as a TGT to the home realm, a user-to-user ticket
 473 provided by the DHCP server, and a session key with the DHCP server, all
 474 obtained during the original DHCP conversation.  If the user-to-user
 475 ticket is still valid, the client MUST re-use the session key from the
 476 user-to-user ticket in its DHCPREQUEST message to generate the integrity
 477 attribute contained within the authentication option.
 478
 479 Since the DHCP client can renew the TGT to the home realm, it is
 480 possible for it to continue to hold a valid home realm TGT.  However,
 481 since the DHCP client did not obtain the user-to-user ticket on its own,
 482 it will need to rely on the DHCP server to renew this ticket. In the
 483 DHCPREQUEST, the DHCP client includes its home realm TGT in a ticket
 484 attribute in the authentication option in order to assist the DHCP
 485 server in renewing the user-to-user ticket.
 486
 487 If the DHCP server user-to-user ticket is expired, then the client MUST
 488 return to INIT state.  To ensure that the user-to-user ticket remains
 489 valid throughout the DHCP lease period so that the renewal process can
 490 proceed, the Kerberos ticket lifetime SHOULD be set to exceed the DHCP
 491 lease time.  If client receives no DHCPACK messages or none of the
 492 DHCPACK messages pass validation, the client behaves as if it had not
 493 received a DHCPACK message in section 4.4.5 of the DHCP specification
 494 [4].
 495
 496 4.2.4.  REBINDING state
 497
 498 When in REBINDING state, the DHCP client can be assumed to have a valid
 499 IP address, as well as a TGT to the home realm, a user-to-user ticket
 500 and a session key with the DHCP server, all obtained during the original
 501 DHCP conversation.  If the user-to-user ticket is still valid, the
 502 client MUST re-use the session key from the user-to-user ticket in its
 503 DHCPREQUEST message to generate the integrity attribute contained within
 504 the authentication option, as described in [3].
 505
 506
 507
 508
 509 Hornstein, et al.            Standards Track                    [Page 9]
 510
 511
 512 INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
 513
 514
 515 Since the DHCP client can renew the TGT to the home realm, it is
 516 possible for it to continue to hold a valid home realm TGT.  However,
 517 since the DHCP client did not obtain the user-to-user ticket on its own,
 518 it will need to rely on the DHCP server to renew this ticket. In the
 519 DHCPREQUEST, the DHCP client includes its home realm TGT in a ticket
 520 attribute in the authentication option in order to assist the DHCP
 521 server in renewing the user-to-user ticket.
 522
 523 If the user-to-user ticket is expired, then the client MUST return to
 524 INIT state.  To ensure that the user-to-user ticket remains valid
 525 throughout the DHCP lease period so that the renewal process can
 526 proceed, the Kerberos ticket lifetime SHOULD be set to exceed the DHCP
 527 lease time.  If client receives no DHCPACK messages or none of the
 528 DHCPACK messages pass validation, the client behaves as if it had not
 529 received a DHCPACK message in section 4.4.5 of the DHCP specification
 530 [4].
 531
 532 4.2.5.  DHCPRELEASE message
 533
 534 Clients sending a DHCPRELEASE MUST include an authentication option. The
 535 authentication option MUST include an integrity attribute, computed as
 536 described in [3], using the user to user session key.
 537
 538 4.2.6.  DHCPDECLINE message
 539
 540 Clients sending a DHCPDECLINE MUST include an authentication option. The
 541 authentication option MUST include an integrity attribute, computed as
 542 described in [3], using the user to user session key.
 543
 544 4.2.7.  DHCPINFORM message
 545
 546 Since the client already has some configuration information, it can be
 547 assumed that it has the ability to obtain a home or local realm TGT
 548 prior to sending the DHCPINFORM.
 549
 550 If the DHCP client knows which DHCP server it will be interacting with,
 551 then it SHOULD include an authentication option containing AP_REQ and
 552 integrity attributes within the DHCPINFORM.  The DHCP client first
 553 requests a TGT to the local realm via an AS_REQ and then using the TGT
 554 returned in the AS_REP to request a ticket to the DHCP server from the
 555 local KDC in a TGS_REQ. The session key obtained from the TGS_REP will
 556 be used to generate the integrity attribute as described in [3].
 557
 558 If the DHCP client does not know what DHCP server it will be talking to,
 559 then it cannot obtain a ticket to the DHCP server. In this case, the
 560 DHCP client MAY send an unauthenticated DHCPINFORM or it MAY include an
 561 authentication option including a ticket attribute only.  The ticket
 562 attribute includes a TGT for the home realm. The client MUST validate
 563
 564
 565
 566 Hornstein, et al.            Standards Track                   [Page 10]
 567
 568
 569 INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
 570
 571
 572 that the DHCP server name in the received Kerberos AP_REQ message is of
 573 the form dhcp/.... as described in section 4.
 574
 575 The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK messages
 576 if no authenticated messages were received. DHCPACK/DHCPNAK messages
 577 with an authentication option containing a KRB_ERROR attribute and no
 578 integrity attribute are treated as though they are unauthenticated. The
 579 client MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK
 580 messages as specified in section 3.2 of the DHCP specification [4].
 581
 582 4.3.  Server behavior
 583
 584 This section, which relies on material from [3], describes the behavior
 585 of a server in response to client messages.
 586
 587 4.3.1.  After receiving a DHCPDISCOVER message
 588
 589 For installations where IP addresses are required within tickets, the
 590 DHCP server MAY complete the AS_REQ by filling in the ADDRESSES field
 591 based on the IP address that it will include in the DHCPOFFER.  The DHCP
 592 server sends the AS_REQ to the home KDC with the FORWARDABLE flag set.
 593 The home KDC then replies to the DHCP server with an AS_REP.  The DHCP
 594 server extracts the client TGT from the AS_REP and forms a TGS_REQ,
 595 which it sends to  the home KDC.
 596
 597 If the DHCP server and client are in different realms, then the DHCP
 598 server will need to obtain a TGT to the home realm from the KDC of its
 599 own (local) realm prior to sending the TGS_REQ. The TGS_REQ includes the
 600 DHCP server's TGT within the home realm, has the ENC-TKT-IN-SKEY flag
 601 set and includes the client home realm TGT in the ADDITIONAL-TICKETS
 602 field, thus requesting a user-to ticket to the DHCP client.  The home
 603 KDC then returns a user-to-user ticket in a TGS_REP. The user-to-user
 604 ticket is encrypted in the client's home realm TGT session key.
 605
 606 In order to recover the user-to-user session key, the DHCP server
 607 decrypts the enc-part of the TGS_REP. To accomplish this, the DHCP
 608 server uses the session key that it shares with the home realm, obtained
 609 in the AS_REQ/AS_REP conversation that it used to obtain its own TGT to
 610 the home realm.
 611
 612 The DHCP server then sends a DHCPOFFER to the client, including AS_REP,
 613 AP_REQ and integrity attributes within the authentication option.  The
 614 AS_REP attribute encapsulates the AS_REP sent to the DHCP server by the
 615 home KDC. The AP_REQ attribute includes an AP_REQ constructed by the
 616 DHCP server based on the TGS_REP sent to it by the home KDC. The server
 617 also includes an integrity attribute generated as specified in [3] from
 618 the user-to-user session key.  The server MUST record the user-to-user
 619 session key selected for the client and use that session key for
 620
 621
 622
 623 Hornstein, et al.            Standards Track                   [Page 11]
 624
 625
 626 INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
 627
 628
 629 validating subsequent messages with the client.
 630
 631 4.3.2.  After receiving a DHCPREQUEST message
 632
 633 The DHCP server uses the user-to-user session key in order to validate
 634 the integrity attribute contained within the authentication option,
 635 using the method specified in [3]. If the message fails to pass
 636 validation, it MUST discard the message and MAY choose to log the
 637 validation failure.
 638
 639 If the message passes the validation procedure, the server responds as
 640 described in [4], including an integrity attribute computed as specified
 641 in [3] within the DHCPACK or DHCPNAK message.
 642
 643 If the authentication option included within the DHCPREQUEST message
 644 contains a ticket attribute then the DHCP server will use the home realm
 645 TGT included in the ticket attribute in order to renew the user-to-user
 646 ticket, which it returns in an AP_REQ attribute within the DHCPACK.
 647 DHCPACK or DHCPNAK messages then include an integrity attribute
 648 generated as specified in [3], using the new user-to-user session key
 649 included within the AP_REQ.
 650
 651 4.3.3.  After receiving a DHCPINFORM message
 652
 653 The server MAY choose to accept unauthenticated DHCPINFORM messages, or
 654 only accept authenticated DHCPINFORM messages based on a site policy.
 655
 656 When a client includes an authentication option in a DHCPINFORM message,
 657 the server MUST respond with an authenticated DHCPACK or DHCPNAK
 658 message. If the DHCPINFORM message includes an authentication option
 659 including AP_REQ and integrity attributes, the DHCP server decrypts the
 660 AP_REQ attribute and then recovers the session key. The DHCP server than
 661 validates the integrity attribute included in the authentication option
 662 using the session key. If the integrity attribute is invalid then the
 663 DHCP server MUST silently discard the DHCPINFORM message.
 664
 665 If the authentication option only includes a ticket attribute and no
 666 integrity or AP_REQ attributes, then the DHCP server should assume that
 667 the client needs the server to obtain a user-to-user ticket from the
 668 home realm KDC.  In this case, the DHCP server includes the client home
 669 realm TGT and its own home realm TGT in a TGS_REQ to the home realm KDC.
 670 It then receives a user-to-user ticket from the home realm KDC in a
 671 TGS_REP. The DHCP server will then include AP_REQ and integrity
 672 attributes within the DHCPACK/DHCPNAK.
 673
 674 If the client does not include an authentication option in the
 675 DHCPINFORM, the server can either respond with an unauthenticated
 676 DHCPACK message, or a DHCPNAK if the server does not accept
 677
 678
 679
 680 Hornstein, et al.            Standards Track                   [Page 12]
 681
 682
 683 INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
 684
 685
 686 unauthenticated clients.
 687
 688 4.3.4.  After receiving a DHCPRELEASE message
 689
 690 The DHCP server uses the session key in order to validate the integrity
 691 attribute contained within the authentication option, using the method
 692 specified in [3]. If the message fails to pass validation, it MUST
 693 discard the message and MAY choose to log the validation failure.
 694
 695 If the message passes the validation procedure, the server responds as
 696 described in [4], marking the client's network address as not allocated.
 697
 698 4.3.5.  After receiving a DHCPDECLINE message
 699
 700 The DHCP server uses the session key in order to validate the integrity
 701 attribute contained within the authentication option, using the method
 702 specified in [3]. If the message fails to pass validation, it MUST
 703 discard the message and MAY choose to log the validation failure.
 704
 705 If the message passes the validation procedure, the server proceeds as
 706 described in [4].
 707
 708 4.4.  Error handling
 709
 710 When an error condition occurs during a Kerberos exchange, Kerberos
 711 error messages can be returned by either side.  These Kerberos error
 712 messages MAY be logged by the receiving and sending parties.
 713
 714 In some cases, it may be possible for these error messages to be
 715 included within the authentication option via the KRB_ERROR attribute.
 716 However, in most cases, errors will result in messages being silently
 717 discarded and so no response will be returned.
 718
 719 For example, if the home KDC returns a KRB_ERROR in response to the
 720 AS_REQ submitted by the DHCP server on the client's behalf, then the
 721 DHCP server will conclude that the DHCPDISCOVER was not authentic, and
 722 will silently discard it.
 723
 724 However, if the AS_REQ included PADATA and the home KDC responds with an
 725 AS_REP, then the DHCP server can conclude that the client is authentic.
 726 If the subsequent TGS_REQ is unsuccessful, with a KRB_ERROR returned by
 727 the home KDC in the TGS_REP, then the fault may lie with the DHCP server
 728 rather than with the client. In this case, the DHCP server MAY choose to
 729 return a KRB_ERROR within the authentication option included in the
 730 DHCPOFFER. The client will then treat this as an unauthenticated
 731 DHCPOFFER.
 732
 733
 734
 735
 736
 737 Hornstein, et al.            Standards Track                   [Page 13]
 738
 739
 740 INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
 741
 742
 743 Similarly, if the integrity attribute contained in the DHCPOFFER proves
 744 invalid, the client will silently discard the DHCPOFFER and instead
 745 accept an offer from another server if one is available. If the
 746 integrity attribute included in the DHCPACK/DHCPNAK proves invalid, then
 747 the client behaves as if it did not receive a DHCPACK/DHCPNAK.
 748
 749 When in INIT-REBOOT, REBINDING or RENEWING state, the client will
 750 include a ticket attribute and integrity attribute within the
 751 authentication option of the DHCPREQUEST, in order to assist the DHCP
 752 server in renewing the user-to-user ticket.  If the integrity attribute
 753 is invalid, then the DHCP server MUST silently discard the DHCPREQUEST.
 754
 755 However, if the integrity attribute is successfully validated by the
 756 DHCP server, but the home realm TGT included in the ticket attribute is
 757 invalid (e.g. expired), then the DHCP server will receive a KRB_ERROR in
 758 response to its TGS_REQ to the home KDC.  In this case, the DHCP server
 759 MAY respond with a DHCPNAK including a KRB_ERROR attribute and no
 760 integrity attribute within the authentication option. This will force
 761 the client back to the INIT state, where it can receive a valid home
 762 realm TGT.
 763
 764 Where the client included PADATA in the AS_REQ attribute of the
 765 authentication option within the DHCPDISCOVER and the AS_REQ was
 766 successfully validated by the KDC, the DHCP server will conclude that
 767 the DHCP client is authentic. In this case if the client successfully
 768 validates the integrity attribute in the DHCPOFFER, but the server does
 769 not validate the integrity attribute in the client's DHCPREQUEST, the
 770 server MAY choose to respond with an authenticated DHCPNAK containing a
 771 KRB_ERROR attribute.
 772
 773 4.5.  PKINIT issues
 774
 775 When public key authentication is supported with Kerberos as described
 776 in [8], the client certificate and a signature accompany the initial
 777 request in the preauthentication fields.  As a result, it is conceivable
 778 that the incomplete AS_REQ included in the DHCPDISCOVER packet may
 779 exceed the size of a single DHCP option, or even the MTU size.  As noted
 780 in [4], a single option may be as large as 255 octets. If the value to
 781 be passed is larger than this the client concatenates together the
 782 values of multiple instances of the same option.
 783
 784 4.6.  Examples
 785
 786 4.6.1.  INIT state
 787
 788 In the intra-realm case where the DHCP Kerberos mutual authentication is
 789 successful, the conversation will appear as follows:
 790
 791
 792
 793
 794 Hornstein, et al.            Standards Track                   [Page 14]
 795
 796
 797 INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
 798
 799
 800    DHCP               DHCP
 801    Client             Server            KDC
 802 --------------     -------------     ---------
 803 DHCPDISCOVER
 804  (Incomplete
 805  AS_REQ)  ->
 806                    AS_REQ ->
 807                                       <- AS_REP
 808                    TGS_REQ
 809                     U-2-U ->
 810                                       <- TGS_REP
 811                 <- DHCPOFFER,
 812                     (AS_REP,
 813                     AP_REQ,
 814                     Integrity)
 815 DHCPREQUEST
 816  (Integrity) ->
 817                 <- DHCPACK
 818                     (Integrity)
 819
 820 In the case where the KDC returns a KRB_ERROR in response to the AS_REQ,
 821 the server will silently discard the DHCPDISCOVER and the conversation
 822 will appear as follows:
 823
 824    DHCP               DHCP
 825    Client             Server            KDC
 826 --------------     -------------     ---------
 827 DHCPDISCOVER
 828  (Incomplete
 829  AS_REQ)  ->
 830                    AS_REQ ->
 831                                      <- KRB_ERROR
 832
 833 In the inter-realm case where the DHCP Kerberos mutual authentication is
 834 successful, the conversation will appear as follows:
 835
 836    DHCP            DHCP           Home      Local
 837    Client          Server         KDC        KDC
 838 --------------  -------------  ---------  ---------
 839 DHCPDISCOVER
 840 (Incomplete
 841  AS_REQ)  ->
 842                    AS_REQ ->
 843                                 <- AS_REP
 844                    TGS_REQ ->
 845                    (cross realm,
 846                    for home
 847                    KDC)
 848
 849
 850
 851 Hornstein, et al.            Standards Track                   [Page 15]
 852
 853
 854 INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
 855
 856
 857                                            <- TGS_REP
 858
 859                    TGS_REQ
 860                     U-2-U ->
 861                                 <- TGS_REP
 862                 <- DHCPOFFER,
 863                     (AS_REP,
 864                     AP_REQ,
 865                     Integrity)
 866 DHCPREQUEST
 867  (Integrity) ->
 868                 <- DHCPACK
 869                     (Integrity)
 870
 871 In the case where the client includes PADATA in the AS_REQ attribute
 872 within the authentication option of the DHCPDISCOVER and the KDC returns
 873 an error-free AS_REP indicating successful validation of the PADATA, the
 874 DHCP server will conclude that the DHCP client is authentic.  If the KDC
 875 then returns a KRB_ERROR in response to the TGS_REQ, indicating a fault
 876 that lies with the DHCP server, the server MAY choose not to silently
 877 discard the DHCPDISCOVER.  Instead it MAY respond with a DHCPOFFER
 878 including a KRB_ERROR attribute within the authentication option. The
 879 client will then treat this as an unauthenticated DHCPOFFER.  The
 880 conversation will appear as follows:
 881
 882    DHCP               DHCP
 883    Client             Server            KDC
 884 --------------     -------------     ---------
 885 DHCPDISCOVER
 886  (Incomplete
 887  AS_REQ
 888  w/PADATA)  ->
 889                    AS_REQ ->
 890                                      <- AS_REP
 891                    TGS_REQ
 892                     U-2-U ->
 893                                      <- KRB_ERROR
 894                 <- DHCPOFFER,
 895                     (KRB_ERROR)
 896 DHCPREQUEST ->
 897                 <- DHCPACK
 898
 899 In the intra-realm case where the client included PADATA in the AS_REQ
 900 attribute of the authentication option and the AS_REQ was successfully
 901 validated by the KDC, the DHCP server will conclude that the DHCP client
 902 is authentic. In this case if the client successfully validates the
 903 integrity attribute in the DHCPOFFER, but the server does not validate
 904 the integrity attribute in the client's DHCPREQUEST, the server MAY
 905
 906
 907
 908 Hornstein, et al.            Standards Track                   [Page 16]
 909
 910
 911 INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
 912
 913
 914 choose to respond with an authenticated DHCPNAK containing a KRB_ERROR
 915 attribute.  The conversation will appear as follows:
 916
 917    DHCP               DHCP
 918    Client             Server            KDC
 919 --------------     -------------     ---------
 920 DHCPDISCOVER
 921  (Incomplete
 922  AS_REQ
 923  w/PADATA)  ->
 924                    AS_REQ ->
 925                                      <- AS_REP
 926                    TGS_REQ
 927                     U-2-U ->
 928                                      <- TGS_REP
 929                 <- DHCPOFFER,
 930                     (AS_REP,
 931                     AP_REQ,
 932                     Integrity)
 933 DHCPREQUEST
 934  (Integrity) ->
 935                 <- DHCNAK
 936                     (KRB_ERROR,
 937                      Integrity)
 938 DHCPDISCOVER
 939  (Incomplete
 940  AS_REQ)  ->
 941
 942 In the intra-realm case where the DHCP client cannot validate the
 943 integrity attribute in the DHCPOFFER, the client silently discards the
 944 DHCPOFFER. The conversation will appear as follows:
 945
 946    DHCP               DHCP
 947    Client             Server            KDC
 948 --------------     -------------     ---------
 949 DHCPDISCOVER
 950  (Incomplete
 951  AS_REQ)  ->
 952                    AS_REQ ->
 953                                      <- AS_REP
 954                    TGS_REQ
 955                     U-2-U ->
 956                                      <- TGS_REP
 957                 <- DHCPOFFER,
 958                    (AS_REP,
 959                    AP_REQ,
 960                    Integrity)
 961 DHCPREQUEST
 962
 963
 964
 965 Hornstein, et al.            Standards Track                   [Page 17]
 966
 967
 968 INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
 969
 970
 971  [To another server]
 972  (Integrity) ->
 973
 974 In the intra-realm case where the DHCP client cannot validate the
 975 integrity attribute in the DHCPACK, the client reverts to INIT state.
 976 The conversation will appear as follows:
 977
 978    DHCP               DHCP
 979    Client             Server            KDC
 980 --------------     -------------     ---------
 981 DHCPDISCOVER
 982 (Incomplete
 983  AS_REQ)  ->
 984                    AS_REQ ->
 985                                      <- AS_REP
 986                    TGS_REQ
 987                     U-2-U ->
 988                                      <- TGS_REP
 989                 <- DHCPOFFER,
 990                     (AS_REP,
 991                     AP_REQ,
 992                     Integrity)
 993 DHCPREQUEST
 994  (Integrity) ->
 995                 <- DHCPACK
 996                     (Integrity)
 997 DHCPDISCOVER
 998  (Incomplete
 999  AS_REQ)  ->
1000
1001 4.6.2.  INIT-REBOOT, RENEWING or REBINDING
1002
1003 In the intra-realm or inter-realm case where the original user-to-user
1004 ticket is still valid, and the DHCP server still has a valid TGT to the
1005 home realm, the conversation will appear as follows:
1006
1007    DHCP               DHCP             Home
1008    Client             Server            KDC
1009 --------------     -------------     ---------
1010
1011 DHCPREQUEST
1012  (TGT,
1013  Integrity)  ->
1014                    TGS_REQ
1015                     U-2-U ->
1016                                      <- TGS_REP
1017                 <- DHCPACK
1018                     (AP_REQ,
1019
1020
1021
1022 Hornstein, et al.            Standards Track                   [Page 18]
1023
1024
1025 INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
1026
1027
1028                     Integrity)
1029
1030 In the intra-realm or inter-realm case where the DHCP server validates
1031 the integrity attribute in the DHCPREQUEST, but receives a KRB_ERROR in
1032 response to the TGS_REQ to the KDC, the DHCP sever MAY choose not to
1033 silently discard the DHCPREQUEST and MAY return an authenticated DHCPNAK
1034 to the client instead, using the user-to-user session key previously
1035 established with the client. The conversation appears as follows:
1036
1037    DHCP               DHCP             Home
1038    Client             Server            KDC
1039 --------------     -------------     ---------
1040
1041 DHCPREQUEST
1042  (TGT,
1043  Integrity)  ->
1044                    TGS_REQ
1045                     U-2-U ->
1046                                      <- KRB_ERROR
1047                 <- DHCPNAK
1048                     (KRB_ERROR,
1049                     Integrity)
1050 DHCPDISCOVER
1051  (Incomplete
1052  AS_REQ)  ->
1053
1054 In the intra-realm or inter-realm case where the DHCP server cannot
1055 validate the integrity attribute in the DHCPREQUEST, the DHCP server
1056 MUST silently discard the DHCPREQUEST and the conversation will appear
1057 as follows:
1058
1059    DHCP               DHCP
1060    Client             Server            KDC
1061 --------------     -------------     ---------
1062
1063 DHCPREQUEST
1064  (TGT,
1065  Integrity)  ->
1066                    Silent discard
1067 [Sequence repeats
1068  until timeout]
1069
1070 DHCPDISCOVER
1071  (Incomplete
1072  AS_REQ)  ->
1073
1074 In the intra-realm or inter-realm case where the original user-to-user
1075 ticket is still valid, the server validates the integrity attribute in
1076
1077
1078
1079 Hornstein, et al.            Standards Track                   [Page 19]
1080
1081
1082 INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
1083
1084
1085 the DHCPREQUEST, but the client fails to validate the integrity
1086 attribute in the DHCPACK, the client will silently discard the DHCPACK.
1087 The conversation will appear as follows:
1088
1089    DHCP               DHCP
1090    Client             Server            KDC
1091 --------------     -------------     ---------
1092
1093 DHCPREQUEST
1094  (TGT,
1095  Integrity)  ->
1096
1097                 <- DHCPACK
1098                     (AP_REQ,
1099                     Integrity)
1100 DHCPDISCOVER
1101  (Incomplete
1102  AS_REQ)  ->
1103
1104 4.6.3.  DHCPINFORM (with known DHCP server)
1105
1106 In the case where the DHCP client knows the DHCP server it will be
1107 interacting with, the DHCP client will obtain a ticket to the DHCP
1108 server and will include AP_REQ and integrity attributes within the
1109 DHCPINFORM.
1110
1111 Where the DHCP Kerberos mutual authentication is successful, the
1112 conversation will appear as follows:
1113
1114    DHCP               DHCP
1115    Client             Server            KDC
1116 --------------     -------------     ---------
1117 AS_REQ ->
1118                                      <- AS_REP
1119 TGS_REQ ->
1120                                      <- TGS_REP
1121 DHCPINFORM
1122  (AP_REQ,
1123  Integrity) ->
1124                 <- DHCPACK
1125                     (Integrity)
1126
1127 In the inter-realm case where the DHCP Kerberos mutual authentication is
1128 successful, the conversation will appear as follows:
1129
1130    DHCP            DHCP           Home      Local
1131    Client          Server         KDC        KDC
1132 --------------  -------------  ---------  ---------
1133
1134
1135
1136 Hornstein, et al.            Standards Track                   [Page 20]
1137
1138
1139 INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
1140
1141
1142 AS_REQ ->
1143                                           <- AS_REP
1144 TGS_REQ ->
1145                                           <- TGS_REP
1146 TGS_REQ ->
1147                                <- TGS_REP
1148 DHCPINFORM
1149  (AP_REQ,
1150  Integrity) ->
1151                 <- DHCPACK
1152                     (Integrity)
1153
1154 In the inter-realm case where the DHCP server fails to validate the
1155 integrity attribute in the DHCPINFORM, the server MUST silently discard
1156 the DHCPINFORM. The conversation will appear as follows:
1157
1158    DHCP            DHCP           Home      Local
1159    Client          Server         KDC        KDC
1160 --------------  -------------  ---------  ---------
1161 AS_REQ ->
1162                                           <- AS_REP
1163 TGS_REQ ->
1164                                           <- TGS_REP
1165 TGS_REQ ->
1166                                <- TGS_REP
1167 DHCPINFORM
1168  (AP_REQ,
1169  Integrity) ->
1170                 <- DHCPACK
1171                     (Integrity)
1172 DHCPINFORM
1173  (AP_REQ,
1174  Integrity) ->
1175
1176 In the inter-realm case where the DHCP client fails to validate the
1177 integrity attribute in the DHCPACK, the client MUST silently discard the
1178 DHCPACK.  The conversation will appear as follows:
1179
1180    DHCP            DHCP           Home      Local
1181    Client          Server         KDC        KDC
1182 --------------  -------------  ---------  ---------
1183 AS_REQ ->
1184                                           <- AS_REP
1185 TGS_REQ ->
1186                                           <- TGS_REP
1187 TGS_REQ ->
1188                                <- TGS_REP
1189 DHCPINFORM
1190
1191
1192
1193 Hornstein, et al.            Standards Track                   [Page 21]
1194
1195
1196 INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
1197
1198
1199  (AP_REQ,
1200  Integrity) ->
1201
1202 4.6.4.  DHCPINFORM (with unknown DHCP server)
1203
1204 In the case where the DHCP client does not know the DHCP server it will
1205 be interacting with, the DHCP client will only include a ticket
1206 attribute within the DHCPINFORM.  Thus the DHCP server will not be able
1207 to validate the authentication option.
1208
1209 Where the DHCP client is able to validate the DHCPACK and no error
1210 occur, the onversation will appear as follows:
1211
1212    DHCP               DHCP
1213    Client             Server            KDC
1214 --------------     -------------     ---------
1215 AS_REQ ->
1216                                      <- AS_REP
1217 DHCPINFORM
1218  (Ticket) ->
1219                    TGS_REQ
1220                     U-2-U ->
1221                                      <- TGS_REP
1222                 <- DHCPACK
1223                     (AP_REQ,
1224                     Integrity)
1225
1226 In the inter-realm case where the DHCP server needs to obtain a TGT to
1227 the home realm, and where the client successfully validates the DHCPACK,
1228 the conversation will appear as follows:
1229
1230    DHCP            DHCP           Home      Local
1231    Client          Server         KDC        KDC
1232 --------------  -------------  ---------  ---------
1233 AS_REQ ->
1234                                           <- AS_REP
1235 DHCPINFORM
1236  (Ticket) ->
1237                    AS_REQ ->
1238                                 <- AS_REP
1239                    TGS_REQ ->
1240                    (cross realm,
1241                    for home
1242                    KDC)
1243                                            <- TGS_REP
1244
1245                    TGS_REQ
1246                     U-2-U ->
1247
1248
1249
1250 Hornstein, et al.            Standards Track                   [Page 22]
1251
1252
1253 INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
1254
1255
1256                                 <- TGS_REP
1257                 <- DHCPACK
1258                     (AP_REQ,
1259                     Integrity)
1260
1261 In the inter-realm case where the local KDC returns a KRB_ERROR in
1262 response to the TGS_REQ from the DHCP server, the DHCP server MAY return
1263 a KRB_ERROR within the DHCP authentication option included in a DHCPNAK.
1264 The conversation will appear as follows:
1265
1266    DHCP            DHCP           Home      Local
1267    Client          Server         KDC        KDC
1268 --------------  -------------  ---------  ---------
1269 AS_REQ ->
1270                                           <- AS_REP
1271 DHCPINFORM
1272  (Ticket) ->
1273                    AS_REQ ->
1274                                 <- AS_REP
1275                    TGS_REQ ->
1276                    (cross realm,
1277                    for home
1278                    KDC)
1279                                            <- KRB_ERROR
1280                 <- DHCPNAK
1281                     (KRB_ERROR)
1282
1283
1284 In the inter-realm case where the DHCP client fails to validate the
1285 integrity attribute in the DHCPACK, the client MUST silently discard the
1286 DHCPACK.  The conversation will appear as follows:
1287
1288    DHCP            DHCP           Home      Local
1289    Client          Server         KDC        KDC
1290 --------------  -------------  ---------  ---------
1291 AS_REQ ->
1292                                           <- AS_REP
1293 DHCPINFORM
1294  (Ticket) ->
1295                    AS_REQ ->
1296                                 <- AS_REP
1297                    TGS_REQ ->
1298                    (cross realm,
1299                    for home
1300                    KDC)
1301                                            <- TGS_REP
1302
1303                    TGS_REQ
1304
1305
1306
1307 Hornstein, et al.            Standards Track                   [Page 23]
1308
1309
1310 INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
1311
1312
1313                     U-2-U ->
1314                                 <- TGS_REP
1315                 <- DHCPACK
1316                     (AP_REQ,
1317                     Integrity)
1318 DHCPINFORM
1319  (Ticket) ->
1320
1321 5.  References
1322
1323
1324 [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
1325      Levels", BCP 14, RFC 2119, March 1997.
1326
1327 [2]  Kohl, J., Neuman, C., "The Kerberos Network Authentication Service
1328      (V5)", RFC 1510, September 1993.
1329
1330 [3]  Droms, R., Arbaugh, W., "Authentication for DHCP Messages",
1331      Internet draft (work in progress), draft-ietf-dhc-
1332      authentication-11.txt, June 1999.
1333
1334 [4]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March
1335      1997.
1336
1337 [5]  Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor
1338      Extensions", RFC 2132, March 1997.
1339
1340 [6]  Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
1341
1342 [7]  Jain, V., Congdon, P., Roese, J., "Network Port Authentication",
1343      IEEE 802.1 PAR submission, June 1999.
1344
1345 [8]  Tung, B., Neuman, C., Hur, M., Medvinsky, A., Medvinsky, S., Wray,
1346      J., Trostle, J., "Public Key Cryptography for Initial
1347      Authentication in Kerberos", Internet draft (work in progress),
1348      draft-ietf-cat-kerberos-pk-init-09.txt, June 1999.
1349
1350 [9]  Tung, B., Ryutov, T., Neuman, C., Tsudik, G., Sommerfeld, B.,
1351      Medvinsky, A., Hur, M.,  "Public Key Cryptography for Cross-Realm
1352      Authentication in Kerberos", Internet draft (work in progress),
1353      draft-ietf-cat-kerberos-pk-cross-04.txt, June 1999.
1354
1355 [10] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March
1356      1992.
1357
1358 [11] Henry, M., "DHCP Option 61 UUID Type Definition", Internet draft
1359      (work in progress), draft-henry-DHCP-opt61-UUID-type-00.txt,
1360      November 1998.
1361
1362
1363
1364 Hornstein, et al.            Standards Track                   [Page 24]
1365
1366
1367 INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
1368
1369
1370 6.  Security Considerations
1371
1372 DHCP authentication, described in [3], addresses the following threats:
1373
1374      Modification of messages
1375      Rogue servers
1376      Unauthorized clients
1377
1378 This section describes how DHCP authentication via Kerberos V addresses
1379 each of these threats.
1380
1381 6.1.  Client security
1382
1383 As noted in [3], it may be desirable to ensure that IP addresses are
1384 only allocated to authorized clients. This can serve to protect against
1385 denial of service attacks. To address this issue it is necessary for
1386 DHCP client messages to be authenticated. In order to guard against
1387 message modification, it is also necessary for DHCP client messages to
1388 be integrity protected.
1389
1390 Note that this protocol does not make use of KRB_SAFE, so as to allow
1391 modification of mutable fields by the DHCP relay. Replay protection is
1392 therefore provided within the DHCP authentication option itself.
1393
1394 In DHCP authentication via Kerberos V the DHCP client will authenticate,
1395 integrity and replay-protect the DHCPREQUEST, DHCPDECLINE and
1396 DHCPRELEASE messages using a user-to-user session key obtained by the
1397 DHCP server from the home KDC. If the DHCP client knows the DHCP server
1398 it will be interacting with, then the DHCP client MAY also authenticate,
1399 integrity and replay-protect the DHCPINFORM message using a session key
1400 obtained from the local realm KDC for the DHCP server it expects to
1401 converse with.
1402
1403 Since the client has not yet obtained a session key, DHCPDISCOVER
1404 packets cannot be authenticated using the session key. However, the
1405 client MAY include pre-authentication data in the PADATA field included
1406 in the DHCPDISCOVER packet. Since the PADATA will then be used by the
1407 DHCP server to request a ticket on the client's behalf, the DHCP server
1408 will learn from the AS_REP whether the PADATA was acceptable or not.
1409 Therefore in this case, the DHCPDISCOVER will be authenticated but not
1410 integrity protected.
1411
1412 Where the DHCP client does not know the DHCP server it will be
1413 interacting with ahead of time, the DHCPINFORM message will not be
1414 authenticated, integrity or replay protected.
1415
1416 Note that snooping of PADATA and TGTs on the wire may provide an
1417 attacker with a means of mounting a dictionary attack, since these items
1418
1419
1420
1421 Hornstein, et al.            Standards Track                   [Page 25]
1422
1423
1424 INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
1425
1426
1427 are typically encrypted with a key derived from the user's password.
1428 Thus use of strong passwords and/or pre-authentication methods utilizing
1429 strong cryptography (see [8]) are recommended.
1430
1431 6.2.  Network access control
1432
1433 DHCP authentication has been proposed as a method of limiting access to
1434 network media that are not physically secured such as wireless LANs and
1435 ports in college residence halls.  However, it is not particularly well
1436 suited to this purpose since even if address allocation is denied an
1437 inauthentic client may use a statically assigned IP address instead, or
1438 may attempt to access the network using non-IP protocols.  As a result,
1439 other methods, described in [6]-[7], have been proposed for controlling
1440 access to wireless media and switched LANs.
1441
1442 6.3.  Server security
1443
1444 As noted in [3], it may be desirable to protect against rogue DHCP
1445 servers put on the network either intentionally or by accident.  To
1446 address this issue it is necessary for DHCP server messages to be
1447 authenticated. In order to guard against message modification, it is
1448 also necessary for DHCP server messages to be integrity protected.
1449 Replay protection is also provided within the DHCP authentication
1450 option.
1451
1452 All messages sent by the DHCP server are authenticated and integrity and
1453 replaly protected using a session key.  This includes the DHCPOFFER,
1454 DHCPACK, and DHCPNAK messages.  The session key is used to compute the
1455 DHCP authentication option, which is verified by the client.
1456
1457 In order to provide protection against rogue servers it is necessary to
1458 prevent rogue servers from obtaining the credentials necessary to act as
1459 a DHCP server. As noted in Section 4, the Kerberos principal name for
1460 the DHCP server  must be of type KRB_NT_SRV_HST with  the service name
1461 component equal to 'dhcp'. The client MUST validate that the DHCP server
1462 principal name has the above  format. This convention requires that the
1463 administrator ensure that non-DHCP  server principals do not have names
1464 that match the above format.
1465
1466 7.  IANA Considerations
1467
1468 This draft does not create any new number spaces for IANA
1469 administration.
1470
1471 8.  Acknowledgements
1472
1473 The authors would like to acknowledge Ralph Droms and William Arbaugh,
1474 authors of the DHCP authentication draft [3]. This draft incorporates
1475
1476
1477
1478 Hornstein, et al.            Standards Track                   [Page 26]
1479
1480
1481 INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
1482
1483
1484 material from their work; however, any mistakes in this document are
1485 solely the responsibility of the authors.
1486
1487 9.  Authors' Addresses
1488
1489 Ken Hornstein
1490 US Naval Research Laboratory
1491 Bldg A-49, Room 2
1492 4555 Overlook Avenue
1493 Washington DC  20375 USA
1494
1495 Phone: +1 (202) 404-4765
1496 EMail: kenh@cmf.nrl.navy.mil
1497
1498 Ted Lemon
1499 Internet Engines, Inc.
1500 950 Charter Street
1501 Redwood City, CA 94063
1502
1503 Phone: +1 (650) 779 6031
1504 Email: mellon@iengines.net
1505
1506 Bernard Aboba
1507 Microsoft Corporation
1508 One Microsoft Way
1509 Redmond, WA 98052
1510
1511 Phone: +1 (425) 936-6605
1512 EMail: bernarda@microsoft.com
1513
1514 Jonathan Trostle
1515 170 W. Tasman Dr.
1516 San Jose, CA 95134, U.S.A.
1517
1518 Email: jtrostle@cisco.com
1519 Phone: +1 (408) 527-6201
1520
1521
1522 10.  Intellectual Property Statement
1523
1524 The IETF takes no position regarding the validity or scope of any
1525 intellectual property or other rights that might be claimed to  pertain
1526 to the implementation or use of the technology described in this
1527 document or the extent to which any license under such rights might or
1528 might not be available; neither does it represent that it has made any
1529 effort to identify any such rights.  Information on the IETF's
1530 procedures with respect to rights in standards-track and standards-
1531 related documentation can be found in BCP-11.  Copies of claims of
1532
1533
1534
1535 Hornstein, et al.            Standards Track                   [Page 27]
1536
1537
1538 INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
1539
1540
1541 rights made available for publication and any assurances of licenses to
1542 be made available, or the result of an attempt made to obtain a general
1543 license or permission for the use of such proprietary rights by
1544 implementors or users of this specification can be obtained from the
1545 IETF Secretariat.
1546
1547 The IETF invites any interested party to bring to its attention any
1548 copyrights, patents or patent applications, or other proprietary rights
1549 which may cover technology that may be required to practice this
1550 standard.  Please address the information to the IETF Executive
1551 Director.
1552
1553 11.  Full Copyright Statement
1554
1555 Copyright (C) The Internet Society (2000).  All Rights Reserved.
1556 This document and translations of it may be copied and furnished to
1557 others, and derivative works that comment on or otherwise explain it or
1558 assist in its implmentation may be prepared, copied, published and
1559 distributed, in whole or in part, without restriction of any kind,
1560 provided that the above copyright notice and this paragraph are included
1561 on all such copies and derivative works.  However, this document itself
1562 may not be modified in any way, such as by removing the copyright notice
1563 or references to the Internet Society or other Internet organizations,
1564 except as needed for the purpose of developing Internet standards in
1565 which case the procedures for copyrights defined in the Internet
1566 Standards process must be followed, or as required to translate it into
1567 languages other than English.  The limited permissions granted above are
1568 perpetual and will not be revoked by the Internet Society or its
1569 successors or assigns.  This document and the information contained
1570 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
1571 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
1572 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1573 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1574 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
1575
1576 12.  Expiration Date
1577
1578 This memo is filed as <draft-hornstein-dhc-kerbauth-02.txt>,  and
1579 expires October 1, 2000.
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592 Hornstein, et al.            Standards Track                   [Page 28]
1593
1594