| blob | bd6dbfe32e9abd70134634d71a1d1cb37d478c1c |
3 Network Working Group L. Hornquist Astrand
4 Internet-Draft Stockholm University
5 Intended status: Standards Track L. Zhu
6 Expires: January 10, 2008 Microsoft Corporation
7 July 9, 2007
10 PK-INIT algorithm agility
11 draft-ietf-krb-wg-pkinit-alg-agility-03
13 Status of this Memo
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.
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.
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."
30 The list of current Internet-Drafts can be accessed at
31 http://www.ietf.org/ietf/1id-abstracts.txt.
33 The list of Internet-Draft Shadow Directories can be accessed at
34 http://www.ietf.org/shadow.html.
36 This Internet-Draft will expire on January 10, 2008.
38 Copyright Notice
40 Copyright (C) The IETF Trust (2007).
54 Hornquist Astrand & Zhu Expires January 10, 2008 [Page 1]
55 \f
56 Internet-Draft PK-INIT algorithm agility July 2007
59 Abstract
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.
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.
73 Table of Contents
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
110 Hornquist Astrand & Zhu Expires January 10, 2008 [Page 2]
111 \f
112 Internet-Draft PK-INIT algorithm agility July 2007
115 1. Introduction
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.
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.
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:
147 o The checksum algorithm in the authentication request is hardwired
148 to use SHA-1 [RFC4634].
150 o The acceptable digest algorithms for signing the authentication
151 data are not discoverable.
153 o The key derivation function in Section 3.2.3 of [RFC4556] is
154 hardwired to use SHA-1.
156 o The acceptable digest algorithms for signing the client X.509
157 certificates are not discoverable.
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.
166 Hornquist Astrand & Zhu Expires January 10, 2008 [Page 3]
167 \f
168 Internet-Draft PK-INIT algorithm agility July 2007
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.
222 Hornquist Astrand & Zhu Expires January 10, 2008 [Page 4]
223 \f
224 Internet-Draft PK-INIT algorithm agility July 2007
227 2. Requirements Notation
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].
278 Hornquist Astrand & Zhu Expires January 10, 2008 [Page 5]
279 \f
280 Internet-Draft PK-INIT algorithm agility July 2007
283 3. paChecksum Agility
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].
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.
334 Hornquist Astrand & Zhu Expires January 10, 2008 [Page 6]
335 \f
336 Internet-Draft PK-INIT algorithm agility July 2007
339 4. CMS Digest Algorithm Agility
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.
351 TD-CMS-DIGEST-ALGORITHMS ::= INTEGER 111
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:
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.
368 The algorithm identifiers in the TD-CMS-DIGEST-ALGORITHMS identifiy
369 digest algorithms supported by the KDC.
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.
390 Hornquist Astrand & Zhu Expires January 10, 2008 [Page 7]
391 \f
392 Internet-Draft PK-INIT algorithm agility July 2007
395 5. X.509 Certificate Signer Algorithm Agility
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:
408 TD-CERT-DIGEST-ALGORITHMS ::= INTEGER 112
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 }
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].
446 Hornquist Astrand & Zhu Expires January 10, 2008 [Page 8]
447 \f
448 Internet-Draft PK-INIT algorithm agility July 2007
451 6. KDF agility
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].
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:
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
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:
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.
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].
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.
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
502 Hornquist Astrand & Zhu Expires January 10, 2008 [Page 9]
503 \f
504 Internet-Draft PK-INIT algorithm agility July 2007
507 request.
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.
514 o The supplemental private information is absent (not used).
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.
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.
523 o The maximum hash input length is 2^64 in bits.
525 The structure PkinitSuppPubInfo is defined as follows:
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 }
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.
558 Hornquist Astrand & Zhu Expires January 10, 2008 [Page 10]
559 \f
560 Internet-Draft PK-INIT algorithm agility July 2007
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.
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.
572 To acomplish this, the AuthPack structure in [RFC4556] is extended as
573 follows:
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 }
589 KDFAlgorithmId ::= SEQUENCE {
590 kdf-id [0] OBJECT IDENTIFIER,
591 -- The object identifier of the KDF
592 ...
593 }
596 The new field supportedKDFs contains an unordered set of KDFs
597 supported by the client.
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.
603 The DHRepInfo structure in [RFC4556] is extended as follows:
614 Hornquist Astrand & Zhu Expires January 10, 2008 [Page 11]
615 \f
616 Internet-Draft PK-INIT algorithm agility July 2007
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 }
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.
636 If the supportedKDFs field is not present in the request, the kdf
637 field in the reply MUST be absent.
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.
645 Implementations comforming to this specification MUST support id-
646 pkinit-kdf-ah-sha256.
648 If no acceptable KDF is found, the error KDC_ERR_NO_ACCEPTABLE_KDF
649 (82).
651 PKINIT introduces the following new error code:
653 o KDC_ERR_NO_ACCEPTABLE_KDF 82
670 Hornquist Astrand & Zhu Expires January 10, 2008 [Page 12]
671 \f
672 Internet-Draft PK-INIT algorithm agility July 2007
675 7. Security Considerations
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.
726 Hornquist Astrand & Zhu Expires January 10, 2008 [Page 13]
727 \f
728 Internet-Draft PK-INIT algorithm agility July 2007
731 8. Acknowledgements
733 Jeffery Hutzelman and Shawn Emery reviewed the document and provided
734 suggestions for improvements.
782 Hornquist Astrand & Zhu Expires January 10, 2008 [Page 14]
783 \f
784 Internet-Draft PK-INIT algorithm agility July 2007
787 9. IANA Considerations
789 No IANA considerations.
838 Hornquist Astrand & Zhu Expires January 10, 2008 [Page 15]
839 \f
840 Internet-Draft PK-INIT algorithm agility July 2007
843 10. References
845 10.1. Normative References
847 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
848 Requirement Levels", BCP 14, RFC 2119, March 1997.
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.
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.
859 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
860 RFC 3852, July 2004.
862 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
863 Kerberos 5", RFC 3961, February 2005.
865 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
866 Kerberos Network Authentication Service (V5)", RFC 4120,
867 July 2005.
869 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial
870 Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
872 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
873 (SHA and HMAC-SHA)", July 2006.
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.
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".
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)".
894 Hornquist Astrand & Zhu Expires January 10, 2008 [Page 16]
895 \f
896 Internet-Draft PK-INIT algorithm agility July 2007
899 10.2. Informative References
901 [RFC1320] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320,
902 April 1992.
904 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
905 April 1992.
907 [WANG04] Wang, X., Lai, X., Fheg, D., Chen, H., and X. Yu,
908 "Cryptanalysis of Hash functions MD4 and RIPEMD",
909 August 2004.
911 [X9.42] ANSI, "Public Key Cryptography for the Financial Services
912 Industry: Agreement of Symmetric Keys Using Discrete
913 Logarithm Cryptography", 2003.
950 Hornquist Astrand & Zhu Expires January 10, 2008 [Page 17]
951 \f
952 Internet-Draft PK-INIT algorithm agility July 2007
955 Appendix A. PKINIT ASN.1 Module
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
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.
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.
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.
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.
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
1006 Hornquist Astrand & Zhu Expires January 10, 2008 [Page 18]
1007 \f
1008 Internet-Draft PK-INIT algorithm agility July 2007
1011 -- has been rejected by the KDC in the process of
1012 -- validating the client's X.509 certificate
1013 -- [RFC3280].
1014 ...
1015 }
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 }
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 }
1043 KDFAlgorithmId ::= SEQUENCE {
1044 kdf-id [0] OBJECT IDENTIFIER,
1045 -- The object identifier of the KDF
1046 ...
1047 }
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
1062 Hornquist Astrand & Zhu Expires January 10, 2008 [Page 19]
1063 \f
1064 Internet-Draft PK-INIT algorithm agility July 2007
1067 Authors' Addresses
1069 Love Hornquist Astrand
1070 Stockholm University
1071 SE-106 91 Stockholm
1072 Sweden
1074 Email: lha@it.su.se
1077 Larry Zhu
1078 Microsoft Corporation
1079 One Microsoft Way
1080 Redmond, WA 98052
1081 US
1083 Email: lzhu@microsoft.com
1118 Hornquist Astrand & Zhu Expires January 10, 2008 [Page 20]
1119 \f
1120 Internet-Draft PK-INIT algorithm agility July 2007
1123 Full Copyright Statement
1125 Copyright (C) The IETF Trust (2007).
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.
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.
1140 Intellectual Property
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.
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.
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.
1165 Acknowledgment
1167 Funding for the RFC Editor function is provided by the IETF
1168 Administrative Support Activity (IASA).
1174 Hornquist Astrand & Zhu Expires January 10, 2008 [Page 21]
1175 \f