1
2
3NETWORK WORKING GROUP                                             L. Zhu
4Internet-Draft                                                  P. Leach
5Expires: October 2, 2005                                   K. Jaganathan
6                                                   Microsoft Corporation
7                                                          March 31, 2005
8
9
10              Kerberos Cryptosystem Negotiation Extension
11                      draft-zhu-kerb-enctype-nego-01
12
13Status of this Memo
14
15   This document is an Internet-Draft and is subject to all provisions
16   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
17   author represents that any applicable patent or other IPR claims of
18   which he or she is aware have been or will be disclosed, and any of
19   which he or she become aware will be disclosed, in accordance with
20   RFC 3668.
21
22   Internet-Drafts are working documents of the Internet Engineering
23   Task Force (IETF), its areas, and its working groups.  Note that
24   other groups may also distribute working documents as
25   Internet-Drafts.
26
27   Internet-Drafts are draft documents valid for a maximum of six months
28   and may be updated, replaced, or obsoleted by other documents at any
29   time.  It is inappropriate to use Internet-Drafts as reference
30   material or to cite them other than as "work in progress."
31
32   The list of current Internet-Drafts can be accessed at
33   http://www.ietf.org/ietf/1id-abstracts.txt.
34
35   The list of Internet-Draft Shadow Directories can be accessed at
36   http://www.ietf.org/shadow.html.
37
38   This Internet-Draft will expire on October 2, 2005.
39
40Copyright Notice
41
42   Copyright (C) The Internet Society (2005).
43
44Abstract
45
46   This document specifies an extension by Kerberos to negotiate new
47   encryption types between the client-server peers.
48
49
50
51
52
53
54Zhu, et al.              Expires October 2, 2005                [Page 1]
55
56Internet-Draft             Enctype Negotiation                March 2005
57
58
59Table of Contents
60
61   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
62   2.   Conventions Used in This Document  . . . . . . . . . . . . . . 3
63   3.   Negotiation Extension  . . . . . . . . . . . . . . . . . . . . 3
64   4.   Security Considerations  . . . . . . . . . . . . . . . . . . . 4
65   5.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 4
66   6.   Normative References . . . . . . . . . . . . . . . . . . . . . 4
67        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 5
68   A.   Leveraging this Enctype Negotiation in Windows SPNEGO
69        Implementations  . . . . . . . . . . . . . . . . . . . . . . . 5
70        Intellectual Property and Copyright Statements . . . . . . . . 7
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, et al.              Expires October 2, 2005                [Page 2]
111
112Internet-Draft             Enctype Negotiation                March 2005
113
114
1151.  Introduction
116
117   Under the current mechanism [CLAR], the KDC must limit the ticket
118   session key enctype chosen for a given server to one it believes is
119   supported by both the client and the server.  If both the client and
120   server understand a stronger enctype than the one selected by the
121   KDC, they can not negotiate it.  As the result, the protection of
122   application traffic is often weaker than necessary when the server
123   can support different sets of enctypes depending on the server
124   application software being used.
125
126   This document specifies an extension to Kerberos to allow clients and
127   servers to negotiate a different and possible stronger cryptosystem
128   to be used in subsequent communication.
129
130   This extension utilizes an authorization data element in the
131   authenticator of the AP-REQ message [CLAR].  The client sends the
132   list of enctypes that it supports to the server, the server then
133   informs the client its choice.  The negotiated subkey is sent in the
134   AP-REP message [CLAR].
135
1362.  Conventions Used in This Document
137
138   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
139   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
140   document are to be interpreted as described in [RFC2119].
141
1423.  Negotiation Extension
143
144   If the client prefers an enctype over that of the service ticket
145   session key, then it MUST send the list of enctypes it supports
146   (including the one selected by the KDC) in decreasing preference
147   order.
148
149   The client sends the enctype list via the authorization-data of the
150   authenticator in the AP-REQ [CLAR].  A new authorization data element
151   type AD-ETYPE-NEGOTIATION (129) is defined.  This authorization data
152   element itself is enclosed in the AD-IF-RELEVANT container, thus a
153   correctly implemented server that does not understand this element
154   should ignore it [CLAR].  The value of this authorization element
155   contains the DER [X60] encoding of the following ASN.1 type:
156
157           EtypeList ::= SEQUENCE OF Int32
158              -- Specifies the enctypes supported by the client.
159              -- This enctype list is in decreasing preference order
160              -- (favorite choice first).
161              -- Int32 is defined in [CLAR].
162
163
164
165
166Zhu, et al.              Expires October 2, 2005                [Page 3]
167
168Internet-Draft             Enctype Negotiation                March 2005
169
170
171   If the EtypeList is present and the server prefers an enctype from
172   the client's enctype list over that of the AP-REQ authenticator
173   subkey (if that is present) or the service ticket session key, the
174   server MUST create a subkey using that enctype.  This negotiated
175   subkey is sent in the subkey field of AP-REP message and it MUST be
176   used for subsequent communication.
177
178   This negotiation extension MUST NOT be used when the client does not
179   expect the subkey in the AP-REP message from the server.
180
181   Note that to preserve the quality of randomness provided by the KDC,
182   implementations of this extension SHOULD consider using the service
183   ticket session key value as a source of additional entropy when
184   generating the negotiated subkey.  If the AP-REQ authenticator subkey
185   is present, it MAY also be used as a source of entropy.
186
187   The policy by which the client or the server chooses an enctype
188   (i.e., how the preference order for the supported enctypes is
189   selected) is an implementation-specific local matter.
190
1914.  Security Considerations
192
193   The client's enctype list and the server's reply enctype are part of
194   encrypted data, thus the security considerations are the same as
195   those of the Kerberos encrypted data.
196
197   In all cases, the communicating peers are exposed to the denial of
198   service threat.
199
2005.  IANA Considerations
201
202   No IANA actions are required for this document.
203
2046.  Normative References
205
206   [CLAR]     RFC-Editor: To be replaced by RFC number for draft-ietf-
207              krb-wg-kerberos-clarifications.  Work in Progress. 
208                            
209   [GSS-CFX]  RFC-Editor: To be replaced by RFC number for draft-ietf-
210              krb-wg-gssapi-cfx.  Work in Progress. 
211
212   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
213              Requirement Levels", BCP 14, RFC 2119, March 1997.
214
215   [RFC2743]  Linn, J., "Generic Security Service Application Program
216              Interface Version 2, Update 1", RFC 2743, January 2000.
217
218
219
220
221Zhu, et al.              Expires October 2, 2005                [Page 4]
222
223Internet-Draft             Enctype Negotiation                March 2005
224
225
226   [SPNEGOBIS]
227              RFC-Editor: To be replaced by RFC number for draft-ietf-
228              kitten-2478bis.  Work in progress.
229
230   [X690]     ASN.1 encoding rules: Specification of Basic Encoding Rules 
231              (BER), Canonical Encoding Rules (CER) and Distinguished 
232              Encoding Rules (DER), ITU-T Recommendation X.690 (1997) | 
233              ISO/IEC International Standard 8825-1:1998.
234
235
236Authors' Addresses
237
238   Larry Zhu
239   Microsoft Corporation
240   One Microsoft Way
241   Redmond, WA  98052
242   US
243
244   Email: lzhu@microsoft.com
245
246
247   Paul Leach
248   Microsoft Corporation
249   One Microsoft Way
250   Redmond, WA  98052
251   US
252
253   Email: paulle@microsoft.com
254
255
256   Karthik Jaganathan
257   Microsoft Corporation
258   One Microsoft Way
259   Redmond, WA  98052
260   US
261
262   Email: karthikj@microsoft.com
263
264Appendix A.  Leveraging this Enctype Negotiation in Windows SPNEGO
265            Implementations
266
267   The SPNEGO implementations in Windows 2000, Windows XP and Windows
268   2003 do not generate or verify the mechlistMIC field when it is
269   required [SPNEGOBIS].
270
271   When the SPNEGO implementations that are updated according to
272   [SPNEGOBIS], an SSPI initiator or acceptor needs to determine if the
273   peer is updated, so that it can generate the mechlistMIC token when
274   the peer can process it.  With the bidirectional negotiation, the
275   updated SPNEGO implementation can achieve the following two goals:
276
277
278
279
280
281Zhu, et al.              Expires October 2, 2005                [Page 5]
282
283Internet-Draft             Enctype Negotiation                March 2005
284
285
286   o  It can remain backward compatible with legacy implementations, if
287      local policy allows unsafe and unprotected negotiation with
288      downlevel implementations when the mechlistMIC token exchange
289      would otherwise be required by [SPNEGOBIS].
290
291   o  The mechanism negotiation is protected according to [SPNEGOBIS]
292      when both peers are updated.
293
294   However, the updated SPNEGO implementation itself can not securely
295   inform the peer whether the local implementation is updated, thus it
296   has to obtain such information from the negotiated mechanism.
297
298   For Windows SPNEGO implementations, both the initiator and the
299   acceptor are assumed to have been updated if a "newer" [CLAR] or
300   different enctype is negotiated for use by the Kerberos GSS-API
301   mechanism.
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337Zhu, et al.              Expires October 2, 2005                [Page 6]
338
339Internet-Draft             Enctype Negotiation                March 2005
340
341
342Intellectual Property Statement
343
344   The IETF takes no position regarding the validity or scope of any
345   Intellectual Property Rights or other rights that might be claimed to
346   pertain to the implementation or use of the technology described in
347   this document or the extent to which any license under such rights
348   might or might not be available; nor does it represent that it has
349   made any independent effort to identify any such rights.  Information
350   on the procedures with respect to rights in RFC documents can be
351   found in BCP 78 and BCP 79.
352
353   Copies of IPR disclosures made to the IETF Secretariat and any
354   assurances of licenses to be made available, or the result of an
355   attempt made to obtain a general license or permission for the use of
356   such proprietary rights by implementers or users of this
357   specification can be obtained from the IETF on-line IPR repository at
358   http://www.ietf.org/ipr.
359
360   The IETF invites any interested party to bring to its attention any
361   copyrights, patents or patent applications, or other proprietary
362   rights that may cover technology that may be required to implement
363   this standard.  Please address the information to the IETF at
364   ietf-ipr@ietf.org.
365
366
367Disclaimer of Validity
368
369   This document and the information contained herein are provided on an
370   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
371   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
372   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
373   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
374   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
375   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
376
377
378Copyright Statement
379
380   Copyright (C) The Internet Society (2005).  This document is subject
381   to the rights, licenses and restrictions contained in BCP 78, and
382   except as set forth therein, the authors retain all their rights.
383
384
385Acknowledgment
386
387   Funding for the RFC Editor function is currently provided by the
388   Internet Society.
389
390
391
392
393Zhu, et al.              Expires October 2, 2005                [Page 7]
394
395
396