1 2 3Network Working Group L. Hornquist Astrand 4Internet-Draft Stockholm University 5Intended status: Standards Track L. Zhu 6Expires: January 10, 2008 Microsoft Corporation 7 July 9, 2007 8 9 10 PK-INIT algorithm agility 11 draft-ietf-krb-wg-pkinit-alg-agility-03 12 13Status of this Memo 14 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 24 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 29 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 32 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 35 36 This Internet-Draft will expire on January 10, 2008. 37 38Copyright Notice 39 40 Copyright (C) The IETF Trust (2007). 41 42 43 44 45 46 47 48 49 50 51 52 53 54Hornquist Astrand & Zhu Expires January 10, 2008 [Page 1] 55 56Internet-Draft PK-INIT algorithm agility July 2007 57 58 59Abstract 60 61 The PK-INIT defined in RFC 4556 is examined and updated to remove 62 protocol structures tied to specific cryptographic algorithms. The 63 affinity to SHA-1 as the checksum algorithm in the authentication 64 request is analyzed. The PK-INIT key derivation function is made 65 negotiable, the digest algorithms for signing the pre-authentication 66 data and the client's X.509 certificates are made discoverable. 67 68 These changes provide protection preemptively against vulnerabilities 69 discovered in the future against any specific cryptographic 70 algorithm, and allow incremental deployment of newer algorithms. 71 72 73Table of Contents 74 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 77 3. paChecksum Agility . . . . . . . . . . . . . . . . . . . . . . 6 78 4. CMS Digest Algorithm Agility . . . . . . . . . . . . . . . . . 7 79 5. X.509 Certificate Signer Algorithm Agility . . . . . . . . . . 8 80 6. KDF agility . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 86 10.2. Informative References . . . . . . . . . . . . . . . . . 17 87 Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 18 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 89 Intellectual Property and Copyright Statements . . . . . . . . . . 21 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110Hornquist Astrand & Zhu Expires January 10, 2008 [Page 2] 111 112Internet-Draft PK-INIT algorithm agility July 2007 113 114 1151. Introduction 116 117 In August 2004, Xiaoyun Wang's research group reported MD4 [RFC1320] 118 collisions generated using hand calculation [WANG04] alongside 119 attacks on later hash function designs in the MD4, MD5 [RFC1321] and 120 SHA [RFC4634] family. Implementations based on Wang's algorithm can 121 find collisions in real time. These discoveries challenged the 122 security for protocols relying on the collision resistance properties 123 of these hashes, for example one can forge a digital signature when 124 SHA-1 [RFC4634] is the digest algorithm. A more far reaching side 125 effect of these recent events, however, is that it is now generally 126 considered flawed or distasteful at least if protocols are designed 127 to use only specific algorithms. 128 129 The Internet Engineer Task Force (IETF) called for actions to update 130 existing protocols to provide crypto algorithm agility in order to 131 untie protocols with specific algorithms. The idea is that if the 132 protocol has crypto algorithm agility, and when a new vulnerability 133 specific to an algorithm is discovered, this algorithm can be 134 disabled via protocol negotiation quickly, thus we can avoid the wait 135 for the multi-year standardization and implementation efforts to 136 update the protocols. In additon, crypto agility allows deployment 137 of new crypto algorithms to be done incrementally, rather than 138 requring a "flag day" on which the change must be deployed everywhere 139 at the same time in order to maintain interoperability. 140 141 This document is to update PK-INIT [RFC4556] to provide crypto 142 algorithm agility. Several protocol structures used in the [RFC4556] 143 protocol are either tied to SHA-1, or require the algorithms not 144 negotiated but rather based on local policy. The following concerns 145 have been addressed: 146 147 o The checksum algorithm in the authentication request is hardwired 148 to use SHA-1 [RFC4634]. 149 150 o The acceptable digest algorithms for signing the authentication 151 data are not discoverable. 152 153 o The key derivation function in Section 3.2.3 of [RFC4556] is 154 hardwired to use SHA-1. 155 156 o The acceptable digest algorithms for signing the client X.509 157 certificates are not discoverable. 158 159 To accomplish these, new key derivation functions (KDFs) identifiable 160 by object identifiers are defined. The PKINIT client provides a list 161 of KDFs in the request and the KDC picks one in the response, thus a 162 mutually-supported KDF is negotiated. 163 164 165 166Hornquist Astrand & Zhu Expires January 10, 2008 [Page 3] 167 168Internet-Draft PK-INIT algorithm agility July 2007 169 170 171 Furthermore, structures are defined to allow the client discover the 172 Cryptographic Message Syntax (CMS) [RFC3852] digest algorithms 173 supported by the KDC for signing the pre-authentication data and 174 signing the client X.509 certificate. 175 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 222Hornquist Astrand & Zhu Expires January 10, 2008 [Page 4] 223 224Internet-Draft PK-INIT algorithm agility July 2007 225 226 2272. Requirements Notation 228 229 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 230 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 231 document are to be interpreted as described in [RFC2119]. 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278Hornquist Astrand & Zhu Expires January 10, 2008 [Page 5] 279 280Internet-Draft PK-INIT algorithm agility July 2007 281 282 2833. paChecksum Agility 284 285 The paChecksum defined in Section 3.2.1 of [RFC4556] provides a 286 cryptographic binding between the client's pre-authentication data 287 and the corresponding Kerberos request body. This also prevents the 288 KDC body from being tempered with. SHA-1 is the only allowed 289 checksum algorithm defined in [RFC4556]. This facility relies the 290 collision resistance properties of the SHA-1 checksum [RFC4634]. 291 292 When the reply key delivery mechanism is based on public key 293 encryption as described in Section 3.2.3. of [RFC4556], the 294 asChecksum in the KDC reply provides the binding between the pre- 295 authentication and the ticket request and response messages, and 296 integrity protection for the unauthenticated clear text in these 297 messages. However, if the reply key delivery mechanism is based on 298 the Diffie-Hellman key agreement as described in Section 3.2.3.1 of 299 [RFC4556], the security provided by using SHA-1 in the paChecksum is 300 weak. In this case, the new KDF selected by the KDC as described in 301 Section 6 provides the cryptographic binding and integrity 302 protection. 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 334Hornquist Astrand & Zhu Expires January 10, 2008 [Page 6] 335 336Internet-Draft PK-INIT algorithm agility July 2007 337 338 3394. CMS Digest Algorithm Agility 340 341 When the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned 342 as described In section 3.2.2 of [RFC4556], implementations 343 comforming to this specification can OPTIONALLY send back a list of 344 supported CMS types signifying the digest algorithms supported by the 345 KDC, in the decreasing preference order. This is accomplished by 346 including a TD_CMS_DATA_DIGEST_ALGORITHMS typed data element in the 347 error data. 348 349 350 351 TD-CMS-DIGEST-ALGORITHMS ::= INTEGER 111 352 353 354 The corresponding data for the TD_CMS_DATA_DIGEST_ALGORITHMS contains 355 the ASN.1 Distinguished Encoding Rules (DER) [X680] [X690] encoded 356 TD-CMS-DIGEST-ALGORITHMS-DATA structure defined as follows: 357 358 359 360 TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF 361 AlgorithmIdentifier 362 -- Contains the list of CMS algorithm [RFC3852] 363 -- identifiers that identify the digest algorithms 364 -- acceptable by the KDC for signing CMS data in 365 -- the order of decreasing preference. 366 367 368 The algorithm identifiers in the TD-CMS-DIGEST-ALGORITHMS identifiy 369 digest algorithms supported by the KDC. 370 371 This information sent by the KDC via TD_CMS_DATA_DIGEST_ALGORITHMS 372 can facilitate trouble-shooting when none of the digest algorithms 373 supported by the client is supported by the KDC. 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390Hornquist Astrand & Zhu Expires January 10, 2008 [Page 7] 391 392Internet-Draft PK-INIT algorithm agility July 2007 393 394 3955. X.509 Certificate Signer Algorithm Agility 396 397 When the client's X.509 certificate is rejected and the 398 KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned as 399 described in section 3.2.2 of [RFC4556], conforming implementations 400 can OPTIONALLY send a list of digest algorithms acceptable by the KDC 401 for use by the CA in signing the client's X.509 certificate, in the 402 decreasing preference order. This is accomplished by including a 403 TD_CERT_DIGEST_ALGORITHMS typed data element in the error data. The 404 corresponding data contains the ASN.1 DER encoding of the structure 405 TD-CERT-DIGEST-ALGORITHMS-DATA defined as follows: 406 407 408 TD-CERT-DIGEST-ALGORITHMS ::= INTEGER 112 409 410 TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE { 411 allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier, 412 -- Contains the list of CMS algorithm [RFC3852] 413 -- identifiers that identify the digest algorithms 414 -- that are used by the CA to sign the client's 415 -- X.509 certificate and acceptable by the KDC in 416 -- the process of validating the client's X.509 417 -- certificate, in the order of decreasing 418 -- preference. 419 rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL, 420 -- This identifies the digest algorithm that was 421 -- used to sign the client's X.509 certificate and 422 -- has been rejected by the KDC in the process of 423 -- validating the client's X.509 certificate 424 -- [RFC3280]. 425 ... 426 } 427 428 429 The KDC fills in allowedAlgorithm field with the list of algorithm 430 [RFC3852] identifiers that identify digest algorithms that are used 431 by the CA to sign the client's X.509 certificate and acceptable by 432 the KDC in the process of validating the client's X.509 certificate, 433 in the order of decreasing preference. The rejectedAlgorithm field 434 identifies the signing algorithm for use in signing the client's 435 X.509 certificate that has been rejected by the KDC in the process of 436 validating the client's certificate [RFC3280]. 437 438 439 440 441 442 443 444 445 446Hornquist Astrand & Zhu Expires January 10, 2008 [Page 8] 447 448Internet-Draft PK-INIT algorithm agility July 2007 449 450 4516. KDF agility 452 453 Based on [RFC3766] and [X9.42], Section 3.2.3.1 of [RFC4556] defines 454 a Key Derivation Function (KDF) that derives a Kerberos protocol key 455 based on the secret value generated by the Diffie-Hellman key 456 exchange. This KDF requires the use of SHA-1 [RFC4634]. 457 458 New KDFs defined in this document based on [SP80056A] can be used in 459 conjunction with any hash functions. A new KDF is identified by an 460 object identifier. The following KDF object identifiers are defined: 461 462 463 464 id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit 6 } 465 -- PKINIT KDFs 466 id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER ::= { id-pkinit-kdf 1 } 467 -- SP800 56A ASN.1 structured hash based KDF using SHA-1 468 id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER ::= { id-pkinit-kdf 2 } 469 -- SP800 56A ASN.1 structured hash based KDF using SHA-256 470 id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER ::= { id-pkinit-kdf 3 } 471 -- SP800 56A ASN.1 structured hash based KDF using SHA-512 472 473 474 Where id-pkinit is defined in [RFC4556]. The id-pkinit-kdf-ah-sha1 475 KDF is the ASN.1 structured hash based KDF (HKDF) [SP80056A] that 476 uses SHA-1 [RFC4634] as the hash function. Similarly id-pkinit-kdf- 477 ah-sha256 and id-pkinit-kdf-ah-sha512 are the ASN.1 structured HKDF 478 using SHA-256 [RFC4634] and SHA-512 [RFC4634] respectively. The 479 common input parameters for these KDFs are provided as follows: 480 481 o The secret value is the shared secret value generated by the 482 Diffie-Hellman exchange. The Diffie-Hellman shared value is first 483 padded with leading zeros such that the size of the secret value 484 in octets is the same as that of the modulus, then represented as 485 a string of octets in big-endian order. 486 487 o The key data length is K. K is the key-generation seed length in 488 bits [RFC3961] for the Authentication Service (AS) reply key. The 489 enctype of the AS reply key is selected according to [RFC4120]. 490 491 o The algorithm identifier input parameter is the identifier of the 492 respective KDF. For example, this is id-pkinit-kdf-ah-sha1 if the 493 KDF is the [SP80056A] ASN.1 structured HKDF using SHA-1 as the 494 hash. 495 496 o The initiator identifier is an OCTET STRING that contains the 497 ASN.1 DER encoding of the KRB5PrincipalName [RFC4556] that 498 identifies the client as specified in the AS-REQ [RFC4120] in the 499 500 501 502Hornquist Astrand & Zhu Expires January 10, 2008 [Page 9] 503 504Internet-Draft PK-INIT algorithm agility July 2007 505 506 507 request. 508 509 o The recipient identifier is an OCTET STRING that contains the 510 ASN.1 DER encoding of the KRB5PrincipalName [RFC4556] that 511 identifies the TGS as specified in the AS-REQ [RFC4120] in the 512 request. 513 514 o The supplemental private information is absent (not used). 515 516 o The supplemental public information is an OCTET STRING that 517 contains the ASN.1 DER encoding of the structure PkinitSuppPubInfo 518 as defined later in this section. 519 520 o The hash length is 128 for id-pkinit-kdf-ah-sha1, 256 for id- 521 pkinit-kdf-ah-sha256, and 512 for id-pkinit-kdf-ah-sha512. 522 523 o The maximum hash input length is 2^64 in bits. 524 525 The structure PkinitSuppPubInfo is defined as follows: 526 527 528 PkinitSuppPubInfo ::= SEQUENCE { 529 enctype [0] Int32, 530 -- The enctype of the AS reply key. 531 as-REQ [1] OCTET STRING, 532 -- This contains the AS-REQ in the request. 533 pk-as-rep [2] OCTET STRING, 534 -- Contains the DER encoding of the type 535 -- PA-PK-AS-REP [RFC4556] in the KDC reply. 536 ticket [3] Ticket, 537 -- This is the ticket in the KDC reply. 538 ... 539 } 540 541 542 The PkinitSuppPubInfo structure contains mutually-known public 543 information specific to the authentication exchange. The enctype 544 field is the enctype of the AS reply key as selected according to 545 [RFC4120]. The as-REQ field contains the DER encoding of the type 546 AS-REQ [RFC4120] in the request sent from the client to the KDC. 547 Note that the as-REQ field does not include the wrapping 4 octet 548 length field when TCP is used. The pk-as-rep field contains the DER 549 encoding of the type PA-PK-AS-REP [RFC4556] in the KDC reply. The 550 ticket field is filled with the ticket in the KDC reply. The 551 PkinitSuppPubInfo provides a cryptographic bindings between the pre- 552 authentication data and the corresponding ticket request and 553 response, thus addressing the concerns described in Section 3. 554 555 556 557 558Hornquist Astrand & Zhu Expires January 10, 2008 [Page 10] 559 560Internet-Draft PK-INIT algorithm agility July 2007 561 562 563 The above ASN.1 structured [SP80056A] HKDF produces a bit string of 564 length K in bits as the keying material, and then the AS reply key is 565 the output of random-to-key() [RFC3961] using that returned keying 566 material as the input. 567 568 The KDF is negotiated between the client and the KDC. The client 569 sends an unordered set of supported KDFs in the request, and the KDC 570 picks one from the set in the reply. 571 572 To acomplish this, the AuthPack structure in [RFC4556] is extended as 573 follows: 574 575 576 AuthPack ::= SEQUENCE { 577 pkAuthenticator [0] PKAuthenticator, 578 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 579 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 580 OPTIONAL, 581 clientDHNonce [3] DHNonce OPTIONAL, 582 ..., 583 supportedKDFs [4] SEQUENCE OF KDFAlgorithmId OPTIONAL, 584 -- Contains an unordered set of KDFs supported by the 585 -- client. 586 ... 587 } 588 589 KDFAlgorithmId ::= SEQUENCE { 590 kdf-id [0] OBJECT IDENTIFIER, 591 -- The object identifier of the KDF 592 ... 593 } 594 595 596 The new field supportedKDFs contains an unordered set of KDFs 597 supported by the client. 598 599 The KDFAlgorithmId structure contains an object identifier that 600 identifies a KDF. The algorithm of the KDF and its parameters are 601 defined by the corresponding specification of that KDF. 602 603 The DHRepInfo structure in [RFC4556] is extended as follows: 604 605 606 607 608 609 610 611 612 613 614Hornquist Astrand & Zhu Expires January 10, 2008 [Page 11] 615 616Internet-Draft PK-INIT algorithm agility July 2007 617 618 619 DHRepInfo ::= SEQUENCE { 620 dhSignedData [0] IMPLICIT OCTET STRING, 621 serverDHNonce [1] DHNonce OPTIONAL, 622 ..., 623 kdf [2] KDFAlgorithmId OPTIONAL, 624 -- The KDF picked by the KDC. 625 ... 626 } 627 628 629 The new field kdf in the extended DHRepInfo structure identifies the 630 KDF picked by the KDC. This kdf field MUST be filled by the 631 comforming KDC if the supportedKDFs field is present in the request, 632 and it MUST be one of the KDFs supported by the client as indicated 633 in the request. Which KDF is chosen is a matter of the local policy 634 on the KDC. 635 636 If the supportedKDFs field is not present in the request, the kdf 637 field in the reply MUST be absent. 638 639 If the client fills the supportedKDFs field in the request, but the 640 kdf field in the reply is not present, the client can deduce that the 641 KDC is not updated to conform with this specification. In that case, 642 it is a matter of local policy on the client whether to reject the 643 reply when the kdf field is absent in the reply. 644 645 Implementations comforming to this specification MUST support id- 646 pkinit-kdf-ah-sha256. 647 648 If no acceptable KDF is found, the error KDC_ERR_NO_ACCEPTABLE_KDF 649 (82). 650 651 PKINIT introduces the following new error code: 652 653 o KDC_ERR_NO_ACCEPTABLE_KDF 82 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670Hornquist Astrand & Zhu Expires January 10, 2008 [Page 12] 671 672Internet-Draft PK-INIT algorithm agility July 2007 673 674 6757. Security Considerations 676 677 This document describes negotiation of checksum types, key derivation 678 functions and other cryptographic functions. If negotiation is done 679 unauthenticated, care MUST be taken to accept only acceptable values. 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726Hornquist Astrand & Zhu Expires January 10, 2008 [Page 13] 727 728Internet-Draft PK-INIT algorithm agility July 2007 729 730 7318. Acknowledgements 732 733 Jeffery Hutzelman and Shawn Emery reviewed the document and provided 734 suggestions for improvements. 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782Hornquist Astrand & Zhu Expires January 10, 2008 [Page 14] 783 784Internet-Draft PK-INIT algorithm agility July 2007 785 786 7879. IANA Considerations 788 789 No IANA considerations. 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838Hornquist Astrand & Zhu Expires January 10, 2008 [Page 15] 839 840Internet-Draft PK-INIT algorithm agility July 2007 841 842 84310. References 844 84510.1. Normative References 846 847 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 848 Requirement Levels", BCP 14, RFC 2119, March 1997. 849 850 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 851 X.509 Public Key Infrastructure Certificate and 852 Certificate Revocation List (CRL) Profile", RFC 3280, 853 April 2002. 854 855 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 856 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 857 RFC 3766, April 2004. 858 859 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 860 RFC 3852, July 2004. 861 862 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 863 Kerberos 5", RFC 3961, February 2005. 864 865 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 866 Kerberos Network Authentication Service (V5)", RFC 4120, 867 July 2005. 868 869 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 870 Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. 871 872 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 873 (SHA and HMAC-SHA)", July 2006. 874 875 [SP80056A] 876 Barker, E., Don, D., and M. Smid, "Recommendation for 877 Pair-Wise Key Establishment Schemes Using Discrete 878 Logarithm Cryptography", March 2006. 879 880 [X680] ITU, "ITU-T Recommendation X.680 (2002) | ISO/IEC 8824- 881 1:2002, Information technology - Abstract Syntax Notation 882 One (ASN.1): Specification of basic notation". 883 884 [X690] ITU, "ITU-T Recommendation X.690 (2002) | ISO/IEC 8825- 885 1:2002, Information technology - ASN.1 encoding Rules: 886 Specification of Basic Encoding Rules (BER), Canonical 887 Encoding Rules (CER) and Distinguished Encoding Rules 888 (DER)". 889 890 891 892 893 894Hornquist Astrand & Zhu Expires January 10, 2008 [Page 16] 895 896Internet-Draft PK-INIT algorithm agility July 2007 897 898 89910.2. Informative References 900 901 [RFC1320] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320, 902 April 1992. 903 904 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 905 April 1992. 906 907 [WANG04] Wang, X., Lai, X., Fheg, D., Chen, H., and X. Yu, 908 "Cryptanalysis of Hash functions MD4 and RIPEMD", 909 August 2004. 910 911 [X9.42] ANSI, "Public Key Cryptography for the Financial Services 912 Industry: Agreement of Symmetric Keys Using Discrete 913 Logarithm Cryptography", 2003. 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950Hornquist Astrand & Zhu Expires January 10, 2008 [Page 17] 951 952Internet-Draft PK-INIT algorithm agility July 2007 953 954 955Appendix A. PKINIT ASN.1 Module 956 957 958 959 KerberosV5-PK-INIT-Agility-SPEC { 960 iso(1) identified-organization(3) dod(6) internet(1) 961 security(5) kerberosV5(2) modules(4) pkinit(5) agility (1) 962 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 963 964 IMPORTS 965 AlgorithmIdentifier, SubjectPublicKeyInfo 966 FROM PKIX1Explicit88 { iso (1) 967 identified-organization (3) dod (6) internet (1) 968 security (5) mechanisms (5) pkix (7) id-mod (0) 969 id-pkix1-explicit (18) } 970 -- As defined in RFC 3280. 971 972 Ticket, Int32, Realm, EncryptionKey, Checksum 973 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 974 dod(6) internet(1) security(5) kerberosV5(2) 975 modules(4) krb5spec2(2) } 976 -- as defined in RFC 4120. 977 978 PKAuthenticator, DHNonce 979 FROM KerberosV5-PK-INIT-SPEC { 980 iso(1) identified-organization(3) dod(6) internet(1) 981 security(5) kerberosV5(2) modules(4) pkinit(5) }; 982 -- as defined in RFC 4556. 983 984 TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF 985 AlgorithmIdentifier 986 -- Contains the list of CMS algorithm [RFC3852] 987 -- identifiers that identify the digest algorithms 988 -- acceptable by the KDC for signing CMS data in 989 -- the order of decreasing preference. 990 991 TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE { 992 allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier, 993 -- Contains the list of CMS algorithm [RFC3852] 994 -- identifiers that identify the digest algorithms 995 -- that are used by the CA to sign the client's 996 -- X.509 certificate and acceptable by the KDC in 997 -- the process of validating the client's X.509 998 -- certificate, in the order of decreasing 999 -- preference. 1000 rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL, 1001 -- This identifies the digest algorithm that was 1002 -- used to sign the client's X.509 certificate and 1003 1004 1005 1006Hornquist Astrand & Zhu Expires January 10, 2008 [Page 18] 1007 1008Internet-Draft PK-INIT algorithm agility July 2007 1009 1010 1011 -- has been rejected by the KDC in the process of 1012 -- validating the client's X.509 certificate 1013 -- [RFC3280]. 1014 ... 1015 } 1016 1017 PkinitSuppPubInfo ::= SEQUENCE { 1018 enctype [0] Int32, 1019 -- The enctype of the AS reply key. 1020 as-REQ [1] OCTET STRING, 1021 -- This contains the AS-REQ in the request. 1022 pk-as-rep [2] OCTET STRING, 1023 -- Contains the DER encoding of the type 1024 -- PA-PK-AS-REP [RFC4556] in the KDC reply. 1025 ticket [3] Ticket, 1026 -- This is the ticket in the KDC reply. 1027 ... 1028 } 1029 1030 AuthPack ::= SEQUENCE { 1031 pkAuthenticator [0] PKAuthenticator, 1032 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 1033 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 1034 OPTIONAL, 1035 clientDHNonce [3] DHNonce OPTIONAL, 1036 ..., 1037 supportedKDFs [4] SEQUENCE OF KDFAlgorithmId OPTIONAL, 1038 -- Contains an unordered set of KDFs supported by the 1039 -- client. 1040 ... 1041 } 1042 1043 KDFAlgorithmId ::= SEQUENCE { 1044 kdf-id [0] OBJECT IDENTIFIER, 1045 -- The object identifier of the KDF 1046 ... 1047 } 1048 1049 DHRepInfo ::= SEQUENCE { 1050 dhSignedData [0] IMPLICIT OCTET STRING, 1051 serverDHNonce [1] DHNonce OPTIONAL, 1052 ..., 1053 kdf [2] KDFAlgorithmId OPTIONAL, 1054 -- The KDF picked by the KDC. 1055 ... 1056 } 1057 END 1058 1059 1060 1061 1062Hornquist Astrand & Zhu Expires January 10, 2008 [Page 19] 1063 1064Internet-Draft PK-INIT algorithm agility July 2007 1065 1066 1067Authors' Addresses 1068 1069 Love Hornquist Astrand 1070 Stockholm University 1071 SE-106 91 Stockholm 1072 Sweden 1073 1074 Email: lha@it.su.se 1075 1076 1077 Larry Zhu 1078 Microsoft Corporation 1079 One Microsoft Way 1080 Redmond, WA 98052 1081 US 1082 1083 Email: lzhu@microsoft.com 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118Hornquist Astrand & Zhu Expires January 10, 2008 [Page 20] 1119 1120Internet-Draft PK-INIT algorithm agility July 2007 1121 1122 1123Full Copyright Statement 1124 1125 Copyright (C) The IETF Trust (2007). 1126 1127 This document is subject to the rights, licenses and restrictions 1128 contained in BCP 78, and except as set forth therein, the authors 1129 retain all their rights. 1130 1131 This document and the information contained herein are provided on an 1132 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1133 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1134 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1135 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1136 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1137 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1138 1139 1140Intellectual Property 1141 1142 The IETF takes no position regarding the validity or scope of any 1143 Intellectual Property Rights or other rights that might be claimed to 1144 pertain to the implementation or use of the technology described in 1145 this document or the extent to which any license under such rights 1146 might or might not be available; nor does it represent that it has 1147 made any independent effort to identify any such rights. Information 1148 on the procedures with respect to rights in RFC documents can be 1149 found in BCP 78 and BCP 79. 1150 1151 Copies of IPR disclosures made to the IETF Secretariat and any 1152 assurances of licenses to be made available, or the result of an 1153 attempt made to obtain a general license or permission for the use of 1154 such proprietary rights by implementers or users of this 1155 specification can be obtained from the IETF on-line IPR repository at 1156 http://www.ietf.org/ipr. 1157 1158 The IETF invites any interested party to bring to its attention any 1159 copyrights, patents or patent applications, or other proprietary 1160 rights that may cover technology that may be required to implement 1161 this standard. Please address the information to the IETF at 1162 ietf-ipr@ietf.org. 1163 1164 1165Acknowledgment 1166 1167 Funding for the RFC Editor function is provided by the IETF 1168 Administrative Support Activity (IASA). 1169 1170 1171 1172 1173 1174Hornquist Astrand & Zhu Expires January 10, 2008 [Page 21] 1175 1176