1
2
3NETWORK WORKING GROUP                                             L. Zhu
4Internet-Draft                                     Microsoft Corporation
5Updates: 4120 (if approved)                                    J. Altman
6Intended status: Standards Track                        Secure Endpoints
7Expires: January 10, 2008                                   July 9, 2007
8
9
10 Initial and Pass Through Authentication Using Kerberos V5 and the GSS-
11                              API (IAKERB)
12                          draft-zhu-ws-kerb-03
13
14Status of this Memo
15
16   By submitting this Internet-Draft, each author represents that any
17   applicable patent or other IPR claims of which he or she is aware
18   have been or will be disclosed, and any of which he or she becomes
19   aware will be disclosed, in accordance with Section 6 of BCP 79.
20
21   Internet-Drafts are working documents of the Internet Engineering
22   Task Force (IETF), its areas, and its working groups.  Note that
23   other groups may also distribute working documents as Internet-
24   Drafts.
25
26   Internet-Drafts are draft documents valid for a maximum of six months
27   and may be updated, replaced, or obsoleted by other documents at any
28   time.  It is inappropriate to use Internet-Drafts as reference
29   material or to cite them other than as "work in progress."
30
31   The list of current Internet-Drafts can be accessed at
32   http://www.ietf.org/ietf/1id-abstracts.txt.
33
34   The list of Internet-Draft Shadow Directories can be accessed at
35   http://www.ietf.org/shadow.html.
36
37   This Internet-Draft will expire on January 10, 2008.
38
39Copyright Notice
40
41   Copyright (C) The IETF Trust (2007).
42
43Abstract
44
45   This document defines extensions to the Kerberos protocol and the
46   GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to
47   exchange messages with the KDC using the GSS-API acceptor as the
48   proxy, by encapsulating the Kerberos messages inside GSS-API tokens.
49   With these extensions a client can obtain Kerberos tickets for
50   services where the KDC is not accessible to the client, but is
51
52
53
54Zhu & Altman            Expires January 10, 2008                [Page 1]
55
56Internet-Draft                   IAKERB                        July 2007
57
58
59   accessible to the application server.
60
61
62Table of Contents
63
64   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
65   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
66   3.  GSS-API Encapsulation  . . . . . . . . . . . . . . . . . . . .  3
67   4.  Addresses in Tickets . . . . . . . . . . . . . . . . . . . . .  7
68   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
69   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
70   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
71   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
72     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
73     8.2.  Informative references . . . . . . . . . . . . . . . . . .  9
74   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9
75   Intellectual Property and Copyright Statements . . . . . . . . . . 11
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110Zhu & Altman            Expires January 10, 2008                [Page 2]
111
112Internet-Draft                   IAKERB                        July 2007
113
114
1151.  Introduction
116
117   When authenticating using Kerberos V5, clients obtain tickets from a
118   KDC and present them to services.  This model of operation cannot
119   work if the client does not have access to the KDC.  For example, in
120   remote access scenarios, the client must initially authenticate to an
121   access point in order to gain full access to the network.  Here the
122   client may be unable to directly contact the KDC either because it
123   does not have an IP address, or the access point packet filter does
124   not allow the client to send packets to the Internet before it
125   authenticates to the access point.
126
127   Recent advancements in extending Kerberos permit Kerberos
128   authentication to complete with the assistance of a proxy.  The
129   Kerberos [RFC4120] pre-authentication framework [KRB-PAFW] prevents
130   the exposure of weak client keys over the open network.  The Kerberos
131   support of anonymity [KRB-ANON] provides for privacy and further
132   complicates traffic analysis.  The kdc-referrals option defined in
133   [KRB-PAFW] may reduce the number of messages exchanged while
134   obtaining a ticket to exactly two even in cross-realm
135   authentications.
136
137   Building upon these Kerberos extensions, this document extends
138   [RFC4120] and [RFC4121] such that the client can communicate with the
139   KDC using a Generic Security Service Application Program Interface
140   (GSS-API) [RFC2743] acceptor as the proxy.  The GSS-API acceptor
141   relays the KDC request and reply messages between the client and the
142   KDC.  The GSS-API acceptor, when relaying the Kerberos messages, is
143   called an IAKERB proxy.  Consequently, IAKERB as defined in this
144   document requires the use of GSS-API.
145
146
1472.  Conventions Used in This Document
148
149   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
150   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
151   document are to be interpreted as described in [RFC2119].
152
153
1543.  GSS-API Encapsulation
155
156   The mechanism Objection Identifier (OID) for GSS-API IAKERB, in
157   accordance with the mechanism proposed by [RFC4178] for negotiating
158   protocol variations, is id-kerberos-iakerb:
159
160      id-kerberos-iakerb ::=
161        { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
162          iakerb(5) }
163
164
165
166Zhu & Altman            Expires January 10, 2008                [Page 3]
167
168Internet-Draft                   IAKERB                        July 2007
169
170
171   The initial context establishment token of IAKERB MUST have the
172   generic token framing described in section 3.1 of [RFC2743] with the
173   mechanism OID being id-kerberos-iakerb, and any subsequent IAKERB
174   context establishment token MUST NOT have this token framing.
175
176   The client starts by constructing the ticket request, and if the
177   ticket request is being made to the KDC, the client, instead of
178   contacting the KDC directly, encapsulates the request message into
179   the output token of the GSS_Init_security_context() call and returns
180   GSS_S_CONTINUE_NEEDED [RFC2743] indicating that at least one more
181   token is required in order to establish the context.  The output
182   token is then passed for use as the input token to the
183   GSS_Accept_sec_context() call in accordance with GSS-API.  The GSS-
184   API acceptor extracts the Kerberos request in the input token,
185   locates the target KDC, and sends the request on behalf of the
186   client.  After receiving the KDC reply, the GSS-API acceptor then
187   encapsulates the reply message into the output token of
188   GSS_Accept_sec_context().  The GSS-API acceptor returns
189   GSS_S_CONTINUE_NEEDED [RFC2743] indicating that at least one more
190   token is required in order to establish the context.  The output
191   token is passed to the initiator in accordance with GSS-API.
192
193          Client <---------> IAKERB proxy <---------> KDC
194
195   The innerToken described in section 3.1 of [RFC2743] and subsequent
196   GSS-API mechanism tokens have the following formats: it starts with a
197   two-octet token-identifier (TOK_ID), followed by an IAKERB message or
198   a Kerberos message.
199
200   Only one IAKERB specific message, namely the IAKERB_PROXY message, is
201   defined in this document.  The TOK_ID values for Kerberos messages
202   are the same as defined in [RFC4121].
203
204                 Token          TOK_ID Value in Hex
205              --------------------------------------
206               IAKERB_PROXY           05 01
207
208   The content of the IAKERB_PROXY message is defined as an IAKERB-
209   HEADER structure immediately followed by a Kerberos message.  The
210   Kerberos message can be an AS-REQ, an AS-REP, a TGS-REQ, a TGS-REP,
211   or a KRB-ERROR as defined in [RFC4120].
212
213
214
215
216
217
218
219
220
221
222Zhu & Altman            Expires January 10, 2008                [Page 4]
223
224Internet-Draft                   IAKERB                        July 2007
225
226
227           IAKERB-HEADER ::= SEQUENCE {
228               target-realm      [1] UTF8String,
229                  -- The name of the target realm.
230               cookie            [2] OCTET STRING OPTIONAL,
231                  -- Opaque data, if sent by the server,
232                  -- MUST be copied by the client verbatim into
233                  -- the next IAKRB_PROXY message.
234               ...
235           }
236
237   The IAKERB-HEADER structure and all the Kerberos messages MUST be
238   encoded using Abstract Syntax Notation One (ASN.1) Distinguished
239   Encoding Rules (DER) [X680] [X690].
240
241   The IAKERB client fills out the IAKERB-HEADER structure as follows:
242   the target-realm contains the realm name the ticket request is
243   addressed to.  In the initial message from the client, the cookie
244   field is absent.  The client MUST specify a target-realm.  If the
245   client does not know the realm of the client's true principal name
246   [REFERALS], it MUST specify a realm it knows.  This can be the realm
247   of the client's host.
248
249   Upon receipt of the IAKERB_PROXY message, the GSS-API acceptor
250   inspects the target-realm field in the IAKERB_HEADER, and locates a
251   KDC of that realm, and sends the ticket request to that KDC.
252
253   When the GSS-API acceptor is unable to obtain an IP address for a KDC
254   in the client's realm, it sends a KRB_ERROR message with the code
255   KRB_AP_ERR_IAKERB_KDC_NOT_FOUND to the client and the context fails
256   to establish.  There is no accompanying error data defined in this
257   document for this error code.
258
259           KRB_AP_ERR_IAKERB_KDC_NOT_FOUND      85
260               -- The IAKERB proxy could not find a KDC.
261
262   When the GSS-API acceptor has an IP address for a KDC in the client
263   realm, but does not receive a response from any KDC in the realm
264   (including in response to retries), it sends a KRB_ERROR message with
265   the code KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE to the client and the
266   context fails to establish.  There is no accompanying error data
267   defined in this document for this error code.
268
269           KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE    86
270               -- The KDC did not respond to the IAKERB proxy.
271
272   The IAKERB proxy can send opaque data in the cookie field of the
273   IAKERB-HEADER structure in the server reply to the client, in order
274   to, for example, minimize the amount of state information kept by the
275
276
277
278Zhu & Altman            Expires January 10, 2008                [Page 5]
279
280Internet-Draft                   IAKERB                        July 2007
281
282
283   GSS-API acceptor.  The content and the encoding of the cookie field
284   is a local matter of the IAKERB proxy.  The client MUST copy the
285   cookie verbatim from the previous server response whenever the cookie
286   is present into the subsequent tokens that contains an IAKERB_PROXY
287   message.
288
289   When the client obtained a service ticket, the client sends a
290   KRB_AP_REQ message to the server, and performs the client-server
291   application exchange as defined in [RFC4120] and [RFC4121].
292
293   For implementations comforming to this specification, the
294   authenticator subkey in the AP-REQ MUST alway be present, and the
295   Exts field in the GSS-API authenticator [GSS-EXTS] MUST contain an
296   extension of the type GSS_EXTS_IAKERB_FINISHED and the extension data
297   contains the ASN.1 DER encoding of the structure IAKERB-FINISHED.
298
299           GSS_EXTS_IAKERB_FINISHED             TBD
300                --- Data type for the IAKERB checksum.
301
302           IAKERB-FINISHED ::= {
303                iakerb-messages [1] Checksum,
304                    -- Contains the checksum of the GSS-API tokens
305                    -- exchanged between the initiator and the acceptor,
306                    -- and prior to the containing AP_REQ GSS-API token.
307                    -- The checksum is performed over the GSS-API tokens
308                    -- in the order that the tokens were sent.
309                 ...
310           }
311
312   The iakerb-messages field in the IAKERB-FINISHED structure contains a
313   checksum of all the GSS-API tokens exchanged between the initiator
314   and the acceptor, and prior to the GSS-API token containing the
315   AP_REQ.  This checksum is performed over these GSS-API tokens in the
316   order that the tokens were sent.  In the parlance of [RFC3961], the
317   checksum type is the required checksum type for the enctype of the
318   subkey in the authenticator, the protocol key for the checksum
319   operation is the authenticator subkey, and the key usage number is
320   KEY_USAGE_IAKERB_FINISHED.
321
322           KEY_USAGE_IAKERB_FINISHED            42
323
324   The GSS-API acceptor MUST then verify the checksum contained in the
325   GSS_EXTS_IAKERB_FINISHED extension.  This checksum provides integrity
326   protection for the messages exchanged including the unauthenticated
327   clear texts in the IAKERB-HEADER structure.
328
329   If the pre-authentication data is encrypted in the long-term
330   password-based key of the principal, the risk of security exposures
331
332
333
334Zhu & Altman            Expires January 10, 2008                [Page 6]
335
336Internet-Draft                   IAKERB                        July 2007
337
338
339   is significant.  Implementations SHOULD provide the AS_REQ armoring
340   as defined in [KRB-PAFW] unless an alternative protection is
341   deployed.  In addition, the anonymous Kerberos FAST option is
342   RECOMMENDED for the client to complicate traffic analysis.
343
344
3454.  Addresses in Tickets
346
347   In IAKERB, the machine sending requests to the KDC is the GSS-API
348   acceptor and not the client.  As a result, the client should not
349   include its addresses in any KDC requests for two reasons.  First,
350   the KDC may reject the forwarded request as being from the wrong
351   client.  Second, in the case of initial authentication for a dial-up
352   client, the client machine may not yet possess a network address.
353   Hence, as allowed by [RFC4120], the addresses field of the AS-REQ and
354   TGS-REQ requests SHOULD be blank and the caddr field of the ticket
355   SHOULD similarly be left blank.
356
357
3585.  Security Considerations
359
360   A typical IAKERB client sends the AS_REQ with pre-authentication data
361   encrypted in the long-term keys of the user before the server is
362   authenticated.  This enables offline attacks by un-trusted servers.
363   To mitigate this threat, the client SHOULD use Kerberos
364   FAST[KRB-PAFW] and require KDC authentication to protect the user's
365   credentials.
366
367   The client name is in clear text in the authentication exchange
368   messages and ticket granting service exchanges according to [RFC4120]
369   whereas the client name is encrypted in client- server application
370   exchange messages.  By using the IAKERB proxy to relay the ticket
371   requests and responses, the client's identity could be revealed in
372   the client-server traffic where the same identity could have been
373   concealed if IAKERB were not used.  Hence, to complicate traffic
374   analysis and provide privacy for the IAKERB client, the IAKERB client
375   SHOULD request the anonymous Kerberos FAST option [KRB-PAFW].
376
377   Similar to other network access protocols, IAKERB allows an
378   unauthenticated client (possibly outside the security perimeter of an
379   organization) to send messages that are proxied to interior servers.
380
381   In a scenario where DNS SRV RR's are being used to locate the KDC,
382   IAKERB is being used, and an external attacker can modify DNS
383   responses to the IAKERB proxy, there are several countermeasures to
384   prevent arbitrary messages from being sent to internal servers:
385
386
387
388
389
390Zhu & Altman            Expires January 10, 2008                [Page 7]
391
392Internet-Draft                   IAKERB                        July 2007
393
394
395   1.  KDC port numbers can be statically configured on the IAKERB
396       proxy.  In this case, the messages will always be sent to KDC's.
397       For an organization that runs KDC's on a static port (usually
398       port 88) and does not run any other servers on the same port,
399       this countermeasure would be easy to administer and should be
400       effective.
401
402   2.  The proxy can do application level sanity checking and filtering.
403       This countermeasure should eliminate many of the above attacks.
404
405   3.  DNS security can be deployed.  This countermeasure is probably
406       overkill for this particular problem, but if an organization has
407       already deployed DNS security for other reasons, then it might
408       make sense to leverage it here.  Note that Kerberos could be used
409       to protect the DNS exchanges.  The initial DNS SRV KDC lookup by
410       the proxy will be unprotected, but an attack here is at most a
411       denial of service (the initial lookup will be for the proxy's KDC
412       to facilitate Kerberos protection of subsequent DNS exchanges
413       between itself and the DNS server).
414
415
4166.  Acknowledgements
417
418   Jonathan Trostle, Michael Swift, Bernard Aboba and Glen Zorn wrote
419   earlier revision of this document.
420
421   The hallway conversations between Larry Zhu and Nicolas Williams
422   formed the basis of this document.
423
424
4257.  IANA Considerations
426
427   There is no IANA action required for this document.
428
429
4308.  References
431
4328.1.  Normative References
433
434   [GSS-EXTS]
435              Emery, S., "Kerberos Version 5 GSS-API Channel Binding
436              Hash Agility",
437              draft-ietf-krb-wg-gss-cb-hash-agility-03.txt (work in
438              progress), 2007.
439
440   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
441              Requirement Levels", BCP 14, RFC 2119, March 1997.
442
443
444
445
446Zhu & Altman            Expires January 10, 2008                [Page 8]
447
448Internet-Draft                   IAKERB                        July 2007
449
450
451   [RFC2743]  Linn, J., "Generic Security Service Application Program
452              Interface Version 2, Update 1", RFC 2743, January 2000.
453
454   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
455              Kerberos 5", RFC 3961, February 2005.
456
457   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
458              Kerberos Network Authentication Service (V5)", RFC 4120,
459              July 2005.
460
461   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
462              Version 5 Generic Security Service Application Program
463              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
464              July 2005.
465
466   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
467              Simple and Protected Generic Security Service Application
468              Program Interface (GSS-API) Negotiation Mechanism",
469              RFC 4178, October 2005.
470
4718.2.  Informative references
472
473   [KRB-ANON]
474              Zhu, L. and P. Leach, "Kerberos Anonymity Support",
475              draft-ietf-krb-wg-anon-04.txt (work in progress), 2007.
476
477   [KRB-PAFW]
478              Zhu, L. and S. Hartman, "A Generalized Framework for
479              Kerberos Pre-Authentication",
480              draft-ietf-krb-wg-preauth-framework-06.txt (work in
481              progress), 2007.
482
483
484Authors' Addresses
485
486   Larry Zhu
487   Microsoft Corporation
488   One Microsoft Way
489   Redmond, WA  98052
490   US
491
492   Email: lzhu@microsoft.com
493
494
495
496
497
498
499
500
501
502Zhu & Altman            Expires January 10, 2008                [Page 9]
503
504Internet-Draft                   IAKERB                        July 2007
505
506
507   Jeffery Altman
508   Secure Endpoints
509   255 W 94th St
510   New York, NY  10025
511   US
512
513   Email: jaltman@secure-endpoints.com
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558Zhu & Altman            Expires January 10, 2008               [Page 10]
559
560Internet-Draft                   IAKERB                        July 2007
561
562
563Full Copyright Statement
564
565   Copyright (C) The IETF Trust (2007).
566
567   This document is subject to the rights, licenses and restrictions
568   contained in BCP 78, and except as set forth therein, the authors
569   retain all their rights.
570
571   This document and the information contained herein are provided on an
572   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
573   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
574   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
575   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
576   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
577   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
578
579
580Intellectual Property
581
582   The IETF takes no position regarding the validity or scope of any
583   Intellectual Property Rights or other rights that might be claimed to
584   pertain to the implementation or use of the technology described in
585   this document or the extent to which any license under such rights
586   might or might not be available; nor does it represent that it has
587   made any independent effort to identify any such rights.  Information
588   on the procedures with respect to rights in RFC documents can be
589   found in BCP 78 and BCP 79.
590
591   Copies of IPR disclosures made to the IETF Secretariat and any
592   assurances of licenses to be made available, or the result of an
593   attempt made to obtain a general license or permission for the use of
594   such proprietary rights by implementers or users of this
595   specification can be obtained from the IETF on-line IPR repository at
596   http://www.ietf.org/ipr.
597
598   The IETF invites any interested party to bring to its attention any
599   copyrights, patents or patent applications, or other proprietary
600   rights that may cover technology that may be required to implement
601   this standard.  Please address the information to the IETF at
602   ietf-ipr@ietf.org.
603
604
605Acknowledgment
606
607   Funding for the RFC Editor function is provided by the IETF
608   Administrative Support Activity (IASA).
609
610
611
612
613
614Zhu & Altman            Expires January 10, 2008               [Page 11]
615
616
617