1 2 3 4Network Working Group L. Hornquist Astrand 5Internet-Draft Stockholm University 6Expires: September 2, 2006 L. Zhu 7 Microsoft Corporation 8 March 2006 9 10 11 PK-INIT algorithm agility 12 draft-ietf-krb-wg-pkinit-alg-agility-00 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 September 2, 2006. 38 39Copyright Notice 40 41 Copyright (C) The Internet Society (2006). 42 43Abstract 44 45 The PK-INIT protocol have in several places hard coded crypto 46 algorithms. The protocol specification needs to be updated so it can 47 support negotiation to upgrading to newer versions of crypto 48 algorithms. This document addresses this issue. 49 50 51 52 53 54 55Hornquist Astrand & Zhu Expires September 2, 2006 [Page 1] 56 57Internet-Draft PK-INIT algorithm agility March 2006 58 59 60Table of Contents 61 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 64 3. paChecksum agility . . . . . . . . . . . . . . . . . . . . . . 5 65 4. CMS Digest Algorithm agility . . . . . . . . . . . . . . . . . 6 66 5. Certificate Signer Algorithm Identifier agility . . . . . . . 7 67 6. octetstring2key function agility . . . . . . . . . . . . . . . 8 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 9. Normative References . . . . . . . . . . . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 72 Intellectual Property and Copyright Statements . . . . . . . . . . 12 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 111Hornquist Astrand & Zhu Expires September 2, 2006 [Page 2] 112 113Internet-Draft PK-INIT algorithm agility March 2006 114 115 1161. Introduction 117 118 The Kerberos PK-INIT document contains several hardcoded algorithms 119 that was know designed at design time that they had to be replaced by 120 something else at a later time, this document described how to use 121 other algorithms other then those that are hard-coded. 122 123 124 125 126 127 128 129 130 131 132 133 134 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 166 167Hornquist Astrand & Zhu Expires September 2, 2006 [Page 3] 168 169Internet-Draft PK-INIT algorithm agility March 2006 170 171 1722. Requirements notation 173 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in [RFC2119]. 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 222 223Hornquist Astrand & Zhu Expires September 2, 2006 [Page 4] 224 225Internet-Draft PK-INIT algorithm agility March 2006 226 227 2283. paChecksum agility 229 230 The paChecksum binds the PK-INIT part of the request to main body of 231 the Kerberos request (KDC-REQ-BODY). This is to makes sure an 232 attacker can not change the request from the client to the server. 233 The problem is that paChecksum is hardcoded to use SHA1-1, however, 234 there is a mechaism to provide algorithm agility for the paChecksum 235 within the PK-INIT prototcol. Newer clients can choose not send the 236 paChecksum field, but rather add some new fields after the existing 237 fields, older KDC will send back know failure-code so that newer 238 clients can fall back to the old protocol if local policy allows 239 that. 240 241 If the attacker can preserve the checksum in paChecksum, an attacker 242 can, for example, change the KDC-REQ-BODY is to downgrade the 243 encryption types used, expend the expiration time, etc, and then try 244 to brute-force the request. 245 246 In the Public Key Encryption case of PK-INIT the reply contains a 247 checksum over the whole request in the asChecksum field, in this case 248 the client will detect any modifications to the request. Since the 249 asChecksum is using the associated checksum of the session key 250 encryption type, asChecksum field is algorithm agile. 251 252 One way to solve this problem is to add the asChecksum to the Diffie- 253 Hellman case reply too, and just ignore the paCheckSum field. The 254 KDC should still not issue tickets that are too weak, since that 255 exposes the problem. This is regardless of the using PK-INIT or not. 256 257 Questions for wg: Wait for Kerberos Extensions that will solve this 258 problem (ignore the problem for how), or use add asChecksum to DH 259 case. 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279Hornquist Astrand & Zhu Expires September 2, 2006 [Page 5] 280 281Internet-Draft PK-INIT algorithm agility March 2006 282 283 2844. CMS Digest Algorithm agility 285 286 The client can tell KDC what the supported CMS types are in the 287 requset packet, but there are no equivalent for KDC to the the client 288 what the digest algorithm are support in an reply. 289 290 Have KDC send the CMS list of supported encryption types in the 291 e-data field of KRB-ERROR when returning the 292 KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error. 293 294 DER encoded TS-SD-PARAMETERS specifies supported digest algorithms. 295 The list is in decreasing preference order. 296 297 298 299 TD-SD-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier 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 335Hornquist Astrand & Zhu Expires September 2, 2006 [Page 6] 336 337Internet-Draft PK-INIT algorithm agility March 2006 338 339 3405. Certificate Signer Algorithm Identifier agility 341 342 The KDC can reject a certificate based on the signers hash algorithm 343 with the error KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED, but doesn't tell 344 the client what algorithm are supported. 345 346 DER encoded TS-DC-PARAMETERS specifies supported certificate digest 347 algorithms. The AllowedAlgorithms is in decreasing preference order. 348 RejectedAlgorithm may be include my the KDC to tell what algorithm 349 was rejected in case the rejected certificate was part of a computed 350 chain. 351 352 353 354 TD-DC-PARAMETERS ::= SEQUENCE { 355 AllowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier, 356 RejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL 357 } 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391Hornquist Astrand & Zhu Expires September 2, 2006 [Page 7] 392 393Internet-Draft PK-INIT algorithm agility March 2006 394 395 3966. octetstring2key function agility 397 398 The PK-INIT standard uses a home-grown string 2 key function in the 399 DH case. The function uses SHA-1 to mix and stretch the DH shared 400 key. 401 402 Describe how the client announces that is supports the new String to 403 key function. Probably by stuffing it into the supportCMSTypes field 404 in the request. 405 406 Use NIST SP 800 56B when its published. 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 446 447Hornquist Astrand & Zhu Expires September 2, 2006 [Page 8] 448 449Internet-Draft PK-INIT algorithm agility March 2006 450 451 4527. Security Considerations 453 454 This document describes negotiation of checksum types and other 455 cryptographic functions. Most of this negotiation is done 456 unauthenticated with no way to very 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503Hornquist Astrand & Zhu Expires September 2, 2006 [Page 9] 504 505Internet-Draft PK-INIT algorithm agility March 2006 506 507 5088. IANA Considerations 509 510 No IANA considerations. 511 5129. Normative References 513 514 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 515 Requirement Levels", BCP 14, RFC 2119, March 1997. 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559Hornquist Astrand & Zhu Expires September 2, 2006 [Page 10] 560 561Internet-Draft PK-INIT algorithm agility March 2006 562 563 564Authors' Addresses 565 566 Love Hornquist Astrand 567 Stockholm University 568 SE-106 91 STOCKHOLM 569 SWEDEN 570 571 Email: lha@it.su.se 572 573 574 Larry Zhu 575 Microsoft Corporation 576 One Microsoft Way 577 Redmond, WA 98052 578 US 579 580 Email: lzhu@microsoft.com 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615Hornquist Astrand & Zhu Expires September 2, 2006 [Page 11] 616 617Internet-Draft PK-INIT algorithm agility March 2006 618 619 620Intellectual Property Statement 621 622 The IETF takes no position regarding the validity or scope of any 623 Intellectual Property Rights or other rights that might be claimed to 624 pertain to the implementation or use of the technology described in 625 this document or the extent to which any license under such rights 626 might or might not be available; nor does it represent that it has 627 made any independent effort to identify any such rights. Information 628 on the procedures with respect to rights in RFC documents can be 629 found in BCP 78 and BCP 79. 630 631 Copies of IPR disclosures made to the IETF Secretariat and any 632 assurances of licenses to be made available, or the result of an 633 attempt made to obtain a general license or permission for the use of 634 such proprietary rights by implementers or users of this 635 specification can be obtained from the IETF on-line IPR repository at 636 http://www.ietf.org/ipr. 637 638 The IETF invites any interested party to bring to its attention any 639 copyrights, patents or patent applications, or other proprietary 640 rights that may cover technology that may be required to implement 641 this standard. Please address the information to the IETF at 642 ietf-ipr@ietf.org. 643 644 645Disclaimer of Validity 646 647 This document and the information contained herein are provided on an 648 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 649 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 650 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 651 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 652 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 653 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 654 655 656Copyright Statement 657 658 Copyright (C) The Internet Society (2006). This document is subject 659 to the rights, licenses and restrictions contained in BCP 78, and 660 except as set forth therein, the authors retain all their rights. 661 662 663Acknowledgment 664 665 Funding for the RFC Editor function is currently provided by the 666 Internet Society. 667 668 669 670 671Hornquist Astrand & Zhu Expires September 2, 2006 [Page 12] 672 673