4 NETWORK WORKING GROUP L. Zhu
5 Internet-Draft P. Leach
6 Updates: 4120 (if approved) K. Jaganathan
7 Expires: January 20, 2006 Microsoft Corporation
11 Kerberos Cryptosystem Negotiation Extension
12 draft-zhu-kerb-enctype-nego-03
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.
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-
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."
31 The list of current Internet-Drafts can be accessed at
32 http://www.ietf.org/ietf/1id-abstracts.txt.
34 The list of Internet-Draft Shadow Directories can be accessed at
35 http://www.ietf.org/shadow.html.
37 This Internet-Draft will expire on January 20, 2006.
41 Copyright (C) The Internet Society (2005).
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.
55 Zhu, et al. Expires January 20, 2006 [Page 1]
57 Internet-Draft Enctype Negotiation July 2005
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
111 Zhu, et al. Expires January 20, 2006 [Page 2]
113 Internet-Draft Enctype Negotiation July 2005
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.
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.
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].
137 2. Conventions Used in This Document
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].
143 3. Negotiation Extension
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
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.
154 AD-ETYPE-NEGOTIATION 129
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:
167 Zhu, et al. Expires January 20, 2006 [Page 3]
169 Internet-Draft Enctype Negotiation July 2005
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].
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
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.
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.
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.
202 4. Security Considerations
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.
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.
218 The authors would like to thank the following individuals for their
219 comments and suggestions: Luke Howard, Tom Yu, Love Hornquist
223 Zhu, et al. Expires January 20, 2006 [Page 4]
225 Internet-Draft Enctype Negotiation July 2005
228 Astrand, Sam Harman, Ken Raeburn and Martin Rex.
230 6. IANA Considerations
232 No IANA actions are required for this document.
234 7. Normative References
236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
237 Requirement Levels", BCP 14, RFC 2119, March 1997.
239 [RFC2743] Linn, J., "Generic Security Service Application Program
240 Interface Version 2, Update 1", RFC 2743, January 2000.
242 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
243 Kerberos 5", RFC 3961, February 2005.
245 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
246 Kerberos Network Authentication Service (V5)", RFC 4120,
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.
257 Microsoft Corporation
262 Email: lzhu@microsoft.com
266 Microsoft Corporation
271 Email: paulle@microsoft.com
283 Zhu, et al. Expires January 20, 2006 [Page 5]
285 Internet-Draft Enctype Negotiation July 2005
289 Microsoft Corporation
294 Email: karthikj@microsoft.com
339 Zhu, et al. Expires January 20, 2006 [Page 6]
341 Internet-Draft Enctype Negotiation July 2005
344 Intellectual Property Statement
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.
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.
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
369 Disclaimer of Validity
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.
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.
389 Funding for the RFC Editor function is currently provided by the
395 Zhu, et al. Expires January 20, 2006 [Page 7]