1
2
3NETWORK WORKING GROUP                                             L. Zhu
4Internet-Draft                                     Microsoft Corporation
5Updates: 4120 (if approved)                                 October 2006
6Intended status: Standards Track
7Expires: April 4, 2007
8
9
10                       Kerberos for Web Services
11                          draft-zhu-ws-kerb-01
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 4, 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 acceptor as the
47   proxy, by encapsulating the Kerberos messages inside GSS-API tokens.
48   With these extensions, Kerberos is suitable for securing
49   communication between the client and web services over the Internet.
50
51
52
53
54Zhu                       Expires April 4, 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 4, 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 initiator and the acceptor via the application traffic,
134   independent of the underlying transports.  A protocol based on
135   [RFC4121] is thus defined to allow the GSS-API initiator to exchange
136   Kerberos messages with the KDC by using the GSS-API acceptor as the
137   proxy.  The acceptor-pull model defined in this specification is
138   benefical for initiators with limited processing power such as mobile
139   devices, or when the transport layer between the initiator and the
140   acceptor has high network latency.
141
142           Client --------- WS-KERB proxy ---------- KDC
143
144   The Kerberos client MUST avoid exposure of long term client keys to
145   the GSS-API acceptor, before and after the Kerberos server is
146   authenticated.  This can be accomplished by using Kerberos-FAST [KRB-
147   PAFW].  Furthermore, the initiator can use the anonymous option as
148   defined in Section 6.5.2 of [KRB-PAFW], to hide the client identity
149   from adversary who can eavesdrop the application traffic.
150
151
1522.  Conventions Used in This Document
153
154   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
155   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
156   document are to be interpreted as described in [RFC2119].
157
158
1593.  GSS-API Encapsulation
160
161   The mechanism Objection Identifier (OID) for GSS-API WS-KERB, in
162   accordance with the mechanism proposed by [RFC4178] for negotiating
163
164
165
166Zhu                       Expires April 4, 2007                 [Page 3]
167
168Internet-Draft                   WS-KERB                    October 2006
169
170
171   protocol variations, is id-kerberos-ws.
172
173      id-kerberos-ws ::=
174        { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
175          webService(6) }
176
177   The first token of the GSS-API WS-KERB mechanism MUST have the
178   generic token framing described in section 3.1 of [RFC2743] with the
179   mechanism OID being id-kerberos-ws, and any subsequent GSS-API WS-
180   KERB token MUST NOT have this framing.
181
182   The GSS-API WS-KERB mechanism MUST always provide mutual
183   authentication, even if the initiator does not ask for it.  When
184   mutual-authentication is performed, the GSS-API acceptor will always
185   send back an AP-REP, and as described later in this section this
186   mechanism provides integrity protection for all initiator-acceptor
187   proxy message exchanges.
188
189   The innerToken described in section 3.1 of [RFC2743] and subsequent
190   GSS-API tokens have the following formats: it starts with a two-octet
191   token-identifier (TOK_ID), followed by a WS-KERB message or a
192   Kerberos message.
193
194
195             Token/Message       TOK_ID Value in Hex
196           -----------------------------------------
197             WS_KRB_PROXY         05 01
198
199   Only one WS-KERB specific message, namely the WS_KRB_PROXY message,
200   is defined in this document.  The TOK_ID values for [RFC4120]
201   Kerberos messages are the same as those defined for the GSS-API
202   Kerberos mechanism [RFC4121].
203
204   The message of the WS_KRB_PROXY type is defined as a WS-KRB-HEADER
205   structure immediately followed by a Kerberos message.  The Kerberos
206   message can be an AS-REQ, an AS-REP, a TGS-REQ, a TGS-REP, or a KRB-
207   ERROR as defined in [RFC4120].
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222Zhu                       Expires April 4, 2007                 [Page 4]
223
224Internet-Draft                   WS-KERB                    October 2006
225
226
227           WS-KRB-HEADER ::= SEQUENCE {
228               proxy-data      [1] ProxyData,
229               ...
230           }
231
232           ProxyData :: = SEQUENCE {
233               realm           [1] Realm,
234               cookie          [3] OCTET STRING OPTIONAL,
235                  -- opaque data, if sent by the acceptor,
236                  -- MUST be copied by the client unchanged into
237                  -- the next WS-KERB message.
238               ...
239           }
240
241
242   The WS-KRB-HEADER structure and all the Kerberos messages MUST be
243   encoded using Abstract Syntax Notation One (ASN.1) Distinguished
244   Encoding Rules (DER) [X680] [X690].
245
246   The GSS-API initiator fills out the realm field in the ProxyData of
247   the first request with the client realm.  If the client does not know
248   the client realm [REFERALS], it MUST fill it out using the client's
249   default realm name such as the realm of the client host.  Typically
250   the Kerberos message in the first WS_KRB_PROXY message from the
251   client is an AS-REQ message.
252
253   Upon receipt of the WS_KRB_PROXY message, the GSS-API WS-KERB
254   acceptor MUST use the proxy-data in the message from the client to
255   locate the KDC and sends the encapsulated Kerberos message to that
256   KDC.  Unless otherwise specified, the acceptor can locate the KDC per
257   Section 7.2.3.2 of [RFC4120].
258
259   In order to reduce the number of roundtrips between the initiator and
260   the acceptor, the acceptor SHOULD process any message exchange with
261   the KDC if the exchange is unauthenticated, such as client-referral
262   message exchange [REFERALS].  If the acceptor can not process the KDC
263   response by itself, for example when the knowledge of the client keys
264   is required, it sends back to the client the KDC reply message
265   encapsulated in a WS_KRB_PROXY message.  The acceptor MUST fill out
266   the realm name whose KDC produced the response.  The acceptor SHOULD
267   use the kdc-referrals option described in Section 6.5.2 of [KRB-PAFW]
268   to allow the KDC of the client's realm to obtain a service ticket
269   addressed to the acceptor, thus further reduce the number of
270   roundtrips between the GSS-API initiator and the GSS-API acceptor.
271   The GSS-API acceptor can send opaque data in the cookie field of the
272   WS-KRB-HEADER structure in the reply from the acceptor to the
273   initiator, in order to, for example, to facilitate state managements
274   on the GSS-API acceptor.  The content and the encoding of the cookie
275
276
277
278Zhu                       Expires April 4, 2007                 [Page 5]
279
280Internet-Draft                   WS-KERB                    October 2006
281
282
283   field is a local matter of the acceptor.  The initiator MUST copy the
284   verbatim cookie from the previous acceptor response, when the cookie
285   is present, whenever it sends an additional WS-KRB-PROXY message to
286   the acceptor.  The client processes the KDC response, and fills out
287   the realm name it believes to whom the acceptor should send the
288   encapsulated Kerberos message.
289
290   When the client obtains a service ticket, the initiator then sends a
291   KRB_AP_REQ message to the acceptor, and proceed as defined in
292   [RFC4121].  A GSS-API authenticator extension [GSS-EXTS] MUST be sent
293   by the initiator.  The extension type is 2 and the content is the
294   ASN.1 DER encoding of the type Checksum.  The checksum is performed
295   over all GSS-API messages as exchanged between the initiator and the
296   acceptor before the KRB_AP_REQ message, and in the order of the
297   exchange.  The checksum type is the required checksum type for the
298   enctype of the subkey in the authenticator, the protocol key is the
299   authenticator subkey, and the key usage number is TBA-1.  The
300   acceptor MUST verify this checksum in the GSS-API authenticator
301   extension, then respond with an AP-REP extension [GSS-EXTS].  The AP-
302   REP extension type is 2 and the the content is the ASN.1 DER encoding
303   of the type Checksum.  This checksum is performed over all GSS-API
304   messages as exchanged between the initiator and the acceptor before
305   the KRB_AP_REQ message, and in the order of the exchange.  The
306   checksum type is the required checksum type for the enctype of the
307   authenticator subkey in the request, and the protocol key is the
308   authenticator subkey, and the key usage number is TBA-2.  The
309   initiator MUST then verify this checksum.
310
311
3124.  Addresses in Tickets
313
314   In WS-KERB, the machine sending requests to the KDC is the GSS-API
315   acceptor and not the initiator.  As a result, the initiator should
316   not include its addresses in any KDC requests for two reasons.
317   First, the KDC may reject the forwarded request as being from the
318   wrong client.  Second, in the case of initial authentication for a
319   dial-up client, the client machine may not yet possess a network
320   address.  Hence, as allowed by [RFC4120], the addresses field of the
321   AS-REQ and TGS-REQ requests SHOULD be blank and the caddr field of
322   the ticket SHOULD similarly be left blank.
323
324
3255.  Security Considerations
326
327   Similar to other network access protocols, WS-KERB allows an
328   unauthenticated client (possibly outside the security perimeter of an
329   organization) to send messages that are proxied to interior servers.
330
331
332
333
334Zhu                       Expires April 4, 2007                 [Page 6]
335
336Internet-Draft                   WS-KERB                    October 2006
337
338
339   In a scenario where DNS SRV RR's are being used to locate the KDC,
340   WS-KERB is being used, and an external attacker can modify DNS
341   responses to the WS-KERB proxy, there are several countermeasures to
342   prevent arbitrary messages from being sent to internal servers:
343
344   1.  KDC port numbers can be statically configured on the WS-KERB
345       proxy.  In this case, the messages will always be sent to KDC's.
346       For an organization that runs KDC's on a static port (usually
347       port 88) and does not run any other servers on the same port,
348       this countermeasure would be easy to administer and should be
349       effective.
350
351   2.  The proxy can do application level sanity checking and filtering.
352       This countermeasure should eliminate many of the above attacks.
353
354   3.  DNS security can be deployed.  This countermeasure is probably
355       overkill for this particular problem, but if an organization has
356       already deployed DNS security for other reasons, then it might
357       make sense to leverage it here.  Note that Kerberos could be used
358       to protect the DNS exchanges.  The initial DNS SRV KDC lookup by
359       the proxy will be unprotected, but an attack here is at most a
360       denial of service (the initial lookup will be for the proxy's KDC
361       to facilitate Kerberos protection of subsequent DNS exchanges
362       between itself and the DNS server).
363
364
3656.  Acknowledgements
366
367   The acceptor-proxy idea is based on the early revisions of this
368   document written by Jonathan Trostle, Michael Swift, Bernard Aboba
369   and Glen Zorn.
370
371   The rest of the ideas mostly came from hallway conversations between
372   the author and Nicolas Williams.
373
374
3757.  IANA Considerations
376
377   There is no IANA action required for this document.
378
379
3808.  Normative References
381
382   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
383              Requirement Levels", BCP 14, RFC 2119, March 1997.
384
385   [RFC2743]  Linn, J., "Generic Security Service Application Program
386              Interface Version 2, Update 1", RFC 2743, January 2000.
387
388
389
390Zhu                       Expires April 4, 2007                 [Page 7]
391
392Internet-Draft                   WS-KERB                    October 2006
393
394
395   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
396              Kerberos Network Authentication Service (V5)", RFC 4120,
397              July 2005.
398
399   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
400              Version 5 Generic Security Service Application Program
401              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
402              July 2005.
403
404   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
405              Simple and Protected Generic Security Service Application
406              Program Interface (GSS-API) Negotiation Mechanism",
407              RFC 4178, October 2005.
408
409   [KRB-ANON] Zhu, L., Leach, P. and Jaganathan, K., "Kerberos Anonymity 
410              Support", draft-ietf-krb-wg-anon, work in progress.
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
447Zhu                       Expires April 4, 2007                 [Page 8]
448
449Internet-Draft                   WS-KERB                    October 2006
450
451
452Full Copyright Statement
453
454   Copyright (C) The Internet Society (2006).
455
456   This document is subject to the rights, licenses and restrictions
457   contained in BCP 78, and except as set forth therein, the authors
458   retain all their rights.
459
460   This document and the information contained herein are provided on an
461   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
462   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
463   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
464   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
465   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
466   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
467
468
469Intellectual Property
470
471   The IETF takes no position regarding the validity or scope of any
472   Intellectual Property Rights or other rights that might be claimed to
473   pertain to the implementation or use of the technology described in
474   this document or the extent to which any license under such rights
475   might or might not be available; nor does it represent that it has
476   made any independent effort to identify any such rights.  Information
477   on the procedures with respect to rights in RFC documents can be
478   found in BCP 78 and BCP 79.
479
480   Copies of IPR disclosures made to the IETF Secretariat and any
481   assurances of licenses to be made available, or the result of an
482   attempt made to obtain a general license or permission for the use of
483   such proprietary rights by implementers or users of this
484   specification can be obtained from the IETF on-line IPR repository at
485   http://www.ietf.org/ipr.
486
487   The IETF invites any interested party to bring to its attention any
488   copyrights, patents or patent applications, or other proprietary
489   rights that may cover technology that may be required to implement
490   this standard.  Please address the information to the IETF at
491   ietf-ipr@ietf.org.
492
493
494Acknowledgment
495
496   Funding for the RFC Editor function is provided by the IETF
497   Administrative Support Activity (IASA).
498
499
500
501
502
503Zhu                       Expires April 4, 2007                 [Page 9]
504
505
506