1 2 3NETWORK WORKING GROUP L. Zhu 4Internet-Draft P. Leach 5Expires: June 4, 2005 K. Jaganathan 6 Microsoft Corporation 7 December 2004 8 9 10 Kerberos Cryptosystem Negotiation Extension 11 draft-zhu-kerb-enctype-nego-00 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 June 4, 2005. 39 40Copyright Notice 41 42 Copyright (C) The Internet Society (2004). 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 June 4, 2005 [Page 1] 55 56Internet-Draft Enctype Negotiation December 2004 57 58 59Table of Contents 60 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions Used in This Document . . . . . . . . . . . . . 4 63 3. Negotiation Protocol . . . . . . . . . . . . . . . . . . . . 5 64 4. Security Considerations . . . . . . . . . . . . . . . . . . 6 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 66 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 7 68 A. Leveraging this Enctype Negotiation in Windows SPNEGO 69 Implementations . . . . . . . . . . . . . . . . . . . . . . 9 70 Intellectual Property and Copyright Statements . . . . . . . 10 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 June 4, 2005 [Page 2] 111 112Internet-Draft Enctype Negotiation December 2004 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 service 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 is selected by the KDC, 121 they can not negotiate it. As the result, the protection of 122 application traffic is often weaker than necessary when different 123 application software that support different set of enctypes can be 124 used by the same server principal. 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 KRB_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 KRB_AP_REP. 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166Zhu, et al. Expires June 4, 2005 [Page 3] 167 168Internet-Draft Enctype Negotiation December 2004 169 170 1712. Conventions Used in This Document 172 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in [RFC2119]. 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222Zhu, et al. Expires June 4, 2005 [Page 4] 223 224Internet-Draft Enctype Negotiation December 2004 225 226 2273. Negotiation Protocol 228 229 If the client prefers an enctype over that of the service ticket 230 session key, then it MUST send the list of enctypes it supports 231 (including the one selected by the KDC), in decreasing preference 232 order. 233 234 The client sends the enctype list via the authorization-data of the 235 authenticator in the KRB_AP_REQ [CLAR]. A new authorization data 236 element type AD-ETYPE-NEGOTIATION (129) is defined. This 237 authorization data element itself is enclosed in the AD-IF-RELEVANT 238 container, thus a correctly implemented server that does not 239 understand this element should ignore it [CLAR]. The value of this 240 authorization element contains the DER [X60] encoding of the 241 following ASN.1 type: 242 243 EtypeList ::= SEQUENCE OF Int32 244 -- the client's proposed enctype list in decreasing 245 -- preference order, favorite choice first 246 247 If the EtypeList is present and the server prefers an enctype from 248 the client's enctype list over that of the KRB_AP_REQ authenticator 249 subkey (if that is present) or the service ticket session key, the 250 server MUST create a subkey using that enctype. This negotiated 251 subkey is sent in the subkey field of KRB_AP_REP message and it MUST 252 be used for subsequent communication. 253 254 Note that to preserve the quality of randomness provided by the KDC, 255 implementations of this protocol SHOULD consider using the service 256 ticket session key value as a source of additional entropy when 257 generating the negotiated subkey. If the KRB_AP_REQ authenticator 258 subkey is present, it MAY also be used as a source of entropy. 259 260 The policy by which the client or the server chooses an enctype 261 (i.e., how the preference order for the supported enctypes is 262 selected) is an implementation-specific local matter. 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278Zhu, et al. Expires June 4, 2005 [Page 5] 279 280Internet-Draft Enctype Negotiation December 2004 281 282 2834. Security Considerations 284 285 The client's enctype list and the server's reply enctype are part of 286 encrypted data, thus the security considerations are the same as 287 those of the Kerberos encrypted data. 288 289 In all cases, the communicating peers are exposed to the denial of 290 service threat. 291 292 293 294 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 334Zhu, et al. Expires June 4, 2005 [Page 6] 335 336Internet-Draft Enctype Negotiation December 2004 337 338 3395. IANA Considerations 340 341 No IANA actions are required for this document. 342 3436. Normative References 344 345 [CLAR] Neuman, B., Yu, Y., Hartman, S. and K. Raeburn, "The 346 Kerberos Network Authentication Service (V5)", August 347 2004. 348 349 [GSS-CFX] Zhu, L., Jaganathan, K. and S. Hartman, "The Kerberos 350 Version 5 GSS-API Mechanism: Version 2", November 2004. 351 352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 353 Requirement Levels", BCP 14, RFC 2119, March 1997. 354 355 [RFC2743] Linn, J., "Generic Security Service Application Program 356 Interface Version 2, Update 1", RFC 2743, January 2000. 357 358 [SPNEGOBIS] 359 Zhu, L., Leach, P., Jaganathan, K., Hartman, S. and W. 360 Ingersoll, "The Simple and Protected GSS-API Negotiation 361 Mechanism", November 2004. 362 363 364Authors' Addresses 365 366 Larry Zhu 367 Microsoft Corporation 368 One Microsoft Way 369 Redmond, WA 98052 370 US 371 372 Email: lzhu@microsoft.com 373 374 375 Paul Leach 376 Microsoft Corporation 377 One Microsoft Way 378 Redmond, WA 98052 379 US 380 381 Email: paulle@microsoft.com 382 383 384 385 386 387 388 389 390Zhu, et al. Expires June 4, 2005 [Page 7] 391 392Internet-Draft Enctype Negotiation December 2004 393 394 395 Karthik Jaganathan 396 Microsoft Corporation 397 One Microsoft Way 398 Redmond, WA 98052 399 US 400 401 Email: karthikj@microsoft.com 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446Zhu, et al. Expires June 4, 2005 [Page 8] 447 448Internet-Draft Enctype Negotiation December 2004 449 450 451Appendix A. Leveraging this Enctype Negotiation in Windows SPNEGO 452 Implementations 453 454 The SPNEGO implementations in Windows 2000, Windows XP and Windows 455 2003 do not generate or verify the mechlistMIC field when it is 456 required [SPNEGOBIS]. 457 458 When the SPNEGO implementations that are updated according to 459 [SPNEGOBIS], an SSPI initiator or acceptor needs to determine if the 460 peer is updated, so that it can generate the mechlistMIC token when 461 the peer can process it. With the bidirectional negotiation, the 462 updated SPNEGO implementation can achieve the following two goals: 463 464 o It can remain backward compatible with legacy implementations, if 465 local policy allows unsafe and unprotected negotiation with 466 downlevel implementations when the mechlistMIC token exchange 467 would otherwise be required by [SPNEGOBIS]. 468 o The mechanism negotiation is protected according to [SPNEGOBIS] 469 when both peers are updated. 470 471 However, the updated SPNEGO implementation itself can not securely 472 inform the peer whether the local implementation is updated, thus it 473 has to obtain such information from the negotiated mechanism. 474 475 For Windows SPNEGO implementations, both the initiator and the 476 acceptor are assumed to have been updated if a "newer" [CLAR] or 477 different enctype is negotiated for use by the Kerberos GSS-API 478 mechanism. 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502Zhu, et al. Expires June 4, 2005 [Page 9] 503 504Internet-Draft Enctype Negotiation December 2004 505 506 507Intellectual Property Statement 508 509 The IETF takes no position regarding the validity or scope of any 510 Intellectual Property Rights or other rights that might be claimed to 511 pertain to the implementation or use of the technology described in 512 this document or the extent to which any license under such rights 513 might or might not be available; nor does it represent that it has 514 made any independent effort to identify any such rights. Information 515 on the procedures with respect to rights in RFC documents can be 516 found in BCP 78 and BCP 79. 517 518 Copies of IPR disclosures made to the IETF Secretariat and any 519 assurances of licenses to be made available, or the result of an 520 attempt made to obtain a general license or permission for the use of 521 such proprietary rights by implementers or users of this 522 specification can be obtained from the IETF on-line IPR repository at 523 http://www.ietf.org/ipr. 524 525 The IETF invites any interested party to bring to its attention any 526 copyrights, patents or patent applications, or other proprietary 527 rights that may cover technology that may be required to implement 528 this standard. Please address the information to the IETF at 529 ietf-ipr@ietf.org. 530 531 532Disclaimer of Validity 533 534 This document and the information contained herein are provided on an 535 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 536 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 537 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 538 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 539 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 540 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 541 542 543Copyright Statement 544 545 Copyright (C) The Internet Society (2004). This document is subject 546 to the rights, licenses and restrictions contained in BCP 78, and 547 except as set forth therein, the authors retain all their rights. 548 549 550Acknowledgment 551 552 Funding for the RFC Editor function is currently provided by the 553 Internet Society. 554 555 556 557 558Zhu, et al. Expires June 4, 2005 [Page 10] 559 560 561