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