- Complete re-write of sasc.
[dragonfly.git] / crypto / heimdal / doc / standardisation / draft-smedvinsky-dhc-kerbauth-01.txt
1
2
3 DHC Working Group                                          S. Medvinsky
4 Internet Draft                                                 Motorola
5 Document: <draft-smedvinsky-dhc-kerbauth-01.txt>
6 Category: Standards Track                                    P.Lalwaney
7 Expires: January 2001                                             Nokia
8
9                                                               July 2000
10
11
12         Kerberos V Authentication Mode for Uninitialized Clients
13
14
15 Status of this Memo
16
17    This document is an Internet-Draft and is in full conformance with
18    all provisions of Section 10 of RFC2026.
19
20    Internet-Drafts are working documents of the Internet Engineering
21    Task Force (IETF), its areas, and its working groups. Note that
22    other groups may also distribute working documents as Internet-
23    Drafts. Internet-Drafts are draft documents valid for a maximum of
24    six months and may be updated, replaced, or obsoleted by other
25    documents at any time. It is inappropriate to use Internet- Drafts
26    as reference material or to cite them other than as "work in
27    progress."
28
29    The list of current Internet-Drafts can be accessed at
30    http://www.ietf.org/ietf/1id-abstracts.txt
31
32    The list of Internet-Draft Shadow Directories can be accessed at
33    http://www.ietf.org/shadow.html.
34
35    The distribution of this memo is unlimited.  It is filed as <draft-
36    smedvinsky-dhc-kerbauth-01.txt>, and expires January 2001. Please
37    send comments to the authors.
38
39
40
41 1. Abstract
42
43    The Dynamic Host Configuration Protocol (DHCP) [1] includes an
44    option that allows authentication of all DHCP messages, as specified
45    in [2].  This document specifies a DHCP authentication mode based on
46    Kerberos V tickets. This provides mutual authentication between a
47    DHCP client and server, as well as authentication of all DHCP
48    messages.
49
50    This document specifies Kerberos message exchanges between an
51    uninitialized client and the KDC (Key Distribution Center) using an
52    IAKERB proxy [7] so that the Kerberos key management phase is
53    decoupled from, and precedes the address allocation and network
54    configuration phase that uses the DHCP authentication option.  In
55    order to make use of the IAKERB proxy, this document specifies a
56    transport mechanism that works with an uninitialized client (i.e. a
57 \f
58 Kerberos V Authentication Mode for Uninitialized Clients     July 2000
59
60
61    client without an assigned IP address). In addition, the document
62    specifies the format of the Kerberos authenticator to be used with
63    the DHCP authentication option.
64
65 2. Conventions used in this document
66
67    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
68    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
69    this document are to be interpreted as described in RFC-2119.
70
71 3. Introduction
72
73    3.1 Terminology
74
75    o "DHCP client"
76
77    A DHCP client is an Internet host using DHCP to obtain configuration
78    parameters such as a network address.
79
80    o "DHCP server"
81
82    A DHCP server is an Internet host that returns configuration
83    parameters to DHCP clients.
84
85    O "Ticket"
86
87    A Kerberos term for a record that helps a client authenticate itself
88    to a server; it contains the client's identity, a session key, a
89    timestamp, and other information, all sealed using the server's
90    secret key. It only serves to authenticate a client when presented
91    along with a fresh Authenticator.
92
93    o "Key Distribution Center"
94
95    Key Distribution Center, a network service that supplies tickets and
96    temporary session keys; or an instance of that service or the host
97    on which it runs. The KDC services both initial ticket and Ticket-
98    Granting Ticket (TGT) requests. The initial ticket portion is
99    sometimes referred to as the Authentication Server (or service. The
100    Ticket-Granting Ticket portion is sometimes referred to as the
101    Ticket-Granting Server (or service).
102
103    o "Realm"
104
105    A Kerberos administrative domain that represents a group of
106    principals registered at a KDC.  A single KDC may be responsible for
107    one or more realms.  A fully qualified principal name includes a
108    realm name along with a principal name unique within that realm.
109
110 3.2 Protocol Overview
111
112
113
114 S. Medvinsky, P. Lalwaney                                          -2-        
115 \f
116 Kerberos V Authentication Mode for Uninitialized Clients     July 2000
117
118
119    DHCP as defined in [1] defines the protocol exchanges for a client
120    to obtain its IP address and network configuration information from
121    a DHCP Server. Kerberos V5 as described in [6] defines the protocol
122    and message exchanges to mutually authenticate two parties. It is
123    our goal to provide authentication support for DHCP using Kerberos.
124    This implies that the Kerberos key management exchange has to take
125    place before a client gets its IP address from the DHCP Server.
126    Kerberos assumes that the client has a network address and can
127    contact the Key Distribution Center to obtain its credentials for
128    authenticated communication with an application server.
129
130    In this specification we utilize the key exchange using an IAKERB
131    proxy described in [7]. This does not require any changes to either
132    the IAKERB or the Kerberos V5 specification.  This document also
133    specifies a particular transport that allows an uninitialized client
134    to contact an IAKERB proxy.
135
136    The Kerberos ticket returned from the key management exchange
137    discussed in Section 5 of this document is passed to the DHCP Server
138    inside the DHCP authentication option with the new Kerberos
139    authenticator type. This is described in Section 6 of this draft.
140
141
142 3.3 Related Work
143
144    A prior Internet Draft [3] outlined the use of Kerberos-based
145    authentication for DHCP. The proposal tightly coupled the Kerberos
146    client state machines and the DHCP client state machines. As a
147    result, the Kerberos key management messages were carried in DHCP
148    messages, along with the Kerberos authenticators. In addition, the
149    first DHCP message exchange (request, offer) is not authenticated.
150
151    We propose a protocol exchange where Kerberos key management is
152    decoupled from and precedes authenticated DHCP exchanges. This
153    implies that the Kerberos ticket returned in the initial key
154    management exchange could be used to authenticate servers assigning
155    addresses by non-DHCP address assignment mechanisms like RSIP [4]
156    and for service specific parameter provisioning mechanisms using SLP
157    [5].
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172 S. Medvinsky, P. Lalwaney                                          -3-        
173 \f
174 Kerberos V Authentication Mode for Uninitialized Clients     July 2000
175
176
177
178 4. System Architecture
179
180
181      Client
182     --------                            --------
183    |        |   5.Authenticated DHCP   |        |
184    |  DHCP  |<------------------------>| DHCP   |
185    | client |                          | server |
186    |        |                          |        |
187    |        |                          |        |
188    |Kerberos|                          |        |
189    | Client |                          |        |
190     --------                            --------
191        ^
192        |
193        |
194        |
195        |                                -------
196         ------------------------------>|       |
197          Kerberos Key Mgmt             | Proxy |
198          messages:                     |       |
199           1. AS Request  / 2.AS Reply   -------
200           3. TGS Request / 4.TGS Reply     ^
201                                            | Kerberos
202                                            | Key Mgmt messages
203                                            v (1, 2, 3, 4)
204                                         --------
205                                        |        |
206                                        |  KDC   |
207                                        |        |
208                                         --------
209
210      Figure 1: System blocks and message interactions between them
211
212
213    In this architecture, the DHCP client obtains a Kerberos ticket from
214    the Key Distribution Center (KDC) using standard Kerberos messages,
215    as specified in [6].  The client, however, contacts the KDC via a
216    proxy server, according to the IAKERB mechanism, described in [7].
217    The are several reasons why a client has to go through this proxy in
218    order to contact the KDC:
219
220   a)The client may not know the host address of the KDC and may be
221      sending its first request message as a broadcast on a local
222      network.  The KDC may not be located on the local network, and
223      even if it were - it will be unable to communicate with a client
224      without an IP address.  This document describes a specific
225      mechanism that may be used by a client to communicate with the
226      Kerberos proxy.
227
228
229
230 S. Medvinsky, P. Lalwaney                                          -4-        
231 \f
232 Kerberos V Authentication Mode for Uninitialized Clients     July 2000
233
234
235   b)The client may not know its Kerberos realm name.  The proxy is
236      able to fill in the missing client realm name in an AS Request
237      message, as specified in IAKERB.  Note that in the case that
238      PKINIT pre-authenticator is used [8], the realm name in the AS
239      Request may be the KDC realm name and not the clientÆs realm name.
240
241   c) The client does not know the realm name of the DHCP server.
242
243      According to IAKERB, when the client sends a TGS Request with a
244      missing server realm name, the proxy will return to the client an
245      error message containing the missing realm name.
246
247      Note that in this case the proxy could return the client a wrong
248      realm name and the client could be fooled into obtaining a ticket
249      for the wrong DHCP server (on the same local network).  However,
250      the wrong DHCP server must still be a registered principal in a
251      KDC database.  In some circumstances this may be an acceptable
252      compromise.  Also, see the security considerations section.
253
254      IAKERB describes the proxy as part of an application server - the
255      DHCP server in this case.  However, in this document we are not
256      requiring the proxy to be integrated with the DHCP server.  The
257      same IAKERB mechanisms apply in the more general case, where the
258      proxy is an independent application.  This proxy, however, MUST be
259      reachable by a client via a local network broadcast.
260
261      After a client has obtained a Kerberos ticket for the DHCP server,
262      it will use it as part of an authentication option in the DHCP
263      messages.  The only extension to the DHCP protocol is the addition
264      of a new authenticator type based on Kerberos tickets.
265
266 4.1 Cross-Realm Authentication
267
268    Figure 1 shows a client communicating with a single KDC via a proxy.
269    However, the DHCP clientÆs realm may be different from the DHCP
270    serverÆs realm.  In that case, the client may need to first contact
271    the KDC in its local realm to obtain a cross-realm TGT.  Then, the
272    client would use the cross-realm TGT to contact the KDC in the DHCP
273    serverÆs realm, as specified in [6].
274
275    In the following example a client doesnÆt know its realm or the DHCP
276    serverÆs realm, which happens to be different from the clientÆs
277    realm.  Here are the steps in obtaining the ticket for the DHCP
278    server (based on [6] and [7]):
279
280         1) The client sends AS Request with NULL realm to the proxy.
281         2) The proxy fills in the realm and forwards the AS Request to
282            the KDC in the clientÆs realm.
283         3) The KDC issues a TGT and sends back an AS Reply to the
284            proxy.
285         4) The proxy forwards AS Reply to the client.
286
287
288 S. Medvinsky, P. Lalwaney                                          -5-        
289 \f
290 Kerberos V Authentication Mode for Uninitialized Clients     July 2000
291
292
293         5) The client sends TGS Request for a principal name "dhcpsrvr"
294            with NULL realm to the proxy.
295         6) The proxy returns KRB_AP_ERR_REALM_REQUIRED error with the
296            DHCP serverÆs realm to the client.
297         7) The client sends another TGS Request for a cross-realm TGT
298            to the proxy.
299         8) The proxy forwards the TGS Request to the KDC in the
300            clientÆs realm.
301         9) The KDC issues a cross-realm TGT and sends back a TGS Reply
302            to the proxy.
303        10) The proxy forwards TGS Reply to the client.
304        11) The client sends a TGS Request to the proxy for a principal
305        "dhcpsrvr" with the realm name filled in, using a cross-realm
306        TGT.
307        12) The proxy forwards TGS Request to the KDC in the DHCP      
308        server's realm.
309        13) The KDC issues a ticket for the DHCP server and sends TGS
310        Reply back to the proxy.
311        14) The proxy forwards TGS Reply to the client.
312
313    In a most general case, the client may need to contact any number of
314    KDCs in different realms before it can get a ticket for the DHCP
315    server.  In each case, the client would contact a KDC via the proxy
316    server, as specified in Section 5 of this document.
317
318 4.2 Public Key Authentication
319
320    This specification also allows clients to perform public key
321    authentication to the KDC, based on the PKINIT specification [8].
322    In this case, the size of an AS Request and AS Reply messages is
323    likely to exceed the size of typical link MTU's.
324
325    Here is an example, where PKINIT is used by a DHCP client that is
326    not a registered principal in the KDC principal database:
327
328         1) The client sends AS Request with a PKINIT Request pre-
329            authenticator to the proxy.  This includes the clientÆs
330            signature and X.509 certificate.  The KDC realm field is
331            left as NULL.
332         2) The proxy fills in the realm and forwards the AS Request to
333            the KDC in the filled in realm.  This is the realm of the
334            DHCP server.  Here, the clientÆs realm is the name of a
335            Certification Authority - not the same as the KDC realm.
336         3) The KDC issues a TGT and sends back an AS Reply with a
337            PKINIT Reply pre-authenticator to the proxy.
338         4) The proxy forwards the AS Reply to the client.
339         5) The client sends TGS Request for a principal name "dhcpsrvr"
340            with the realm found in the TGT to the proxy.
341         6) The proxy forwards TGS Request to the KDC in the DHCP
342            serverÆs realm.
343         7) The KDC issues a ticket for the DHCP server and sends TGS
344            Reply back to the proxy.
345
346 S. Medvinsky, P. Lalwaney                                          -6-        
347 \f
348 Kerberos V Authentication Mode for Uninitialized Clients     July 2000
349
350
351         8) The proxy forwards TGS Reply to the client.
352
353
354    5. Key Management Exchange that Precedes Network Address Allocation
355
356    An uninitialized host (e.g. on power-on and reset) does not have a
357    network address. It does have a link layer address or hardware
358    address. At this time, the client may not have any information on
359    its realm or the realm of the address allocation server (DHCP
360    Server).
361
362    In the Kerberos key management exchange, a client gets its ticket
363    granting ticket (TGT) by contacting the Authentication Server in the
364    KDC using the AS_Request / Reply messages (shown as messages 1 and 2
365    in Figure 1). The client then contacts the Ticket Granting Server in
366    the KDC to get the DHCP server ticket (to be used for mutual
367    authentication with the DHCP server) using the TGS_REQ / TGS_REP
368    messages (shown as messages 3 and 4 in the above figure).  It is
369    also possible for the client to obtain a DHCP server ticket directly
370    with the AS Request / Reply exchange, without the use of the TGT.
371
372    In the use of Kerberos for DHCP authentication, the client (a) does
373    not have an IP/network address (b) does not know he KDCÆs IP address
374    (c) the KDC may not be on the local network and (d) the client may
375    not know the DHCP ServerÆs IP address and realm.  We therefore
376    require a Kerberos proxy on the local network to accept broadcast
377    Kerberos request messages (AS_REQ and TGS_REQ) from uninitialized
378    clients and relay them to the appropriate KDC.
379
380    The uninitialized client formulates a broadcast AS_REQ or TGS_REQ as
381    follows:
382
383    The request payload contains the client hardware address in
384    addresses field with a negative value for the address type. Kerberos
385    v5 [6] allows for the usage of negative address types for "local"
386    use. Note that IAKERB [7] discourages the use of the addresses field
387    as network addresses may not be known or may change in situation
388    where proxies are used. In this draft we incorporate the negative
389    values permitted in the Kerberos transport in the address type field
390    of both the AS_REQ and TGS_REQ messages. The negative value SHOULD
391    be the negative number of the hardware address type "htype" value
392    (from assigned numbers RFC) used in RFC 2131. The address field of
393    the message contains the clients hardware address.
394
395    The request payload is UDP encapsulated and addressed to port 88 on
396    the server/proxy. The UDP source port is selected by the client. The
397    source and destination network addresses are the all-zeroÆs address
398    and the broadcast address, respectively. For IPv4, the source IP
399    address is set to 0.0.0.0 and the destination IP address is set to
400    255.255.255.255. The data link layer header source address
401    corresponds to the link layer/hardware address of the client. The
402
403
404 S. Medvinsky, P. Lalwaney                                          -7-        
405 \f
406 Kerberos V Authentication Mode for Uninitialized Clients     July 2000
407
408
409    destination link layer address is the broadcast address at the link
410    layer (e.g. for Ethernet the address is ffffffff).
411
412    In the case where AS_REQ message contains a PKINIT pre-authenticator
413    for public key-based client authentication (based on [8]), the
414    message will probably not fit into a single UDP packet given typical
415    link MTU's.
416
417    It is assumed that the proxy server on a network is configured with
418    a list of KDCÆs, their realms and their IP addresses. The proxy
419    server will act as a client to the KDC and forward standard Kerberos
420    messages to/from the KDC using unicast UDP or TCP transport
421    mechanisms, according to [6].
422
423    Upon receiving a broadcast request from a client, the proxy MUST
424    record the clientÆs hardware address that appears as the source
425    address on the frame as well as in the addresses field of the
426    request message. Based on the realm of the KDC specified in the
427    request, the proxy determines the KDC to which this message is
428    relayed as a unicast message from the proxy to the KDC.  In the case
429    that the client left the KDC realm name as NULL, it is up to the
430    proxy to first determine the correct realm name and fill it in the
431    request (according to [7]).
432
433    On receiving a request, the KDC formulates a response (AS_REP or
434    TGS_REP). It includes the clientÆs addresses field in the encrypted
435    part of the ticket (according to [6]). This response is unicast to
436    the proxy.
437
438    Upon receiving the reply, the proxy MUST first determine the
439    previously saved hardware address of the client.  The proxy
440    broadcasts the reply on its local network. This is a network layer
441    broadcast. At the link level, it uses the hardware address obtained
442    from the addresses field of the request.
443
444    The client on receiving the response (link layer destination address
445    as its hardware address, network layer address is the broadcast
446    address) must verify that the hardware address in the ticket
447    corresponds to its link layer address.
448
449    Upon receiving a TGS_REP (or an AS_REP with the application server
450    ticket) from the proxy, the client will have enough information to
451    securely communicate with the application server (the DHCP Server in
452    this case), as specified in the following section.
453
454
455
456
457
458
459
460
461
462 S. Medvinsky, P. Lalwaney                                          -8-        
463 \f
464 Kerberos V Authentication Mode for Uninitialized Clients     July 2000
465
466
467     6. Authenticated Message Exchange Between the DHCP Client and the
468    DHCP Server
469
470    The ticket returned in the TGS response is used by the DHCP client
471    in the construction of the Kerberos authenticator.  The Kerberos
472    ticket serves two purposes: to establish a shared session key with
473    the DHCP server, and is also included as part of a Kerberos
474    authenticator in the DHCP request.
475
476    If the size of the authenticator is greater than 255 bytes, the DHCP
477    authentication option is repeated multiple times.  When the values
478    of all the authentication options are concatenated together, they
479    will make up the complete authenticator.
480
481    Once the session key is established, the Kerberos structure
482    containing the ticket (AP REQ) can be omitted from the authenticator
483    for subsequent messages sent by both the DHCP client and the DHCP
484    server.
485
486    The Kerberos authenticator for a DHCP request message is specified
487    below:
488
489    0                   1                   2                   3
490    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
491    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
492    |     Code      |    Length     |    Protocol   |   Algorithm   |
493    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
494    |                                                               |
495    +              Replay Detection (64 bits)                       +
496    |                                                               |
497    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
498    |                                                               |
499    +              Authentication token (n octets)           ...    +
500    |                                                               |
501    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
502
503    The format of this authenticator is in accordance with [2]. The code
504    for the authentication option is TBD, and the length field contains
505    the length of the remainder of the option, starting with the
506    protocol field.
507
508    The value of the protocol field for this authenticator MUST be set
509    to 2.
510
511    The algorithm field MUST take one of the following values:
512         1 - HMAC-MD5
513         2 - HMAC-SHA-1
514
515    Replay protection field is a monotonically increasing counter field.
516    When the Kerberos AP REQ structure is present in the authenticator
517    the counter may be set to any value.  The AP REQ contains its own
518    replay protection mechanism in the form of a timestamp.
519
520 S. Medvinsky, P. Lalwaney                                          -9-        
521 \f
522 Kerberos V Authentication Mode for Uninitialized Clients     July 2000
523
524
525
526    Once the session key has been established and the AP REQ is not
527    included in the authenticator, this field MUST be monotonically
528    increasing in the messages sent by the client.
529
530    Kerberos authenticator token consists of type-length-value
531    attributes:
532
533    0                   1                   2                   3
534    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
535    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
536    |     Type      |  Reserved     |       Payload Length          |
537    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
538    |                           attribute value...
539    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
540
541    The following attributes are included in the Kerberos authenticator
542    token:
543
544    Type         Attribute Name          Value
545    --------------------------------------------------------------------
546    0            Message Integrity Code  Depends on the value of the
547                                         algorithm field.  Its length is
548                                         16 bytes for HMAC-MD5 [9, 10]
549                                         and 20 bytes for HMAC-SHA-1
550                                         [11, 10].  The HMAC key must be
551                                         derived from Kerberos session
552                                         key found in the Kerberos
553                                         ticket according to the key
554                                         derivation rules in [6]:
555
556                                           HMAC Key = DK(sess key,
557                                                       key usage | 0x99)
558
559                                         Here, DK is defined in [12] and
560                                         the key usage value for DHCP is
561                                         TBD.
562
563                                         The HMAC is calculated over the
564                                         entire DHCP message. The
565                                         Message Integrity Code
566                                         attribute MUST be set to all 0s
567                                         for the computation of the
568                                         HMAC.  Because a DHCP relay
569                                         agent may alter the values of
570                                         the 'giaddr' and 'hops' fields
571                                         in the DHCP message, the
572                                         contents of those two fields
573                                         MUST also be set to zero for
574                                         the computation of the HMAC.
575                                         Rules specified in Section 3 of
576                                         [2] for the exclusion and
577
578 S. Medvinsky, P. Lalwaney                                         -10-        
579 \f
580 Kerberos V Authentication Mode for Uninitialized Clients     July 2000
581
582
583                                         processing of the relay agent
584                                         information are applicable here
585                                         too.
586
587                                         This field MUST always be
588                                         present in the Kerberos
589                                         authenticator.
590
591    1            AP_REQ                  ASN.1 encoding of a Kerberos
592                                         AP_REQ message, as specified
593                                         in [6]. This MUST be included
594                                         by the client when establishing
595                                         a new session key.  In all
596                                         other cases, this attribute
597                                         MUST be omitted.
598
599    AP_REQ contains the Kerberos ticket for the DHCP server and also
600    contains information needed by the DHCP server to authenticate the
601    client.  After verifying the AP_REQ and decrypting the Kerberos
602    ticket, the DHCP server is able to extract a session key which it
603    now shares with the DHCP client.
604
605    The Kerberos authenticator token contains its own replay protection
606    mechanism inside the AP_REQ structure.  The AP_REQ contains a
607    timestamp that must be within an agreed upon time window at the DHCP
608    server.  However, this does not require the DHCP clients to maintain
609    an accurate clock between reboots.  Kerberos allows clients to
610    synchronize their clock with the KDC with the help of Kerberos
611    KRB_AP_ERR_SKEW error message, as specified in [6].
612
613    The DHCP server MUST save both the session key and its associated
614    expiration time found in the Kerberos ticket.  Up until the
615    expiration time, the server must accept client requests with the
616    Kerberos authenticator that does not include the AP REQ, using the
617    saved session key in calculating HMAC values.
618
619    The Kerberos authenticator inside all DHCP server responses MUST NOT
620    contain the AP REQ and MUST use the saved Kerberos session key in
621    calculating HMAC values.
622
623    When the session key expires, it is the client's responsibility to
624    obtain a new ticket from the KDC and to include an AP REQ inside the
625    Kerberos authenticator for the next DHCP request message.
626
627
628
629
630
631
632
633
634
635
636 S. Medvinsky, P. Lalwaney                                         -11-        
637 \f
638 Kerberos V Authentication Mode for Uninitialized Clients     July 2000
639
640
641 7. Detailed message flows for Kerberos and DHCP message Exchanges
642
643    The following flow depicts the Kerberos exchange in which a AS REQ
644    message is used to directly request the DHCP Server ticket. There
645    are no changes to transport mechanisms below when the additional
646    phase of using TGS requests/responses with TGTÆs is used.
647
648    Client                         IAKERB Proxy                 KDC
649
650    KB-client-------- AS_REQ ------>
651
652    AS REQ Address type = - (htype)
653    AS REQ Address= hw address
654
655    src UDP port = senders port
656    destination UDP port = 88
657
658    src IP = 0.0.0.0
659    destination IP = 255.255.255.255
660
661    src link layer address =
662    clientÆs HW/link address [e.g Ethernet address]
663
664    destination link layer address =
665    link broadcast address [e.g. ffffffff for Ethernet]
666
667
668                                          --------------------------->
669                                             (unicast to UDP port 88)
670
671
672
673                                           <--------------------------
674                                              (unicast AS REP)
675                                          Encrypted portion of ticket
676                                          Includes clients HW address
677
678
679       <---------------AS_REP -----------
680
681
682      Ticket includes clientÆs hardware address
683
684      src UDP port = 88
685      destination UDP port = copied from src port in AS_REQ
686
687      src IP = ProxyÆs IP address
688      destination IP = 255.255.255.255
689
690      src link layer address = ProxyÆs HW/link address
691      destination link layer address =
692          ClientÆs link layer address from AS_REQ
693
694
695 S. Medvinsky, P. Lalwaney                                         -12-        
696 \f
697 Kerberos V Authentication Mode for Uninitialized Clients     July 2000
698
699
700
701
702
703     The client uses the ticket received from the KDC in the DHCP
704 Authentication option as described in Section 6.
705
706
707      Client
708      DHCP-client                                   DHCP Server
709
710              ------DHCPDISCOVER ---->
711              (Auth Protocol = 2, includes Kerberos
712               authenticator with AP REQ )
713                                    -----------------------------------
714                                    |  HMAC  |     AP   REQ           |
715                                     ----------------------------------
716                                             | Ticket| Client Authent |
717                                             --------------------------
718
719                                          1. Server decrypts ticket
720                                          (inside AP REQ) with service
721                                          key
722                                          2. Server decrypts client
723                                          authenticator (inside AP REQ)
724                                          and checks content and
725                                          checksum to validate the
726                                          client.
727                                          3. Recompute HMAC with session
728                                          key and compare.
729
730
731           <-------DHCPOFFER----------
732           (Auth Protocol = 2, no AP REQ )
733
734
735
736          ---------DHCPREQUEST------->
737          (Auth Protocol = 2, no AP REQ)
738
739
740           <--------DHCPACK-------------
741            (Auth Protocol = 2, no AP REQ )
742
743
744
745
746 8. Security Considerations
747
748    DHCP clients that do not know the DHCP serverÆs realm name will get
749    it from the proxy, as specified in IAKERB [7].  Since the proxy is
750    not authenticated, a DHCP client can be fooled into obtaining a
751    ticket for the wrong DHCP server in the wrong realm.
752
753 S. Medvinsky, P. Lalwaney                                         -13-        
754 \f
755 Kerberos V Authentication Mode for Uninitialized Clients     July 2000
756
757
758
759    This could happen when the client leaves out the server realm name
760    in a TGS Request message to the proxy.  It is also possible,
761    however, for a client to directly request a DHCP server ticket with
762    an AS Request message.  In those cases, the same situation occurs
763    when the client leaves out the realm name in an AS Request.
764
765    This wrong DHCP server is still registered as a valid principal in a
766    database of a KDC that can be trusted by the client.  In some
767    circumstances a client may assume that a DHCP server that is a
768    Kerberos principal registered with a trusted KDC will not attempt to
769    deliberately misconfigure a client.
770
771    This specification provides a tradeoff between:
772
773         1) The DHCP clients knowing DHCP serverÆs realm ahead of time,
774            which provides for full 2-way authentication at the cost of
775            an additional configuration parameter.
776         2) The DHCP clients not requiring any additional configuration
777            information, besides a password or a key (and a public key
778            certificate if PKINIT is used).  This is at the cost of not
779            being able to fully authenticate the identity of the DHCP
780            server.
781
782
783
784 9. References
785
786
787    [1]Droms, R., Arbaugh, W., "Dynamic Host Configuration Protocol",
788       RFC 2131, Bucknell University, March 1997.
789
790    [2]Droms, R., Arbaugh, W., "Authentication for DHCP Messages",
791       draft-ietf-dhc-authentication-13.txt, June 2000.
792
793    [3]Hornstein, K., Lemon, T., "DHCP Authentication Via Kerberos V",
794       draft-hornstein-dhc-kerbauth-02.txt, February 2000.
795
796    [4]Borella, M., Grabelsky, D., Lo, J., Tuniguchi, K., "Realm
797       Specific IP: Protocol Specification ", draft-ietf-nat-rsip-
798       protocol-06.txt, March 2000.
799
800    [5]Guttman, E., Perkins, C., Veizades, J., Day, M., "Service
801       Location Protocol, Version 2", RFC 2608, June 1999.
802
803    [6]Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network
804       Authentication Service (V5)", draft-ietf-cat-kerberos-revisions-
805       05.txt, March 2000.
806
807
808
809
810
811 S. Medvinsky, P. Lalwaney                                         -14-        
812 \f
813 Kerberos V Authentication Mode for Uninitialized Clients     July 2000
814
815
816
817    [7]Swift, M., Trostle, J., "Initial Authentication and Pass Through
818       Authentication Using Kerberos V5 and the GSS-API (IAKERB)",
819       draft-ietf-cat-iakerb-03.txt, September 1999.
820
821    [8]Tung, B., C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray,
822       J. Trostle, "Public Key Cryptography for Initial Authentication
823       in Kerberos", draft-ietf-cat-pk-init-11.txt, March 2000.
824
825    [9]Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
826       1992.
827
828    [10]Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for
829       Message Authentication," RFC 2104, February 1997.
830
831    [11]NIST, FIPS PUB 180-1, "Secure Hash Standard", April 1995.
832
833    [12]Horowitz, M., "Key Derivation for Authentication, Integrity, and
834       Privacy", draft-horowitz-key-derivation-02.txt, August 1998.
835
836    [13]Bradner, S. "The Internet Standards Process -- Revision 3", RFC
837    2026.
838
839
840
841  10. Author's Addresses
842
843    Sasha Medvinsky
844    Motorola
845    6450 Sequence Drive
846    San Diego, CA 92121
847    Email: smedvinsky@gi.com
848
849    Poornima Lalwaney
850    Nokia
851    12278 Scripps Summit Drive
852    San Diego, CA  92131
853    Email: poornima.lalwaney@nokia.com
854
855
856 11. Expiration
857
858    This memo is filed as <draft-smedvinsky-dhc-kerbauth-01.txt>, and
859    expires January 1, 2001.
860
861
862
863 12. Intellectual Property Notices
864
865
866
867
868
869
870 S. Medvinsky, P. Lalwaney                                         -15-        
871 \f
872 Kerberos V Authentication Mode for Uninitialized Clients    March 2000
873
874
875       This section contains two notices as required by [13] for
876    standards track documents.  Per [13], section 10.4(A):
877
878      The IETF takes no position regarding the validity or scope of any
879    intellectual property or other rights that might be claimed to
880    pertain to the implementation or use of the technology described in
881    this document or the extent to which any license under such rights
882    might or might not be available; neither does it represent that it
883    has made any effort to identify any such rights. Information on the
884    IETF's procedures with respect to rights in standards-track and
885    standards-related documentation can be found in BCP-11. Copies of
886    claims of rights made available for publication and any assurances
887    of licenses to be made available, or the result of an attempt made
888    to obtain a general license or permission for the use of such
889    proprietary rights by implementers or users of this specification
890    can be obtained from the IETF Secretariat.
891
892       Per [13] section 10.4(D):
893
894       The IETF has been notified of intellectual property rights
895    claimed in regard to some or all of the specification contained in
896    this document.  For more information consult the online list of
897    claimed rights.
898
899    13. Full Copyright Statement
900
901    Copyright (C) The Internet Society (1999).  All Rights Reserved.
902
903    This document and translations of it may be copied and furnished to
904    others, and derivative works that comment on or otherwise explain it
905    or assist in its implementation may be prepared, copied, published
906    and distributed, in whole or in part, without restriction of any
907    kind, provided that the above copyright notice and this paragraph
908    are included on all such copies and derivative works.  However, this
909    document itself may not be modified in any way, such as by removing
910    the copyright notice or references to the Internet Society or other
911    Internet organizations, except as needed for the purpose of
912    developing Internet standards in which case the procedures for
913    copyrights defined in the Internet Standards process must be
914    followed, or as required to translate it into languages other than
915    English.  The limited permissions granted above are perpetual and
916    will not be revoked by the Internet Society or its successors or
917    assigns. This document and the information contained herein is
918    provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
919    INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
920    IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
921    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
922    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
923
924
925
926
927
928 S. Medvinsky, P. Lalwaney                                         -16-
929 \f