1
2
3
4NETWORK WORKING GROUP                                             L. Zhu
5Internet-Draft                                                  P. Leach
6Updates: 4120 (if approved)                                K. Jaganathan
7Expires: January 20, 2006                          Microsoft Corporation
8                                                           July 19, 2005
9
10
11              Kerberos Cryptosystem Negotiation Extension
12                     draft-zhu-kerb-enctype-nego-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 20, 2006.
38
39Copyright Notice
40
41   Copyright (C) The Internet Society (2005).
42
43Abstract
44
45   This document specifies an extension to the Kerberos protocol where
46   the client can send a list of supported encryption types in
47   decreasing preference order, and the server then selects an
48   encryption type that is supported by both the client and the server.
49
50
51
52
53
54
55Zhu, et al.             Expires January 20, 2006                [Page 1]
56
57Internet-Draft             Enctype Negotiation                 July 2005
58
59
60Table of Contents
61
62   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
63   2.   Conventions Used in This Document  . . . . . . . . . . . . . . 3
64   3.   Negotiation Extension  . . . . . . . . . . . . . . . . . . . . 3
65   4.   Security Considerations  . . . . . . . . . . . . . . . . . . . 4
66   5.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4
67   6.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 5
68   7.   Normative References . . . . . . . . . . . . . . . . . . . . . 5
69        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 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
110
111Zhu, et al.             Expires January 20, 2006                [Page 2]
112
113Internet-Draft             Enctype Negotiation                 July 2005
114
115
1161.  Introduction
117
118   Under the current mechanism [RFC4120], the KDC must limit the ticket
119   session key encryption type (enctype) chosen for a given server to
120   one it believes is supported by both the client and the server.  If
121   both the client and server understand a stronger enctype than the one
122   selected by the KDC, they can not negotiate it.  As the result, the
123   protection of application traffic is often weaker than necessary when
124   the server can support different sets of enctypes depending on the
125   server application software being used.
126
127   This document specifies an extension to the Kerberos protocol to
128   allow clients and servers to negotiate a different and possible
129   stronger cryptosystem to be used in subsequent communication.
130
131   This extension utilizes an authorization data element in the
132   authenticator of the AP-REQ message [RFC4120].  The client sends the
133   list of enctypes that it supports to the server, the server then
134   informs the client its choice.  The negotiated subkey is sent in the
135   AP-REP message [RFC4120].
136
1372.  Conventions Used in This Document
138
139   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
140   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
141   document are to be interpreted as described in [RFC2119].
142
1433.  Negotiation Extension
144
145   If the client prefers an enctype over that of the service ticket
146   session key, then it sends the list of enctypes it supports
147   (including the one selected by the KDC) in decreasing preference
148   order.
149
150   The client sends the enctype list via the authorization-data of the
151   authenticator in the AP-REQ [RFC4120].  A new authorization data
152   element type AD-ETYPE-NEGOTIATION is defined.
153
154           AD-ETYPE-NEGOTIATION              129
155
156   This authorization data element itself is enclosed in the AD-IF-
157   RELEVANT container, thus a correctly implemented server that does not
158   understand this element should ignore it [RFC4120].  The value of
159   this authorization element contains the DER [X690] encoding of the
160   following ASN.1 type:
161
162
163
164
165
166
167Zhu, et al.             Expires January 20, 2006                [Page 3]
168
169Internet-Draft             Enctype Negotiation                 July 2005
170
171
172           EtypeList ::= SEQUENCE OF Int32
173              -- Specifies the enctypes supported by the client.
174              -- This enctype list is in decreasing preference order
175              -- (favorite choice first).
176              -- Int32 is defined in [RFC4120].
177
178   If the EtypeList is present and the server prefers an enctype from
179   the client's enctype list over that of the AP-REQ authenticator
180   subkey (if that is present) or the service ticket session key, the
181   server MUST create a subkey using that enctype.  This negotiated
182   subkey is sent in the subkey field of AP-REP message and it is then
183   used as the protocol key or base key [RFC3961] for subsequent
184   communication.
185
186   This negotiation extension SHOULD NOT be used when the client does
187   not expect the subkey in the AP-REP message from the server.
188
189   A note on key generation: The KDC has a strong Pseudo-Random Number
190   Generator (PRNG), as such the client can take advantage of the
191   randomness provided by the KDC by reusing the KDC key data when
192   generating keys.  Implementations SHOULD use the service ticket
193   session key value as a source of additional entropy when generating
194   the negotiated subkey.  If the AP-REQ authenticator subkey is
195   present, it MAY also be used as a source of entropy.
196
197   The server MAY ignore the preference order indicated by the client.
198   The policy by which the client or the server chooses an enctype
199   (i.e., how the preference order for the supported enctypes is
200   selected) is a local matter.
201
2024.  Security Considerations
203
204   The client's enctype list and the server's reply enctype are part of
205   encrypted data, thus the security considerations are the same as
206   those of the Kerberos encrypted data.
207
208   Both the EtypeList and the server's sub-session key are protected by
209   the session key or sub-session key used for the AP-REQ, and as a
210   result, if a key for a stronger enctype is negotiated underneath a
211   key for a weaker enctype, an attacker capable of breaking the weaker
212   enctype can also discover the key for the stronger enctype.  The
213   advantage of this extension is to minimize the amount of cipher text
214   encrypted under a weak enctype to which an attacker has access.
215
2165.  Acknowledgements
217
218   The authors would like to thank the following individuals for their
219   comments and suggestions: Luke Howard, Tom Yu, Love Hornquist
220
221
222
223Zhu, et al.             Expires January 20, 2006                [Page 4]
224
225Internet-Draft             Enctype Negotiation                 July 2005
226
227
228   Astrand, Sam Harman, Ken Raeburn and Martin Rex.
229
2306.  IANA Considerations
231
232   No IANA actions are required for this document.
233
2347.  Normative References
235
236   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
237              Requirement Levels", BCP 14, RFC 2119, March 1997.
238
239   [RFC2743]  Linn, J., "Generic Security Service Application Program
240              Interface Version 2, Update 1", RFC 2743, January 2000.
241
242   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
243              Kerberos 5", RFC 3961, February 2005.
244
245   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
246              Kerberos Network Authentication Service (V5)", RFC 4120,
247              July 2005.
248
249   [X690]     ASN.1 encoding rules: Specification of Basic Encoding Rules 
250              (BER), Canonical Encoding Rules (CER) and Distinguished 
251              Encoding Rules (DER), ITU-T Recommendation X.690 (1997) | 
252              ISO/IEC International Standard 8825-1:1998.
253
254Authors' Addresses
255
256   Larry Zhu
257   Microsoft Corporation
258   One Microsoft Way
259   Redmond, WA  98052
260   US
261
262   Email: lzhu@microsoft.com
263
264
265   Paul Leach
266   Microsoft Corporation
267   One Microsoft Way
268   Redmond, WA  98052
269   US
270
271   Email: paulle@microsoft.com
272
273
274
275
276
277
278
279
280
281
282
283Zhu, et al.             Expires January 20, 2006                [Page 5]
284
285Internet-Draft             Enctype Negotiation                 July 2005
286
287
288   Karthik Jaganathan
289   Microsoft Corporation
290   One Microsoft Way
291   Redmond, WA  98052
292   US
293
294   Email: karthikj@microsoft.com
295
296
297
298
299
300
301
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
337
338
339Zhu, et al.             Expires January 20, 2006                [Page 6]
340
341Internet-Draft             Enctype Negotiation                 July 2005
342
343
344Intellectual Property Statement
345
346   The IETF takes no position regarding the validity or scope of any
347   Intellectual Property Rights or other rights that might be claimed to
348   pertain to the implementation or use of the technology described in
349   this document or the extent to which any license under such rights
350   might or might not be available; nor does it represent that it has
351   made any independent effort to identify any such rights.  Information
352   on the procedures with respect to rights in RFC documents can be
353   found in BCP 78 and BCP 79.
354
355   Copies of IPR disclosures made to the IETF Secretariat and any
356   assurances of licenses to be made available, or the result of an
357   attempt made to obtain a general license or permission for the use of
358   such proprietary rights by implementers or users of this
359   specification can be obtained from the IETF on-line IPR repository at
360   http://www.ietf.org/ipr.
361
362   The IETF invites any interested party to bring to its attention any
363   copyrights, patents or patent applications, or other proprietary
364   rights that may cover technology that may be required to implement
365   this standard.  Please address the information to the IETF at
366   ietf-ipr@ietf.org.
367
368
369Disclaimer of Validity
370
371   This document and the information contained herein are provided on an
372   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
373   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
374   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
375   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
376   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
377   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
378
379
380Copyright Statement
381
382   Copyright (C) The Internet Society (2005).  This document is subject
383   to the rights, licenses and restrictions contained in BCP 78, and
384   except as set forth therein, the authors retain all their rights.
385
386
387Acknowledgment
388
389   Funding for the RFC Editor function is currently provided by the
390   Internet Society.
391
392
393
394
395Zhu, et al.             Expires January 20, 2006                [Page 7]
396
397
398