1
2
3NETWORK WORKING GROUP                                             L. Zhu
4Internet-Draft                                     Microsoft Corporation
5Updates: 4120 (if approved)                             October 17, 2006
6Intended status: Standards Track
7Expires: April 20, 2007
8
9
10                       Kerberos for Web Services
11                          draft-zhu-ws-kerb-00
12
13Status of this Memo
14
15   By submitting this Internet-Draft, each author represents that any
16   applicable patent or other IPR claims of which he or she is aware
17   have been or will be disclosed, and any of which he or she becomes
18   aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
24
25   Internet-Drafts are draft documents valid for a maximum of six months
26   and may be updated, replaced, or obsoleted by other documents at any
27   time.  It is inappropriate to use Internet-Drafts as reference
28   material or to cite them other than as "work in progress."
29
30   The list of current Internet-Drafts can be accessed at
31   http://www.ietf.org/ietf/1id-abstracts.txt.
32
33   The list of Internet-Draft Shadow Directories can be accessed at
34   http://www.ietf.org/shadow.html.
35
36   This Internet-Draft will expire on April 20, 2007.
37
38Copyright Notice
39
40   Copyright (C) The Internet Society (2006).
41
42Abstract
43
44   This document defines extensions to the Kerberos protocol and the
45   GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to
46   exchange messages with the KDC using the GSS-API server as the proxy,
47   by encapsulating the Kerberos messages inside GSS-API tokens.  With
48   these extensions, Kerberos is suitable for securing communication
49   between the client and web services over the Internet.
50
51
52
53
54Zhu                      Expires April 20, 2007                 [Page 1]
55
56Internet-Draft                   WS-KERB                    October 2006
57
58
59Table of Contents
60
61   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
62   2.  Conventions Used in This Document . . . . . . . . . . . . . . . 3
63   3.  GSS-API Encapsulation . . . . . . . . . . . . . . . . . . . . . 3
64   4.  Addresses in Tickets  . . . . . . . . . . . . . . . . . . . . . 6
65   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
66   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
67   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
68   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7
69   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
70   Intellectual Property and Copyright Statements  . . . . . . . . . . 9
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110Zhu                      Expires April 20, 2007                 [Page 2]
111
112Internet-Draft                   WS-KERB                    October 2006
113
114
1151.  Introduction
116
117   The Kerberos [RFC4120] pre-authentication framework [KRB-PAFW]
118   promises minimal or no exposure of weak client keys and strong client
119   authentication.  The Kerberos support of anonymity [KRB-ANON]
120   provides for privacy.  These advancements make Kerberos suitable over
121   the Internet.
122
123   The traditional client-push Kerberos protocol does not work well in
124   the Web services environments where the KDC is not accessible to the
125   client, but is accessible to the web server.  For example, the KDC is
126   commonly placed behind a firewall together with the application
127   server.  The lack of accessibility to the KDC by the client could
128   also occur are when the client does not have an IP address prior to
129   authenticating to an access point.
130
131   Generic Security Service Application Program Interface (GSS-API)
132   [RFC2743] allows security mechanisms exchange arbitrary messages
133   between the client and the server via the application traffic,
134   independent of the underlying transports.  A protocol based on
135   [RFC4121] is thus defined to allow the GSS-API client to exchange
136   Kerberos messages with the KDC by using the GSS-API server as the
137   proxy.  The server-pull model defined in this specification is
138   benefical for clients with limited processing power such as mobile
139   devices, or when the client and the server message exchange has high
140   network latency.
141
142           Client <---------> WS-KERB proxy <----------> KDC
143
144   The Kerberos client MUST use a pre-authentication mechanism such as
145   FAST [KRB-PAFW] to avoid exposure of long term client keys to the
146   server, before and after the server is authenticated, and hide the
147   client identity from adversary who can eavesdrop the application
148   traffic if such level of privacy is desirable.
149
150
1512.  Conventions Used in This Document
152
153   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
154   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
155   document are to be interpreted as described in [RFC2119].
156
157
1583.  GSS-API Encapsulation
159
160   The mechanism Objection Identifier (OID) for GSS-API WS-KERB, in
161   accordance with the mechanism proposed by [RFC4178] for negotiating
162   protocol variations, is id-kerberos-ws:
163
164
165
166Zhu                      Expires April 20, 2007                 [Page 3]
167
168Internet-Draft                   WS-KERB                    October 2006
169
170
171      id-kerberos-ws ::=
172        { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
173          webService(6) }
174
175   The first token of the GSS-API WS-KERB mechanism MUST have the
176   generic token framing described in section 3.1 of [RFC2743] with the
177   mechanism OID being id-kerberos-ws, and any subsequent GSS-API WS-
178   KERB token MUST NOT have this framing.
179
180   The GSS-API WS-KERB mechanism MUST always provide server
181   authentication, even if the client does not ask for it.  When server-
182   authentication is performed, the GSS-API server will always send back
183   an AP-REP, and as described later in this section this mechanism
184   provides integrity protection for all client-server proxy message
185   exchanges.
186
187   The innerToken described in section 3.1 of [RFC2743] and subsequent
188   GSS-API tokens have the following formats: it starts with a two-octet
189   token-identifier (TOK_ID), followed by a WS-KERB message or a
190   Kerberos message.
191
192
193             Token/Message       TOK_ID Value in Hex
194           -----------------------------------------
195             WS_KRB_PROXY         05 01
196
197   Only one WS-KERB specific message, namely the WS_KRB_PROXY message,
198   is defined in this document.  The TOK_ID values for [RFC4120]
199   Kerberos messages are the same as those defined for the GSS-API
200   Kerberos mechanism [RFC4121].
201
202   The message of the WS_KRB_PROXY type is defined as a WS-KRB-HEADER
203   structure immediately followed by a Kerberos message.  The Kerberos
204   message can be an AS-REQ, an AS-REP, a TGS-REQ, a TGS-REP, or a KRB-
205   ERROR as defined in [RFC4120].
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222Zhu                      Expires April 20, 2007                 [Page 4]
223
224Internet-Draft                   WS-KERB                    October 2006
225
226
227           WS-KRB-HEADER ::= SEQUENCE {
228               pvno            [1] INTEGER (5) ,
229               msg-type        [2] INTEGER (23),
230               proxy-data      [3] ProxyData,
231               ...
232           }
233
234           ProxyData :: = SEQUENCE {
235               realm           [1] Realm,
236               cookie          [3] OCTET STRING OPTIONAL,
237                  -- opaque data, if sent by the server,
238                  -- MUST be copied by the client unchanged into
239                  -- the next WS-KERB message.
240               ...
241           }
242
243
244   The WS-KRB-HEADER structure and all the Kerberos messages MUST be
245   encoded using Abstract Syntax Notation One (ASN.1) Distinguished
246   Encoding Rules (DER) [X680] [X690].
247
248   The GSS-API WS-KERB client fills out the realm field in the ProxyData
249   of the first request with the client realm.  If the client does not
250   know the client realm [REFERALS], it MUST fill it out using the
251   client's default realm name such as the realm of the client host.
252   Typically the Kerberos message in the first WS_KRB_PROXY message from
253   the client is an AS-REQ message.
254
255   Upon receipt of the WS_KRB_PROXY message, the GSS-API WS-KERB server
256   MUST use the proxy-data in the message from the client to locate the
257   KDC and sends the encapsulated Kerberos message to that KDC.  In
258   order to reduce the number of roundtrips between the client and the
259   server, the server SHOULD process any message exchange with the KDC
260   if the exchange is unauthenticated, such as client-referral message
261   exchange [REFERALS].  If the server can not process the KDC response
262   by itself, for example when the knowledge of the client keys is
263   required, it sends back to the client the KDC reply message
264   encapsulated in a WS_KRB_PROXY message.  The server MUST fill out the
265   realm name whose KDC produced the response.  The server SHOULD use
266   the XKDC mechanism described in [KRB-PAFW] to allow the client's KDC
267   to obtain a service ticket to the server, thus further reduce the
268   number of roundtrips between the GSS-API client and the GSS-API
269   server.  The GSS-API server can send opaque data in the cookie field
270   of the WS-KRB-HEADER structure in the server reply to the client, in
271   order to, for example, reduce the amount of state information kept by
272   the GSS-API server.  The content and the encoding of the cookie field
273   is a local matter of the server.  The client MUST copy the verbatim
274   cookie from the previous server response, when the cookie is present,
275
276
277
278Zhu                      Expires April 20, 2007                 [Page 5]
279
280Internet-Draft                   WS-KERB                    October 2006
281
282
283   whenever it sends an additional WS-KRB-PROXY message to the server.
284   The client processes the KDC response, and fills out the realm name
285   it believes to whom the server should send the encapsulated Kerberos
286   message.
287
288   When the client obtains a service ticket, the client then sends a
289   KRB_AP_REQ message to the server, and proceed as defined in
290   [RFC4121].  A GSS-API authenticator extension [GSS-EXTS] MUST be sent
291   by the client.  The extension type is 2 and the content is the ASN.1
292   DER encoding of the type Checksum.  The checksum is performed over
293   all GSS-API messages as exchanged between the client and the server
294   before the KRB_AP_REQ message, and in the order of the exchange.  The
295   checksum type is the required checksum type for the enctype of the
296   subkey in the authenticator, the protocol key is the authenticator
297   subkey, and the key usage number is TBA-1.  The server MUST verify
298   this checksum in the GSS-API authenticator extension, then respond
299   with an AP-REP extension [GSS-EXTS].  The AP-REP extension type is 2
300   and the the content is the ASN.1 DER encoding of the type Checksum.
301   This checksum is performed over all GSS-API messages as exchanged
302   between the client and the server before the KRB_AP_REQ message, and
303   in the order of the exchange.  The checksum type is the required
304   checksum type for the enctype of the authenticator subkey in the
305   request, and the protocol key is the authenticator subkey, and the
306   key usage number is TBA-2.  The client MUST then verify this
307   checksum.
308
309
3104.  Addresses in Tickets
311
312   In WS-KERB, the machine sending requests to the KDC is the GSS-API
313   server and not the client.  As a result, the client should not
314   include its addresses in any KDC requests for two reasons.  First,
315   the KDC may reject the forwarded request as being from the wrong
316   client.  Second, in the case of initial authentication for a dial-up
317   client, the client machine may not yet possess a network address.
318   Hence, as allowed by [RFC4120], the addresses field of the AS-REQ and
319   TGS-REQ requests SHOULD be blank and the caddr field of the ticket
320   SHOULD similarly be left blank.
321
322
3235.  Security Considerations
324
325   Similar to other network access protocols, WS-KERB allows an
326   unauthenticated client (possibly outside the security perimeter of an
327   organization) to send messages that are proxied to interior servers.
328
329   In a scenario where DNS SRV RR's are being used to locate the KDC,
330   WS-KERB is being used, and an external attacker can modify DNS
331
332
333
334Zhu                      Expires April 20, 2007                 [Page 6]
335
336Internet-Draft                   WS-KERB                    October 2006
337
338
339   responses to the WS-KERB proxy, there are several countermeasures to
340   prevent arbitrary messages from being sent to internal servers:
341
342   1.  KDC port numbers can be statically configured on the WS-KERB
343       proxy.  In this case, the messages will always be sent to KDC's.
344       For an organization that runs KDC's on a static port (usually
345       port 88) and does not run any other servers on the same port,
346       this countermeasure would be easy to administer and should be
347       effective.
348
349   2.  The proxy can do application level sanity checking and filtering.
350       This countermeasure should eliminate many of the above attacks.
351
352   3.  DNS security can be deployed.  This countermeasure is probably
353       overkill for this particular problem, but if an organization has
354       already deployed DNS security for other reasons, then it might
355       make sense to leverage it here.  Note that Kerberos could be used
356       to protect the DNS exchanges.  The initial DNS SRV KDC lookup by
357       the proxy will be unprotected, but an attack here is at most a
358       denial of service (the initial lookup will be for the proxy's KDC
359       to facilitate Kerberos protection of subsequent DNS exchanges
360       between itself and the DNS server).
361
362
3636.  Acknowledgements
364
365   The server-proxy idea is based on the early revisions of this
366   document written by Jonathan Trostle, Michael Swift, Bernard Aboba
367   and Glen Zorn.
368
369   The rest of the ideas mostly came from hallway conversations between
370   the author and Nicolas Williams.
371
372
3737.  IANA Considerations
374
375   There is no IANA action required for this document.
376
377
3788.  Normative References
379
380   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
381              Requirement Levels", BCP 14, RFC 2119, March 1997.
382
383   [RFC2743]  Linn, J., "Generic Security Service Application Program
384              Interface Version 2, Update 1", RFC 2743, January 2000.
385
386   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
387
388
389
390Zhu                      Expires April 20, 2007                 [Page 7]
391
392Internet-Draft                   WS-KERB                    October 2006
393
394
395              Kerberos Network Authentication Service (V5)", RFC 4120,
396              July 2005.
397
398   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
399              Version 5 Generic Security Service Application Program
400              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
401              July 2005.
402
403   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
404              Simple and Protected Generic Security Service Application
405              Program Interface (GSS-API) Negotiation Mechanism",
406              RFC 4178, October 2005.
407
408   [KRB-ANON] Zhu, L., Leach, P. and Jaganathan, K., "Kerberos Anonymity 
409              Support", draft-ietf-krb-wg-anon, work in progress.
410
411
412   [KRB-PAFW] Zhu, etl, "Kerberos Pre-Authentication framework", 
413              draft-ietf-krb-wg-preauth-framework, work in progress.
414              
415   [GSS-EXTS] Emery, S., draft-ietf-krb-wg-gss-cb-hash-agility, work in 
416              progess.
417
418   [REFERALS] Raeburn, K., "Generating KDC Referrals to Locate Kerberos 
419              Realms", draft-ietf-krb-wg-kerberos-referrals, work in
420              progress.
421              
422   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
423              Information technology - Abstract Syntax Notation One
424              (ASN.1): Specification of basic notation.
425
426   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
427              Information technology - ASN.1 encoding Rules:
428              Specification of Basic Encoding Rules (BER), Canonical
429              Encoding Rules (CER) and Distinguished Encoding Rules
430              (DER).
431
432
433Author's Address
434
435   Larry Zhu
436   Microsoft Corporation
437   One Microsoft Way
438   Redmond, WA  98052
439   US
440
441   Email: lzhu@microsoft.com
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470Zhu                      Expires April 20, 2007                 [Page 8]
471
472Internet-Draft                   WS-KERB                    October 2006
473
474
475Full Copyright Statement
476
477   Copyright (C) The Internet Society (2006).
478
479   This document is subject to the rights, licenses and restrictions
480   contained in BCP 78, and except as set forth therein, the authors
481   retain all their rights.
482
483   This document and the information contained herein are provided on an
484   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
485   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
486   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
487   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
488   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
489   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
490
491
492Intellectual Property
493
494   The IETF takes no position regarding the validity or scope of any
495   Intellectual Property Rights or other rights that might be claimed to
496   pertain to the implementation or use of the technology described in
497   this document or the extent to which any license under such rights
498   might or might not be available; nor does it represent that it has
499   made any independent effort to identify any such rights.  Information
500   on the procedures with respect to rights in RFC documents can be
501   found in BCP 78 and BCP 79.
502
503   Copies of IPR disclosures made to the IETF Secretariat and any
504   assurances of licenses to be made available, or the result of an
505   attempt made to obtain a general license or permission for the use of
506   such proprietary rights by implementers or users of this
507   specification can be obtained from the IETF on-line IPR repository at
508   http://www.ietf.org/ipr.
509
510   The IETF invites any interested party to bring to its attention any
511   copyrights, patents or patent applications, or other proprietary
512   rights that may cover technology that may be required to implement
513   this standard.  Please address the information to the IETF at
514   ietf-ipr@ietf.org.
515
516
517Acknowledgment
518
519   Funding for the RFC Editor function is provided by the IETF
520   Administrative Support Activity (IASA).
521
522
523
524
525
526Zhu                      Expires April 20, 2007                 [Page 9]
527
528
529