4 NETWORK WORKING GROUP L. Zhu
5 Internet-Draft Microsoft Corporation
6 Expires: June 15, 2006 B. Tung
7 USC Information Sciences Institute
11 Public Key Cryptography for Initial Authentication in Kerberos
12 draft-ietf-cat-kerberos-pk-init-31
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.
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-
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."
31 The list of current Internet-Drafts can be accessed at
32 http://www.ietf.org/ietf/1id-abstracts.txt.
34 The list of Internet-Draft Shadow Directories can be accessed at
35 http://www.ietf.org/shadow.html.
37 This Internet-Draft will expire on June 15, 2006.
41 Copyright (C) The Internet Society (2005).
45 This document describes protocol extensions (hereafter called PKINIT)
46 to the Kerberos protocol specification. These extensions provide a
47 method for integrating public key cryptography into the initial
48 authentication exchange, by using asymmetric-key signature and/or
49 encryption algorithms in pre-authentication data fields.
55 Zhu & Tung Expires June 15, 2006 [Page 1]
57 Internet-Draft PKINIT December 2005
62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
63 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
64 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
65 3.1. Definitions, Requirements, and Constants . . . . . . . . . 5
66 3.1.1. Required Algorithms . . . . . . . . . . . . . . . . . 5
67 3.1.2. Defined Message and Encryption Types . . . . . . . . . 5
68 3.1.3. Algorithm Identifiers . . . . . . . . . . . . . . . . 6
69 3.2. PKINIT Pre-authentication Syntax and Use . . . . . . . . . 7
70 3.2.1. Generation of Client Request . . . . . . . . . . . . . 7
71 3.2.2. Receipt of Client Request . . . . . . . . . . . . . . 12
72 3.2.3. Generation of KDC Reply . . . . . . . . . . . . . . . 16
73 3.2.4. Receipt of KDC Reply . . . . . . . . . . . . . . . . . 23
74 3.3. Interoperability Requirements . . . . . . . . . . . . . . 24
75 3.4. KDC Indication of PKINIT Support . . . . . . . . . . . . . 25
76 4. Security Considerations . . . . . . . . . . . . . . . . . . . 25
77 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
80 7.1. Normative References . . . . . . . . . . . . . . . . . . . 28
81 7.2. Informative References . . . . . . . . . . . . . . . . . . 30
82 Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 30
83 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 35
84 Appendix C. Miscellaneous Information about Microsoft Windows
85 PKINIT Implementations . . . . . . . . . . . . . . . 37
86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
87 Intellectual Property and Copyright Statements . . . . . . . . . . 40
111 Zhu & Tung Expires June 15, 2006 [Page 2]
113 Internet-Draft PKINIT December 2005
118 A client typically authenticates itself to a service in Kerberos
119 using three distinct though related exchanges. First, the client
120 requests a ticket-granting ticket (TGT) from the Kerberos
121 authentication server (AS). Then, it uses the TGT to request a
122 service ticket from the Kerberos ticket-granting server (TGS).
123 Usually, the AS and TGS are integrated in a single device known as a
124 Kerberos Key Distribution Center, or KDC. Finally, the client uses
125 the service ticket to authenticate itself to the service.
127 The advantage afforded by the TGT is that the client exposes his
128 long-term secrets only once. The TGT and its associated session key
129 can then be used for any subsequent service ticket requests. One
130 result of this is that all further authentication is independent of
131 the method by which the initial authentication was performed.
132 Consequently, initial authentication provides a convenient place to
133 integrate public-key cryptography into Kerberos authentication.
135 As defined in [RFC4120], Kerberos authentication exchanges use
136 symmetric-key cryptography, in part for performance. One
137 disadvantage of using symmetric-key cryptography is that the keys
138 must be shared, so that before a client can authenticate itself, he
139 must already be registered with the KDC.
141 Conversely, an established Public Key Infrastructure (PKI) already
142 provides key management and key distribution mechanisms that are
143 sufficient to establish authentication and secure communication.
144 Adding public-key cryptography to Kerberos allows Kerberized
145 applications to leverage these existing services. In addition, human
146 users can avoid the inconvenience of managing strong passwords, by
147 using randomly generated strong public and private key pairs.
149 As noted above, a convenient and efficient place to introduce public-
150 key cryptography into Kerberos is in the initial authentication
151 exchange. This document describes the methods and data formats for
152 integrating public-key cryptography into Kerberos initial
156 2. Conventions Used in This Document
158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
160 document are to be interpreted as described in [RFC2119].
162 Both the AS and the TGS are referred to as the KDC.
167 Zhu & Tung Expires June 15, 2006 [Page 3]
169 Internet-Draft PKINIT December 2005
172 In this protocol, both the client and the KDC have a public-private
173 key pair in order to prove their identities to each other over the
174 open network. The client's key pair is used to authenticate the
175 client to the KDC, and the KDC's key pair is used to authenticate the
176 KDC to the client. The term "signature key" is used to refer to the
177 private key of the key pair being used.
179 In this document, the encryption key used to encrypt the enc-part
180 field of the KDC-REP in the AS-REP [RFC4120] is referred to as the AS
183 In this document, an empty sequence in an optional field can be
184 either included or omitted: both encodings are permitted and
185 considered equivalent.
187 In this document, the term "Modular Exponential Diffie-Hellman" is
188 used to refer to the Diffie-Hellman key exchange as described in
189 [RFC2631], in order to differentiate it from other equivalent
190 representations of the same key agreement algorithm.
195 This section describes extensions to [RFC4120] for supporting the use
196 of public-key cryptography in the initial request for a ticket.
198 Briefly, this document defines the following extensions to [RFC4120]:
200 1. The client indicates the use of public-key authentication by
201 including a special preauthenticator in the initial request. This
202 preauthenticator contains the client's public-key data and a
205 2. The KDC tests the client's request against its authentication
206 policy and trusted Certification Authorities (CAs).
208 3. If the request passes the verification tests, the KDC replies as
209 usual, but the reply is encrypted using either:
211 a. a key generated through a Diffie-Hellman (DH) key exchange
212 [RFC2631] [IEEE1363] with the client, signed using the KDC's
215 b. a symmetric encryption key, signed using the KDC's signature
216 key and encrypted using the client's public key.
223 Zhu & Tung Expires June 15, 2006 [Page 4]
225 Internet-Draft PKINIT December 2005
228 Any keying material required by the client to obtain the
229 encryption key for decrypting the KDC reply is returned in a pre-
230 authentication field accompanying the usual reply.
232 4. The client validates the KDC's signature, obtains the encryption
233 key, decrypts the reply, and then proceeds as usual.
235 Section 3.1 of this document enumerates the required algorithms and
236 necessary extension message types. Section 3.2 describes the
237 extension messages in greater detail.
239 3.1. Definitions, Requirements, and Constants
241 3.1.1. Required Algorithms
243 All PKINIT implementations MUST support the following algorithms:
245 o AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-
248 o Signature algorithm: sha-1WithRSAEncryption [RFC3279].
250 o AS reply key delivery method: Diffie-Hellman key exchange
253 In addition, implementations of this specification MUST be capable of
254 processing the Extended Key Usage (EKU) extension and the id-pkinit-
255 san (as defined in Section 3.2.2) otherName of the Subject
256 Alternative Name (SAN) extension in X.509 certificates [RFC3280], if
259 3.1.2. Defined Message and Encryption Types
261 PKINIT makes use of the following new pre-authentication types:
266 PKINIT also makes use of the following new authorization data type:
268 AD_INITIAL_VERIFIED_CAS 9
270 PKINIT introduces the following new error codes:
279 Zhu & Tung Expires June 15, 2006 [Page 5]
281 Internet-Draft PKINIT December 2005
284 KDC_ERR_CLIENT_NOT_TRUSTED 62
285 KDC_ERR_INVALID_SIG 64
286 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65
287 KDC_ERR_CANT_VERIFY_CERTIFICATE 70
288 KDC_ERR_INVALID_CERTIFICATE 71
289 KDC_ERR_REVOKED_CERTIFICATE 72
290 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
291 KDC_ERR_CLIENT_NAME_MISMATCH 75
292 KDC_ERR_INCONSISTENT_KEY_PURPOSE 76
293 KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED 77
294 KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED 78
295 KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED 79
297 PKINIT uses the following typed data types for errors:
299 TD_TRUSTED_CERTIFIERS 104
300 TD_INVALID_CERTIFICATES 105
303 The ASN.1 module for all structures defined in this document (plus
304 IMPORT statements for all imported structures) is given in
307 All structures defined in or imported into this document MUST be
308 encoded using Distinguished Encoding Rules (DER) [X680] [X690]
309 (unless otherwise noted). All data structures carried in OCTET
310 STRINGs must be encoded according to the rules specified in
311 corresponding specifications.
313 Interoperability note: Some implementations may not be able to decode
314 wrapped CMS objects encoded with BER; specifically, they may not be
315 able to decode indefinite length encodings. To maximize
316 interoperability, implementers SHOULD encode CMS objects used in
319 3.1.3. Algorithm Identifiers
321 PKINIT does not define, but does make use of, the following algorithm
324 PKINIT uses the following algorithm identifier(s) for Modular
325 Exponential Diffie-Hellman key agreement [RFC2631] [RFC3279]:
327 dhpublicnumber (as described in [RFC3279])
329 PKINIT uses the following signature algorithm identifiers as defined
335 Zhu & Tung Expires June 15, 2006 [Page 6]
337 Internet-Draft PKINIT December 2005
340 sha-1WithRSAEncryption (RSA with SHA1)
341 md5WithRSAEncryption (RSA with MD5)
342 id-dsa-with-sha1 (DSA with SHA1)
344 PKINIT uses the following encryption algorithm identifiers as defined
345 in [RFC3447] for encrypting the temporary key with a public key:
350 PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565]
351 for encrypting the AS reply key with the temporary key:
353 des-ede3-cbc (three-key 3DES, CBC mode, as defined in [RFC3370])
354 rc2-cbc (RC2, CBC mode, as defined in [RFC3370])
355 id-aes256-CBC (AES-256, CBC mode, as defined in [RFC3565])
357 PKINIT defines the following encryption types, for use in the etype
358 field of the AS-REQ [RFC4120] message to indicate acceptance of the
359 corresponding algorithms that can used by Cryptographic Message
360 Syntax (CMS) [RFC3852] messages in the reply:
362 id-dsa-with-sha1-CmsOID 9
363 -- Indicates that the client supports id-dsa-with-sha1.
364 md5WithRSAEncryption-CmsOID 10
365 -- Indicates that the client supports md5WithRSAEncryption.
366 sha-1WithRSAEncryption-CmsOID 11
367 -- Indicates that the client supports sha-1WithRSAEncryption.
369 -- Indicates that the client supports rc2-cbc.
370 rsaEncryption-EnvOID 13
371 -- Indicates that the client supports rsaEncryption.
372 id-RSAES-OAEP-EnvOID 14
373 -- Indicates that the client supports id-RSAES-OAEP.
374 des-ede3-cbc-EnvOID 15
375 -- Indicates that the client supports des-ede3-cbc.
377 3.2. PKINIT Pre-authentication Syntax and Use
379 This section defines the syntax and use of the various pre-
380 authentication fields employed by PKINIT.
382 3.2.1. Generation of Client Request
384 The initial authentication request (AS-REQ) is sent as per [RFC4120];
385 in addition, a pre-authentication data element, whose padata-type is
386 PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
387 type PA-PK-AS-REQ, is included.
391 Zhu & Tung Expires June 15, 2006 [Page 7]
393 Internet-Draft PKINIT December 2005
396 PA-PK-AS-REQ ::= SEQUENCE {
397 signedAuthPack [0] IMPLICIT OCTET STRING,
398 -- Contains a CMS type ContentInfo encoded
399 -- according to [RFC3852].
400 -- The contentType field of the type ContentInfo
401 -- is id-signedData (1.2.840.113549.1.7.2),
402 -- and the content field is a SignedData.
403 -- The eContentType field for the type SignedData is
404 -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
405 -- eContent field contains the DER encoding of the
407 -- AuthPack is defined below.
408 trustedCertifiers [1] SEQUENCE OF
409 ExternalPrincipalIdentifier OPTIONAL,
410 -- Contains a list of CAs, trusted by the client,
411 -- that can be used to certify the KDC.
412 -- Each ExternalPrincipalIdentifier identifies a CA
413 -- or a CA certificate (thereby its public key).
414 -- The information contained in the
415 -- trustedCertifiers SHOULD be used by the KDC as
416 -- hints to guide its selection of an appropriate
417 -- certificate chain to return to the client.
418 kdcPkId [2] IMPLICIT OCTET STRING
420 -- Contains a CMS type SignerIdentifier encoded
421 -- according to [RFC3852].
422 -- Identifies, if present, a particular KDC
423 -- public key that the client already has.
427 DHNonce ::= OCTET STRING
429 ExternalPrincipalIdentifier ::= SEQUENCE {
430 subjectName [0] IMPLICIT OCTET STRING OPTIONAL,
431 -- Contains a PKIX type Name encoded according to
433 -- Identifies the certificate subject by the
434 -- distinguished subject name.
435 -- REQUIRED when there is a distinguished subject
436 -- name present in the certificate.
437 issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL,
438 -- Contains a CMS type IssuerAndSerialNumber encoded
439 -- according to [RFC3852].
440 -- Identifies a certificate of the subject.
441 -- REQUIRED for TD-INVALID-CERTIFICATES and
442 -- TD-TRUSTED-CERTIFIERS.
443 subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL,
447 Zhu & Tung Expires June 15, 2006 [Page 8]
449 Internet-Draft PKINIT December 2005
452 -- Identifies the subject's public key by a key
453 -- identifier. When an X.509 certificate is
454 -- referenced, this key identifier matches the X.509
455 -- subjectKeyIdentifier extension value. When other
456 -- certificate formats are referenced, the documents
457 -- that specify the certificate format and their use
458 -- with the CMS must include details on matching the
459 -- key identifier to the appropriate certificate
461 -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
465 AuthPack ::= SEQUENCE {
466 pkAuthenticator [0] PKAuthenticator,
467 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
468 -- Type SubjectPublicKeyInfo is defined in
470 -- Specifies Diffie-Hellman domain parameters
471 -- and the client's public key value [IEEE1363].
472 -- The DH public key value is encoded as a BIT
473 -- STRING according to [RFC3279].
474 -- This field is present only if the client wishes
475 -- to use the Diffie-Hellman key agreement method.
476 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
478 -- Type AlgorithmIdentifier is defined in
480 -- List of CMS encryption types supported by the
481 -- client in order of (decreasing) preference.
482 clientDHNonce [3] DHNonce OPTIONAL,
483 -- Present only if the client indicates that it
484 -- wishes to reuse DH keys or to allow the KDC to
485 -- do so (see Section 3.2.3.1).
489 PKAuthenticator ::= SEQUENCE {
490 cusec [0] INTEGER (0..999999),
491 ctime [1] KerberosTime,
492 -- cusec and ctime are used as in [RFC4120], for
493 -- replay prevention.
494 nonce [2] INTEGER (0..4294967295),
495 -- Chosen randomly; This nonce does not need to
496 -- match with the nonce in the KDC-REQ-BODY.
497 paChecksum [3] OCTET STRING,
498 -- Contains the SHA1 checksum, performed over
503 Zhu & Tung Expires June 15, 2006 [Page 9]
505 Internet-Draft PKINIT December 2005
511 The ContentInfo [RFC3852] structure contained in the signedAuthPack
512 field of the type PA-PK-AS-REQ is encoded according to [RFC3852] and
513 is filled out as follows:
515 1. The contentType field of the type ContentInfo is id-signedData
516 (as defined in [RFC3852]), and the content field is a SignedData
517 (as defined in [RFC3852]).
519 2. The eContentType field for the type SignedData is id-pkinit-
520 authData: { iso(1) org(3) dod(6) internet(1) security(5)
521 kerberosv5(2) pkinit(3) authData(1) }. Notes to CMS
522 implementers: the signed attribute content-type MUST be present
523 in this SignedData instance and its value is id-pkinit-authData
524 according to [RFC3852].
526 3. The eContent field for the type SignedData contains the DER
527 encoding of the type AuthPack.
529 4. The signerInfos field of the type SignedData contains a single
530 signerInfo, which contains the signature over the type AuthPack.
532 5. The AuthPack structure contains a PKAuthenticator, the client
533 public key information, the CMS encryption types supported by the
534 client and a DHNonce. The pkAuthenticator field certifies to the
535 KDC that the client has recent knowledge of the signing key that
536 authenticates the client. The clientPublicValue field specifies
537 Diffie-Hellman domain parameters and the client's public key
538 value. The DH public key value is encoded as a BIT STRING
539 according to [RFC3279]. The clientPublicValue field is present
540 only if the client wishes to use the Diffie-Hellman key agreement
541 method. The supportedCMSTypes field specifies the list of CMS
542 encryption types supported by the client in order of (decreasing)
543 preference. The clientDHNonce field is described later in this
546 6. The ctime field in the PKAuthenticator structure contains the
547 current time on the client's host, and the cusec field contains
548 the microsecond part of the client's timestamp. The ctime and
549 cusec fields are used together to specify a reasonably accurate
550 timestamp [RFC4120]. The nonce field is chosen randomly. The
551 paChecksum field contains a SHA1 checksum that is performed over
552 the KDC-REQ-BODY [RFC4120].
559 Zhu & Tung Expires June 15, 2006 [Page 10]
561 Internet-Draft PKINIT December 2005
564 7. The certificates field of the type SignedData contains
565 certificates intended to facilitate certification path
566 construction, so that the KDC can verify the signature over the
567 type AuthPack. For path validation, these certificates SHOULD be
568 sufficient to construct at least one certification path from the
569 client certificate to one trust anchor acceptable by the KDC
570 [RFC4158]. The client MUST be capable of including such a set of
571 certificates if configured to do so. The certificates field MUST
572 NOT contain "root" CA certificates.
574 8. The client's Diffie-Hellman public value (clientPublicValue) is
575 included if and only if the client wishes to use the Diffie-
576 Hellman key agreement method. The Diffie-Hellman domain
577 parameters [IEEE1363] for the client's public key are specified
578 in the algorithm field of the type SubjectPublicKeyInfo [RFC3279]
579 and the client's Diffie-Hellman public key value is mapped to a
580 subjectPublicKey (a BIT STRING) according to [RFC3279]. When
581 using the Diffie-Hellman key agreement method, implementations
582 MUST support Oakley 1024-bit Modular Exponential (MODP) well-
583 known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group
584 14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known
587 The Diffie-Hellman field size should be chosen so as to provide
588 sufficient cryptographic security [RFC3766].
590 When MODP Diffie-Hellman is used, the exponents should have at
591 least twice as many bits as the symmetric keys that will be
592 derived from them [ODL99].
594 9. The client may wish to reuse DH keys or to allow the KDC to do so
595 (see Section 3.2.3.1). If so, then the client includes the
596 clientDHNonce field. This nonce string MUST be as long as the
597 longest key length of the symmetric key types that the client
598 supports. This nonce MUST be chosen randomly.
600 The ExternalPrincipalIdentifier structure is used in this document to
601 identify the subject's public key thereby the subject principal.
602 This structure is filled out as follows:
604 1. The subjectName field contains a PKIX type Name encoded according
605 to [RFC3280]. This field identifies the certificate subject by
606 the distinguished subject name. This field is REQUIRED when
607 there is a distinguished subject name present in the certificate
615 Zhu & Tung Expires June 15, 2006 [Page 11]
617 Internet-Draft PKINIT December 2005
620 2. The issuerAndSerialNumber field contains a CMS type
621 IssuerAndSerialNumber encoded according to [RFC3852]. This field
622 identifies a certificate of the subject. This field is REQUIRED
623 for TD-INVALID-CERTIFICATES and TD-TRUSTED-CERTIFIERS (both
624 structures are defined in Section 3.2.2).
626 3. The subjectKeyIdentifier [RFC3852] field identifies the subject's
627 public key by a key identifier. When an X.509 certificate is
628 referenced, this key identifier matches the X.509
629 subjectKeyIdentifier extension value. When other certificate
630 formats are referenced, the documents that specify the
631 certificate format and their use with the CMS must include
632 details on matching the key identifier to the appropriate
633 certificate field. This field is RECOMMENDED for TD-TRUSTED-
634 CERTIFIERS (as defined in Section 3.2.2).
636 The trustedCertifiers field of the type PA-PK-AS-REQ contains a list
637 of CAs, trusted by the client, that can be used to certify the KDC.
638 Each ExternalPrincipalIdentifier identifies a CA or a CA certificate
639 (thereby its public key).
641 The kdcPkId field of the type PA-PK-AS-REQ contains a CMS type
642 SignerIdentifier encoded according to [RFC3852]. This field
643 identifies, if present, a particular KDC public key that the client
646 3.2.2. Receipt of Client Request
648 Upon receiving the client's request, the KDC validates it. This
649 section describes the steps that the KDC MUST (unless otherwise
650 noted) take in validating the request.
652 The KDC verifies the client's signature in the signedAuthPack field
653 according to [RFC3852].
655 If, while validating the client's X.509 certificate [RFC3280], the
656 KDC cannot build a certification path to validate the client's
657 certificate, it sends back a KRB-ERROR [RFC4120] message with the
658 code KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for
659 this error message is a TYPED-DATA (as defined in [RFC4120]) that
660 contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and
661 whose data-value contains the DER encoding of the type TD-TRUSTED-
664 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
665 ExternalPrincipalIdentifier
666 -- Identifies a list of CAs trusted by the KDC.
667 -- Each ExternalPrincipalIdentifier identifies a CA
671 Zhu & Tung Expires June 15, 2006 [Page 12]
673 Internet-Draft PKINIT December 2005
676 -- or a CA certificate (thereby its public key).
678 Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
679 TD-TRUSTED-CERTIFIERS structure identifies a CA or a CA certificate
680 (thereby its public key) trusted by the KDC.
682 Upon receiving this error message, the client SHOULD retry only if it
683 has a different set of certificates (from those of the previous
684 requests) that form a certification path (or a partial path) from one
685 of the trust anchors acceptable by the KDC to its own certificate.
687 If, while processing the certification path, the KDC determines that
688 the signature on one of the certificates in the signedAuthPack field
689 is invalid, it returns a KRB-ERROR [RFC4120] message with the code
690 KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data for this error
691 message is a TYPED-DATA that contains an element whose data-type is
692 TD_INVALID_CERTIFICATES, and whose data-value contains the DER
693 encoding of the type TD-INVALID-CERTIFICATES:
695 TD-INVALID-CERTIFICATES ::= SEQUENCE OF
696 ExternalPrincipalIdentifier
697 -- Each ExternalPrincipalIdentifier identifies a
698 -- certificate (sent by the client) with an invalid
701 Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
702 TD-INVALID-CERTIFICATES structure identifies a certificate (that was
703 sent by the client) with an invalid signature.
705 If more than one X.509 certificate signature is invalid, the KDC MAY
706 include one IssuerAndSerialNumber per invalid signature within the
707 TD-INVALID-CERTIFICATES.
709 The client's X.509 certificate is validated according to [RFC3280].
711 Based on local policy, the KDC may also check whether any X.509
712 certificates in the certification path validating the client's
713 certificate have been revoked. If any of them have been revoked, the
714 KDC MUST return an error message with the code
715 KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
716 revocation status but is unable to do so, it SHOULD return an error
717 message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN. The
718 certificate or certificates affected are identified exactly as for
719 the error code KDC_ERR_INVALID_CERTIFICATE (see above).
721 Note that the TD_INVALID_CERTIFICATES error data is only used to
722 identify invalid certificates sent by the client in the request.
727 Zhu & Tung Expires June 15, 2006 [Page 13]
729 Internet-Draft PKINIT December 2005
732 The client's public key is then used to verify the signature. If the
733 signature fails to verify, the KDC MUST return an error message with
734 the code KDC_ERR_INVALID_SIG. There is no accompanying e-data for
737 In addition to validating the client's signature, the KDC MUST also
738 check that the client's public key used to verify the client's
739 signature is bound to the client's principal name as specified in the
742 1. If the KDC has its own binding between either the client's
743 signature-verification public key or the client's certificate and
744 the client's Kerberos principal name, it uses that binding.
746 2. Otherwise, if the client's X.509 certificate contains a Subject
747 Alternative Name (SAN) extension carrying a KRB5PrincipalName
748 (defined below) in the otherName field of the type GeneralName
749 [RFC3280], it binds the client's X.509 certificate to that name.
751 The type of the otherName field is AnotherName. The type-id field
752 of the type AnotherName is id-pkinit-san:
754 id-pkinit-san OBJECT IDENTIFIER ::=
755 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
758 And the value field of the type AnotherName is a
761 KRB5PrincipalName ::= SEQUENCE {
763 principalName [1] PrincipalName
766 If the KDC does not have its own binding and there is no
767 KRB5PrincipalName name present in the client's X.509 certificate, or
768 if the Kerberos name in the request does not match the
769 KRB5PrincipalName in the client's X.509 certificate (including the
770 realm name), the KDC MUST return an error message with the code
771 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for
774 Even if the certification path is validated and the certificate is
775 mapped to the client's principal name, the KDC may decide not to
776 accept the client's certificate, depending on local policy.
778 The KDC MAY require the presence of an Extended Key Usage (EKU)
779 KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field
783 Zhu & Tung Expires June 15, 2006 [Page 14]
785 Internet-Draft PKINIT December 2005
788 of the client's X.509 certificate:
790 id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
791 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
792 pkinit(3) keyPurposeClientAuth(4) }
793 -- PKINIT client authentication.
794 -- Key usage bits that MUST be consistent:
797 The digitalSignature key usage bit [RFC3280] MUST be asserted when
798 the intended purpose of the client's X.509 certificate is restricted
799 with the id-pkinit-KPClientAuth EKU.
801 If this EKU KeyPurposeId is required but it is not present or if the
802 client certificate is restricted not to be used for PKINIT client
803 authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
804 an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE. There
805 is no accompanying e-data for this error message. KDCs implementing
806 this requirement SHOULD also accept the EKU KeyPurposeId id-ms-kp-sc-
807 logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there
808 are a large number of X.509 client certificates deployed for use with
809 PKINIT which have this EKU.
811 As a matter of local policy, the KDC MAY decide to reject requests on
812 the basis of the absence or presence of other specific EKU OID's.
814 If the digest algorithm used in generating the CA signature for the
815 public key in any certificate of the request is not acceptable by the
816 KDC, the KDC MUST return a KRB-ERROR [RFC4120] message with the code
817 KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED. The accompanying e-data MUST be
818 encoded in TYPED-DATA although none is defined at this point.
820 If the client's public key is not accepted with reasons other than
821 what were specified above, the KDC returns a KRB-ERROR [RFC4120]
822 message with the code KDC_ERR_CLIENT_NOT_TRUSTED. There is no
823 accompanying e-data currently defined for this error message.
825 The KDC MUST check the timestamp to ensure that the request is not a
826 replay, and that the time skew falls within acceptable limits. The
827 recommendations for clock skew times in [RFC4120] apply here. If the
828 check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
829 KRB_AP_ERR_SKEW, respectively.
831 If the clientPublicValue is filled in, indicating that the client
832 wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
833 check to see if the key parameters satisfy its policy. If they do
834 not, it MUST return an error message with the code
835 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The accompanying e-data is a
839 Zhu & Tung Expires June 15, 2006 [Page 15]
841 Internet-Draft PKINIT December 2005
844 TYPED-DATA that contains an element whose data-type is
845 TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
846 the type TD-DH-PARAMETERS:
848 TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
849 -- Each AlgorithmIdentifier specifies a set of
850 -- Diffie-Hellman domain parameters [IEEE1363].
851 -- This list is in decreasing preference order.
853 TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
854 that the KDC supports in decreasing preference order, from which the
855 client SHOULD pick one to retry the request.
857 The AlgorithmIdentifier structure is defined in [RFC3280] and is
858 filled in according to [RFC3279]. More specifically Section 2.3.3 of
859 [RFC3279] describes how to fill in the AlgorithmIdentifier structure
860 in the case where MODP Diffie-Hellman key exchange is used.
862 If the client included a kdcPkId field in the PA-PK-AS-REQ and the
863 KDC does not possess the corresponding key, the KDC MUST ignore the
864 kdcPkId field as if the client did not include one.
866 If the digest algorithm used by the id-pkinit-authData is not
867 acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120]
868 message with the code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED.
869 The accompanying e-data MUST be encoded in TYPED-DATA although none
870 is defined at this point.
872 3.2.3. Generation of KDC Reply
874 Assuming that the client's request has been properly validated, the
875 KDC proceeds as per [RFC4120], except as follows.
877 The KDC MUST set the initial flag and include an authorization data
878 element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued
879 ticket. The ad-data [RFC4120] field contains the DER encoding of the
880 type AD-INITIAL-VERIFIED-CAS:
882 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
883 ExternalPrincipalIdentifier
884 -- Identifies the certification path based on which
885 -- the client certificate was validated.
886 -- Each ExternalPrincipalIdentifier identifies a CA
887 -- or a CA certificate (thereby its public key).
889 The AD-INITIAL-VERIFIED-CAS structure identifies the certification
890 path based on which the client certificate was validated. Each
891 ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the AD-
895 Zhu & Tung Expires June 15, 2006 [Page 16]
897 Internet-Draft PKINIT December 2005
900 INITIAL-VERIFIED-CAS structure identifies a CA or a CA certificate
901 (thereby its public key).
903 The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
904 containers if the list of CAs satisfies the AS' realm's local policy
905 (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
906 [RFC4120]). Furthermore, any TGS MUST copy such authorization data
907 from tickets used within a PA-TGS-REQ of the TGS-REQ into the
908 resulting ticket. If the list of CAs satisfies the local KDC's
909 realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT
910 container, otherwise it MAY unwrap the authorization data out of the
911 AD-IF-RELEVANT container.
913 Application servers that understand this authorization data type
914 SHOULD apply local policy to determine whether a given ticket bearing
915 such a type *not* contained within an AD-IF-RELEVANT container is
916 acceptable. (This corresponds to the AP server checking the
917 transited field when the TRANSITED-POLICY-CHECKED flag has not been
918 set [RFC4120].) If such a data type is contained within an AD-IF-
919 RELEVANT container, AP servers MAY apply local policy to determine
920 whether the authorization data is acceptable.
922 A pre-authentication data element, whose padata-type is PA_PK_AS_REP
923 and whose padata-value contains the DER encoding of the type PA-PK-
924 AS-REP (defined below), is included in the AS-REP [RFC4120].
926 PA-PK-AS-REP ::= CHOICE {
927 dhInfo [0] DHRepInfo,
928 -- Selected when Diffie-Hellman key exchange is
930 encKeyPack [1] IMPLICIT OCTET STRING,
931 -- Selected when public key encryption is used.
932 -- Contains a CMS type ContentInfo encoded
933 -- according to [RFC3852].
934 -- The contentType field of the type ContentInfo is
935 -- id-envelopedData (1.2.840.113549.1.7.3).
936 -- The content field is an EnvelopedData.
937 -- The contentType field for the type EnvelopedData
938 -- is id-signedData (1.2.840.113549.1.7.2).
939 -- The eContentType field for the inner type
940 -- SignedData (when unencrypted) is
941 -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
942 -- eContent field contains the DER encoding of the
943 -- type ReplyKeyPack.
944 -- ReplyKeyPack is defined in Section 3.2.3.2.
951 Zhu & Tung Expires June 15, 2006 [Page 17]
953 Internet-Draft PKINIT December 2005
956 DHRepInfo ::= SEQUENCE {
957 dhSignedData [0] IMPLICIT OCTET STRING,
958 -- Contains a CMS type ContentInfo encoded according
960 -- The contentType field of the type ContentInfo is
961 -- id-signedData (1.2.840.113549.1.7.2), and the
962 -- content field is a SignedData.
963 -- The eContentType field for the type SignedData is
964 -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
965 -- eContent field contains the DER encoding of the
966 -- type KDCDHKeyInfo.
967 -- KDCDHKeyInfo is defined below.
968 serverDHNonce [1] DHNonce OPTIONAL,
969 -- Present if and only if dhKeyExpiration is
970 -- present in the KDCDHKeyInfo.
974 KDCDHKeyInfo ::= SEQUENCE {
975 subjectPublicKey [0] BIT STRING,
976 -- The KDC's DH public key.
977 -- The DH public key value is encoded as a BIT
978 -- STRING according to [RFC3279].
979 nonce [1] INTEGER (0..4294967295),
980 -- Contains the nonce in the pkAuthenticator field
981 -- in the request if the DH keys are NOT reused,
983 dhKeyExpiration [2] KerberosTime OPTIONAL,
984 -- Expiration time for KDC's key pair,
985 -- present if and only if the DH keys are reused.
986 -- If present, the KDC's DH public key MUST not be
987 -- used past the point of this expiration time.
988 -- If this field is omitted then the serverDHNonce
989 -- field MUST also be omitted.
993 The content of the AS-REP is otherwise unchanged from [RFC4120]. The
994 KDC encrypts the reply as usual, but not with the client's long-term
995 key. Instead, it encrypts it with either a shared key derived from a
996 Diffie-Hellman exchange, or a generated encryption key. The contents
997 of the PA-PK-AS-REP indicate which key delivery method is used.
999 In addition, the lifetime of the ticket returned by the KDC MUST NOT
1000 exceed that of the client's public-private key pair. The ticket
1001 lifetime, however, can be shorter than that of the client's public-
1002 private key pair. For the implementations of this specification, the
1003 lifetime of the client's public-private key pair is the validity
1007 Zhu & Tung Expires June 15, 2006 [Page 18]
1009 Internet-Draft PKINIT December 2005
1012 period in X.509 certificates [RFC3280], unless configured otherwise.
1014 3.2.3.1. Using Diffie-Hellman Key Exchange
1016 In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
1018 The ContentInfo [RFC3852] structure for the dhSignedData field is
1019 filled in as follows:
1021 1. The contentType field of the type ContentInfo is id-signedData
1022 (as defined in [RFC3852]), and the content field is a SignedData
1023 (as defined in [RFC3852]).
1025 2. The eContentType field for the type SignedData is the OID value
1026 for id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1)
1027 security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }. Notes to CMS
1028 implementers: the signed attribute content-type MUST be present
1029 in this SignedData instance and its value is id-pkinit-DHKeyData
1030 according to [RFC3852].
1032 3. The eContent field for the type SignedData contains the DER
1033 encoding of the type KDCDHKeyInfo.
1035 4. The KDCDHKeyInfo structure contains the KDC's public key, a nonce
1036 and optionally the expiration time of the KDC's DH key being
1037 reused. The subjectPublicKey field of the type KDCDHKeyInfo
1038 field identifies KDC's DH public key. This DH public key value
1039 is encoded as a BIT STRING according to [RFC3279]. The nonce
1040 field contains the nonce in the pkAuthenticator field in the
1041 request if the DH keys are NOT reused. The value of this nonce
1042 field is 0 if the DH keys are reused. The dhKeyExpiration field
1043 is present if and only if the DH keys are reused. If the
1044 dhKeyExpiration field is present, the KDC's public key in this
1045 KDCDHKeyInfo structure MUST NOT be used past the point of this
1046 expiration time. If this field is omitted then the serverDHNonce
1047 field MUST also be omitted.
1049 5. The signerInfos field of the type SignedData contains a single
1050 signerInfo, which contains the signature over the type
1053 6. The certificates field of the type SignedData contains
1054 certificates intended to facilitate certification path
1055 construction, so that the client can verify the KDC's signature
1056 over the type KDCDHKeyInfo. The information contained in the
1057 trustedCertifiers in the request SHOULD be used by the KDC as
1058 hints to guide its selection of an appropriate certificate chain
1059 to return to the client. This field may be left empty if the KDC
1063 Zhu & Tung Expires June 15, 2006 [Page 19]
1065 Internet-Draft PKINIT December 2005
1068 public key specified by the kdcPkId field in the PA-PK-AS-REQ was
1069 used for signing. Otherwise, for path validation, these
1070 certificates SHOULD be sufficient to construct at least one
1071 certification path from the KDC certificate to one trust anchor
1072 acceptable by the client [RFC4158]. The KDC MUST be capable of
1073 including such a set of certificates if configured to do so. The
1074 certificates field MUST NOT contain "root" CA certificates.
1076 7. If the client included the clientDHNonce field, then the KDC may
1077 choose to reuse its DH keys. If the server reuses DH keys then
1078 it MUST include an expiration time in the dhKeyExpiration field.
1079 Past the point of the expiration time, the signature over the
1080 type DHRepInfo is considered expired/invalid. When the server
1081 reuses DH keys then it MUST include a serverDHNonce at least as
1082 long as the length of keys for the symmetric encryption system
1083 used to encrypt the AS reply. Note that including the
1084 serverDHNonce changes how the client and server calculate the key
1085 to use to encrypt the reply; see below for details. The KDC
1086 SHOULD NOT reuse DH keys unless the clientDHNonce field is
1087 present in the request.
1089 The AS reply key is derived as follows:
1091 1. Both the KDC and the client calculate the shared secret value as
1094 a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
1095 shared secret value. DHSharedSecret is the value ZZ as
1096 described in Section 2.1.1 of [RFC2631].
1098 DHSharedSecret is first padded with leading zeros such that the
1099 size of DHSharedSecret in octets is the same as that of the
1100 modulus, then represented as a string of octets in big-endian
1103 Implementation note: Both the client and the KDC can cache the
1104 triple (ya, yb, DHSharedSecret), where ya is the client's public
1105 key and yb is the KDC's public key. If both ya and yb are the
1106 same in a later exchange, the cached DHSharedSecret can be used.
1108 2. Let K be the key-generation seed length [RFC3961] of the AS reply
1109 key whose enctype is selected according to [RFC4120].
1111 3. Define the function octetstring2key() as follows:
1119 Zhu & Tung Expires June 15, 2006 [Page 20]
1121 Internet-Draft PKINIT December 2005
1124 octetstring2key(x) == random-to-key(K-truncate(
1131 where x is an octet string; | is the concatenation operator; 0x00,
1132 0x01, 0x02, etc., are each represented as a single octet; random-
1133 to-key() is an operation that generates a protocol key from a
1134 bitstring of length K; and K-truncate truncates its input to the
1135 first K bits. Both K and random-to-key() are as defined in the
1136 kcrypto profile [RFC3961] for the enctype of the AS reply key.
1138 4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
1139 the serverDHNonce; otherwise, let both n_c and n_k be empty octet
1142 5. The AS reply key k is:
1144 k = octetstring2key(DHSharedSecret | n_c | n_k)
1146 If the hash algorithm used in the key derivation function (currently
1147 only octetstring2key() is defined) is not acceptable by the KDC, the
1148 KDC MUST return a KRB-ERROR [RFC4120] message with the code
1149 KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED. The accompanying e-data MUST be
1150 encoded in TYPED-DATA although none is defined at this point.
1152 3.2.3.2. Using Public Key Encryption
1154 In this case, the PA-PK-AS-REP contains the encKeyPack field where
1155 the AS reply key is encrypted.
1157 The ContentInfo [RFC3852] structure for the encKeyPack field is
1158 filled in as follows:
1160 1. The contentType field of the type ContentInfo is id-envelopedData
1161 (as defined in [RFC3852]), and the content field is an
1162 EnvelopedData (as defined in [RFC3852]).
1164 2. The contentType field for the type EnvelopedData is id-
1165 signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
1166 pkcs (1) pkcs7 (7) signedData (2) }.
1168 3. The eContentType field for the inner type SignedData (when
1169 decrypted from the encryptedContent field for the type
1170 EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6)
1171 internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }.
1175 Zhu & Tung Expires June 15, 2006 [Page 21]
1177 Internet-Draft PKINIT December 2005
1180 Notes to CMS implementers: the signed attribute content-type MUST
1181 be present in this SignedData instance and its value is id-
1182 pkinit-rkeyData according to [RFC3852].
1184 4. The eContent field for the inner type SignedData contains the DER
1185 encoding of the type ReplyKeyPack (as described below).
1187 5. The signerInfos field of the inner type SignedData contains a
1188 single signerInfo, which contains the signature for the type
1191 6. The certificates field of the inner type SignedData contains
1192 certificates intended to facilitate certification path
1193 construction, so that the client can verify the KDC's signature
1194 for the type ReplyKeyPack. The information contained in the
1195 trustedCertifiers in the request SHOULD be used by the KDC as
1196 hints to guide its selection of an appropriate certificate chain
1197 to return to the client. This field may be left empty if the KDC
1198 public key specified by the kdcPkId field in the PA-PK-AS-REQ was
1199 used for signing. Otherwise, for path validation, these
1200 certificates SHOULD be sufficient to construct at least one
1201 certification path from the KDC certificate to one trust anchor
1202 acceptable by the client [RFC4158]. The KDC MUST be capable of
1203 including such a set of certificates if configured to do so. The
1204 certificates field MUST NOT contain "root" CA certificates.
1206 7. The recipientInfos field of the type EnvelopedData is a SET which
1207 MUST contain exactly one member of type KeyTransRecipientInfo.
1208 The encryptedKey of this member contains the temporary key which
1209 is encrypted using the client's public key.
1211 8. The unprotectedAttrs or originatorInfo fields of the type
1212 EnvelopedData MAY be present.
1214 If there is a supportedCMSTypes field in the AuthPack, the KDC must
1215 check to see if it supports any of the listed types. If it supports
1216 more than one of the types, the KDC SHOULD use the one listed first.
1217 If it does not support any of them, it MUST return an error message
1218 with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].
1220 Furthermore the KDC computes the checksum of the AS-REQ in the client
1221 request. This checksum is performed over the type AS-REQ and the
1222 protocol key [RFC3961] of the checksum operation is the replyKey and
1223 the key usage number is 6. If the replyKey's enctype is "newer"
1224 [RFC4120] [RFC4121], the checksum operation is the required checksum
1225 operation [RFC3961] of that enctype.
1231 Zhu & Tung Expires June 15, 2006 [Page 22]
1233 Internet-Draft PKINIT December 2005
1236 ReplyKeyPack ::= SEQUENCE {
1237 replyKey [0] EncryptionKey,
1238 -- Contains the session key used to encrypt the
1239 -- enc-part field in the AS-REP, i.e. the
1241 asChecksum [1] Checksum,
1242 -- Contains the checksum of the AS-REQ
1243 -- corresponding to the containing AS-REP.
1244 -- The checksum is performed over the type AS-REQ.
1245 -- The protocol key [RFC3961] of the checksum is the
1246 -- replyKey and the key usage number is 6.
1247 -- If the replyKey's enctype is "newer" [RFC4120]
1248 -- [RFC4121], the checksum is the required
1249 -- checksum operation [RFC3961] for that enctype.
1250 -- The client MUST verify this checksum upon receipt
1255 Implementations of this RSA encryption key delivery method are
1256 RECOMMENDED to support RSA keys at least 2048 bits in size.
1258 3.2.4. Receipt of KDC Reply
1260 Upon receipt of the KDC's reply, the client proceeds as follows. If
1261 the PA-PK-AS-REP contains the dhSignedData field, the client derives
1262 the AS reply key using the same procedure used by the KDC as defined
1263 in Section 3.2.3.1. Otherwise, the message contains the encKeyPack
1264 field, and the client decrypts and extracts the temporary key in the
1265 encryptedKey field of the member KeyTransRecipientInfo, and then uses
1266 that as the AS reply key.
1268 If the public key encryption method is used, the client MUST verify
1269 the asChecksum contained in the ReplyKeyPack.
1271 In either case, the client MUST verify the signature in the
1272 SignedData according to [RFC3852]. The KDC's X.509 certificate MUST
1273 be validated according to [RFC3280]. In addition, unless the client
1274 can otherwise verify that the public key used to verify the KDC's
1275 signature is bound to the KDC of the target realm, the KDC's X.509
1276 certificate MUST contain a Subject Alternative Name extension
1277 [RFC3280] carrying an AnotherName whose type-id is id-pkinit-san (as
1278 defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
1279 matches the name of the TGS of the target realm (as defined in
1280 Section 7.3 of [RFC4120]).
1282 Unless the client knows by some other means that the KDC certificate
1283 is intended for a Kerberos KDC, the client MUST require that the KDC
1287 Zhu & Tung Expires June 15, 2006 [Page 23]
1289 Internet-Draft PKINIT December 2005
1292 certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc:
1294 id-pkinit-KPKdc OBJECT IDENTIFIER ::=
1295 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
1296 pkinit(3) keyPurposeKdc(5) }
1297 -- Signing KDC responses.
1298 -- Key usage bits that MUST be consistent:
1299 -- digitalSignature.
1301 The digitalSignature key usage bit [RFC3280] MUST be asserted when
1302 the intended purpose of the KDC's X.509 certificate is restricted
1303 with the id-pkinit-KPKdc EKU.
1305 If the KDC certificate contains the Kerberos TGS name encoded as an
1306 id-pkinit-san SAN, this certificate is certified by the issuing CA as
1307 a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required.
1309 If all applicable checks are satisfied, the client then decrypts the
1310 enc-part field of the KDC-REP in the AS-REP using the AS reply key,
1311 and then proceeds as described in [RFC4120].
1313 Implementation note: CAs issuing KDC certificates SHOULD place all
1314 "short" and "fully-qualified" Kerberos realm names of the KDC (one
1315 per GeneralName [RFC3280]) into the KDC certificate to allow maximum
1318 3.3. Interoperability Requirements
1320 The client MUST be capable of sending a set of certificates
1321 sufficient to allow the KDC to construct a certification path for the
1322 client's certificate, if the correct set of certificates is provided
1323 through configuration or policy.
1325 If the client sends all the X.509 certificates on a certification
1326 path to a trust anchor acceptable by the KDC, and the KDC can not
1327 verify the client's public key otherwise, the KDC MUST be able to
1328 process path validation for the client's certificate based on the
1329 certificates in the request.
1331 The KDC MUST be capable of sending a set of certificates sufficient
1332 to allow the client to construct a certification path for the KDC's
1333 certificate, if the correct set of certificates is provided through
1334 configuration or policy.
1336 If the KDC sends all the X.509 certificates on a certification path
1337 to a trust anchor acceptable by the client, and the client can not
1338 verify the KDC's public key otherwise, the client MUST be able to
1339 process path validation for the KDC's certificate based on the
1343 Zhu & Tung Expires June 15, 2006 [Page 24]
1345 Internet-Draft PKINIT December 2005
1348 certificates in the reply.
1350 3.4. KDC Indication of PKINIT Support
1352 If pre-authentication is required, but was not present in the
1353 request, per [RFC4120] an error message with the code
1354 KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
1355 stored in the e-data field of the KRB-ERROR message to specify which
1356 pre-authentication mechanisms are acceptable. The KDC can then
1357 indicate the support of PKINIT by including an empty element whose
1358 padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
1360 Otherwise if it is required by the KDC's local policy that the client
1361 must be pre-authenticated using the pre-authentication mechanism
1362 specified in this document, but no PKINIT pre-authentication was
1363 present in the request, an error message with the code
1364 KDC_ERR_PREAUTH_FAILED SHOULD be returned.
1366 KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
1367 the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
1368 STRING), and clients MUST ignore this and any other value. Future
1369 extensions to this protocol may specify other data to send instead of
1370 an empty OCTET STRING.
1373 4. Security Considerations
1375 Kerberos error messages are not integrity protected, as a result, the
1376 domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered
1377 with by an attacker so that the set of domain parameters selected
1378 could be either weaker or not mutually preferred. Local policy can
1379 configure sets of domain parameters acceptable locally, or disallow
1380 the negotiation of DH domain parameters.
1382 The symmetric reply key size and Diffie-Hellman field size or RSA
1383 modulus size should be chosen so as to provide sufficient
1384 cryptographic security [RFC3766].
1386 When MODP Diffie-Hellman is used, the exponents should have at least
1387 twice as many bits as the symmetric keys that will be derived from
1390 PKINIT raises certain security considerations beyond those that can
1391 be regulated strictly in protocol definitions. We will address them
1394 PKINIT extends the cross-realm model to the public-key
1395 infrastructure. Users of PKINIT must understand security policies
1399 Zhu & Tung Expires June 15, 2006 [Page 25]
1401 Internet-Draft PKINIT December 2005
1404 and procedures appropriate to the use of Public Key Infrastructures
1407 In order to trust a KDC certificate that is certified by a CA as a
1408 KDC certificate for a target realm (for example, by asserting the TGS
1409 name of that Kerberos realm as an id-pkinit-san SAN and/or
1410 restricting the certificate usage by using the id-pkinit-KPKdc EKU,
1411 as described in Section 3.2.4), the client MUST verify that the KDC
1412 certificate's issuing CA is authorized to issue KDC certificates for
1413 that target realm. Otherwise, the binding between the KDC
1414 certificate and the KDC of the target realm is not established.
1416 How to validate this authorization is a matter of local policy. A
1417 way to achieve this is the configuration of specific sets of
1418 intermediary CAs and trust anchors, one of which must be on the KDC
1419 certificate's certification path [RFC3280]; and for each CA or trust
1420 anchor the realms for which it is allowed to issue certificates.
1422 In addition, if any CA is trusted to issue KDC certificates can also
1423 issue other kinds of certificates, then local policy must be able to
1424 distinguish between them: for example, it could require that KDC
1425 certificates contain the id-pkinit-KPKdc EKU or that the realm be
1426 specified with the id-pkinit-san SAN.
1428 It is the responsibility of the PKI administrators for an
1429 organization to ensure that KDC certificates are only issued to KDCs,
1430 and that clients can ascertain this using their local policy.
1432 Standard Kerberos allows the possibility of interactions between
1433 cryptosystems of varying strengths; this document adds interactions
1434 with public-key cryptosystems to Kerberos. Some administrative
1435 policies may allow the use of relatively weak public keys. Using
1436 such keys to wrap data encrypted under stronger conventional
1437 cryptosystems may be inappropriate.
1439 PKINIT requires keys for symmetric cryptosystems to be generated.
1440 Some such systems contain "weak" keys. For recommendations regarding
1441 these weak keys, see [RFC4120].
1443 PKINIT allows the use of the same RSA key pair for encryption and
1444 signing when doing RSA encryption based key delivery. This is not
1445 recommended usage of RSA keys [RFC3447], by using DH based key
1446 delivery this is avoided.
1448 Care should be taken in how certificates are chosen for the purposes
1449 of authentication using PKINIT. Some local policies may require that
1450 key escrow be used for certain certificate types. Deployers of
1451 PKINIT should be aware of the implications of using certificates that
1455 Zhu & Tung Expires June 15, 2006 [Page 26]
1457 Internet-Draft PKINIT December 2005
1460 have escrowed keys for the purposes of authentication. Because
1461 signing only certificates are normally not escrowed, by using DH
1462 based key delivery this is avoided.
1464 PKINIT does not provide for a "return routability" test to prevent
1465 attackers from mounting a denial-of-service attack on the KDC by
1466 causing it to perform unnecessary and expensive public-key
1467 operations. Strictly speaking, this is also true of standard
1468 Kerberos, although the potential cost is not as great, because
1469 standard Kerberos does not make use of public-key cryptography. By
1470 using DH based key delivery and reusing DH keys, the necessary crypto
1471 processing cost per request can be minimized.
1473 The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
1474 permit empty SEQUENCEs to be encoded. Such empty sequences may only
1475 be used if the KDC itself vouches for the user's certificate.
1477 When the Diffie-Hellman key exchange method is used, additional pre-
1478 authentication data [RFC4120] (in addition to the PA_PK_AS_REQ as
1479 defined in this specification) is not bound to the AS_REQ by the
1480 mechanisms discussed in this specification (meaning it may be dropped
1481 or added by attackers without being detected by either the client or
1482 the KDC). Designers of additional pre-authentication data should
1483 take that into consideration if such additional pre-authentication
1484 data can be used in conjunction with the PA_PK_AS_REQ. The future
1485 work of the Kerberos working group is expected to update the hash
1486 algorithms specified in this document and provide a generic mechanism
1487 to bind additional pre-authentication data with the accompanying
1493 The following people have made significant contributions to this
1494 draft: Paul Leach, Stefan Santesson, Sam Hartman, Love Hornquist
1495 Astrand, Ken Raeburn, Nicolas Williams, John Wray, Tom Yu, Jeffrey
1496 Hutzelman, David Cross, Dan Simon, Karthik Jaganathan, Chaskiel M
1497 Grundman and Jeffrey Altman.
1499 Andre Scedrov, Aaron D. Jaggard, Iliano Cervesato, Joe-Kai Tsay and
1500 Chris Walstad discovered a binding issue between the AS-REQ and AS-
1501 REP in draft -26, the asChecksum field was added as the result.
1503 Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and
1504 Jonathan Trostle who wrote earlier versions of this document.
1506 The authors are indebted to the Kerberos working group chair Jeffrey
1507 Hutzelman who kept track of various issues and was enormously helpful
1511 Zhu & Tung Expires June 15, 2006 [Page 27]
1513 Internet-Draft PKINIT December 2005
1516 during the creation of this document.
1518 Some of the ideas on which this document is based arose during
1519 discussions over several years between members of the SAAG, the IETF
1520 CAT working group, and the PSRG, regarding integration of Kerberos
1521 and SPX. Some ideas have also been drawn from the DASS system.
1522 These changes are by no means endorsed by these groups. This is an
1523 attempt to revive some of the goals of those groups, and this
1524 document approaches those goals primarily from the Kerberos
1527 Lastly, comments from groups working on similar ideas in DCE have
1531 6. IANA Considerations
1533 This document has no actions for IANA.
1538 7.1. Normative References
1541 IEEE, "Standard Specifications for Public Key
1542 Cryptography", IEEE 1363, 2000.
1544 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1545 Requirement Levels", BCP 14, RFC 2119, March 1997.
1547 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
1548 RFC 2412, November 1998.
1550 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
1551 RFC 2631, June 1999.
1553 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
1554 Identifiers for the Internet X.509 Public Key
1555 Infrastructure Certificate and Certificate Revocation List
1556 (CRL) Profile", RFC 3279, April 2002.
1558 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
1559 X.509 Public Key Infrastructure Certificate and
1560 Certificate Revocation List (CRL) Profile", RFC 3280,
1563 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
1567 Zhu & Tung Expires June 15, 2006 [Page 28]
1569 Internet-Draft PKINIT December 2005
1572 Algorithms", RFC 3370, August 2002.
1574 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
1575 Standards (PKCS) #1: RSA Cryptography Specifications
1576 Version 2.1", RFC 3447, February 2003.
1578 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
1579 Diffie-Hellman groups for Internet Key Exchange (IKE)",
1582 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES)
1583 Encryption Algorithm in Cryptographic Message Syntax
1584 (CMS)", RFC 3565, July 2003.
1586 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
1587 Public Keys Used For Exchanging Symmetric Keys", BCP 86,
1588 RFC 3766, April 2004.
1590 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
1591 RFC 3852, July 2004.
1593 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
1594 Kerberos 5", RFC 3961, February 2005.
1596 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES)
1597 Encryption for Kerberos 5", RFC 3962, February 2005.
1599 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
1600 Kerberos Network Authentication Service (V5)", RFC 4120,
1603 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
1604 Version 5 Generic Security Service Application Program
1605 Interface (GSS-API) Mechanism: Version 2", RFC 4121,
1608 [X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
1609 Information technology - Abstract Syntax Notation One
1610 (ASN.1): Specification of basic notation.
1612 [X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
1613 Information technology - ASN.1 encoding Rules: Specification
1614 of Basic Encoding Rules (BER), Canonical Encoding Rules
1615 (CER) and Distinguished Encoding Rules (DER).
1621 Zhu & Tung Expires June 15, 2006 [Page 29]
1623 Internet-Draft PKINIT December 2005
1626 7.2. Informative References
1628 [LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
1629 Sizes", Journal of Cryptology 14 (2001) 255-293.
1631 [ODL99] Odlyzko, A., "Discrete logarithms: The past and the
1632 future, Designs, Codes, and Cryptography (1999)".
1634 [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
1635 Nicholas, "Internet X.509 Public Key Infrastructure:
1636 Certification Path Building", RFC 4158, September 2005.
1639 Appendix A. PKINIT ASN.1 Module
1641 KerberosV5-PK-INIT-SPEC {
1642 iso(1) identified-organization(3) dod(6) internet(1)
1643 security(5) kerberosV5(2) modules(4) pkinit(5)
1644 } DEFINITIONS EXPLICIT TAGS ::= BEGIN
1647 SubjectPublicKeyInfo, AlgorithmIdentifier
1648 FROM PKIX1Explicit88 { iso (1)
1649 identified-organization (3) dod (6) internet (1)
1650 security (5) mechanisms (5) pkix (7) id-mod (0)
1651 id-pkix1-explicit (18) }
1652 -- As defined in RFC 3280.
1654 KerberosTime, PrincipalName, Realm, EncryptionKey
1655 FROM KerberosV5Spec2 { iso(1) identified-organization(3)
1656 dod(6) internet(1) security(5) kerberosV5(2)
1657 modules(4) krb5spec2(2) } ;
1659 id-pkinit OBJECT IDENTIFIER ::=
1660 { iso (1) org (3) dod (6) internet (1) security (5)
1661 kerberosv5 (2) pkinit (3) }
1663 id-pkinit-authData OBJECT IDENTIFIER ::= { id-pkinit 1 }
1664 id-pkinit-DHKeyData OBJECT IDENTIFIER ::= { id-pkinit 2 }
1665 id-pkinit-rkeyData OBJECT IDENTIFIER ::= { id-pkinit 3 }
1666 id-pkinit-KPClientAuth OBJECT IDENTIFIER ::= { id-pkinit 4 }
1667 id-pkinit-KPKdc OBJECT IDENTIFIER ::= { id-pkinit 5 }
1669 id-pkinit-san OBJECT IDENTIFIER ::=
1670 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
1675 Zhu & Tung Expires June 15, 2006 [Page 30]
1677 Internet-Draft PKINIT December 2005
1680 pa-pk-as-req INTEGER ::= 16
1681 pa-pk-as-rep INTEGER ::= 17
1683 ad-initial-verified-cas INTEGER ::= 9
1685 td-trusted-certifiers INTEGER ::= 104
1686 td-invalid-certificates INTEGER ::= 105
1687 td-dh-parameters INTEGER ::= 109
1689 PA-PK-AS-REQ ::= SEQUENCE {
1690 signedAuthPack [0] IMPLICIT OCTET STRING,
1691 -- Contains a CMS type ContentInfo encoded
1692 -- according to [RFC3852].
1693 -- The contentType field of the type ContentInfo
1694 -- is id-signedData (1.2.840.113549.1.7.2),
1695 -- and the content field is a SignedData.
1696 -- The eContentType field for the type SignedData is
1697 -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
1698 -- eContent field contains the DER encoding of the
1700 -- AuthPack is defined below.
1701 trustedCertifiers [1] SEQUENCE OF
1702 ExternalPrincipalIdentifier OPTIONAL,
1703 -- Contains a list of CAs, trusted by the client,
1704 -- that can be used to certify the KDC.
1705 -- Each ExternalPrincipalIdentifier identifies a CA
1706 -- or a CA certificate (thereby its public key).
1707 -- The information contained in the
1708 -- trustedCertifiers SHOULD be used by the KDC as
1709 -- hints to guide its selection of an appropriate
1710 -- certificate chain to return to the client.
1711 kdcPkId [2] IMPLICIT OCTET STRING
1713 -- Contains a CMS type SignerIdentifier encoded
1714 -- according to [RFC3852].
1715 -- Identifies, if present, a particular KDC
1716 -- public key that the client already has.
1720 DHNonce ::= OCTET STRING
1722 ExternalPrincipalIdentifier ::= SEQUENCE {
1723 subjectName [0] IMPLICIT OCTET STRING OPTIONAL,
1724 -- Contains a PKIX type Name encoded according to
1726 -- Identifies the certificate subject by the
1727 -- distinguished subject name.
1731 Zhu & Tung Expires June 15, 2006 [Page 31]
1733 Internet-Draft PKINIT December 2005
1736 -- REQUIRED when there is a distinguished subject
1737 -- name present in the certificate.
1738 issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL,
1739 -- Contains a CMS type IssuerAndSerialNumber encoded
1740 -- according to [RFC3852].
1741 -- Identifies a certificate of the subject.
1742 -- REQUIRED for TD-INVALID-CERTIFICATES and
1743 -- TD-TRUSTED-CERTIFIERS.
1744 subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL,
1745 -- Identifies the subject's public key by a key
1746 -- identifier. When an X.509 certificate is
1747 -- referenced, this key identifier matches the X.509
1748 -- subjectKeyIdentifier extension value. When other
1749 -- certificate formats are referenced, the documents
1750 -- that specify the certificate format and their use
1751 -- with the CMS must include details on matching the
1752 -- key identifier to the appropriate certificate
1754 -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
1758 AuthPack ::= SEQUENCE {
1759 pkAuthenticator [0] PKAuthenticator,
1760 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
1761 -- Type SubjectPublicKeyInfo is defined in
1763 -- Specifies Diffie-Hellman domain parameters
1764 -- and the client's public key value [IEEE1363].
1765 -- The DH public key value is encoded as a BIT
1766 -- STRING according to [RFC3279].
1767 -- This field is present only if the client wishes
1768 -- to use the Diffie-Hellman key agreement method.
1769 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
1771 -- Type AlgorithmIdentifier is defined in
1773 -- List of CMS encryption types supported by the
1774 -- client in order of (decreasing) preference.
1775 clientDHNonce [3] DHNonce OPTIONAL,
1776 -- Present only if the client indicates that it
1777 -- wishes to reuse DH keys or to allow the KDC to
1782 PKAuthenticator ::= SEQUENCE {
1783 cusec [0] INTEGER (0..999999),
1787 Zhu & Tung Expires June 15, 2006 [Page 32]
1789 Internet-Draft PKINIT December 2005
1792 ctime [1] KerberosTime,
1793 -- cusec and ctime are used as in [RFC4120], for
1794 -- replay prevention.
1795 nonce [2] INTEGER (0..4294967295),
1796 -- Chosen randomly; This nonce does not need to
1797 -- match with the nonce in the KDC-REQ-BODY.
1798 paChecksum [3] OCTET STRING,
1799 -- Contains the SHA1 checksum, performed over
1804 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
1805 ExternalPrincipalIdentifier
1806 -- Identifies a list of CAs trusted by the KDC.
1807 -- Each ExternalPrincipalIdentifier identifies a CA
1808 -- or a CA certificate (thereby its public key).
1810 TD-INVALID-CERTIFICATES ::= SEQUENCE OF
1811 ExternalPrincipalIdentifier
1812 -- Each ExternalPrincipalIdentifier identifies a
1813 -- certificate (sent by the client) with an invalid
1816 KRB5PrincipalName ::= SEQUENCE {
1818 principalName [1] PrincipalName
1821 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
1822 ExternalPrincipalIdentifier
1823 -- Identifies the certification path based on which
1824 -- the client certificate was validated.
1825 -- Each ExternalPrincipalIdentifier identifies a CA
1826 -- or a CA certificate (thereby its public key).
1828 PA-PK-AS-REP ::= CHOICE {
1829 dhInfo [0] DHRepInfo,
1830 -- Selected when Diffie-Hellman key exchange is
1832 encKeyPack [1] IMPLICIT OCTET STRING,
1833 -- Selected when public key encryption is used.
1834 -- Contains a CMS type ContentInfo encoded
1835 -- according to [RFC3852].
1836 -- The contentType field of the type ContentInfo is
1837 -- id-envelopedData (1.2.840.113549.1.7.3).
1838 -- The content field is an EnvelopedData.
1839 -- The contentType field for the type EnvelopedData
1843 Zhu & Tung Expires June 15, 2006 [Page 33]
1845 Internet-Draft PKINIT December 2005
1848 -- is id-signedData (1.2.840.113549.1.7.2).
1849 -- The eContentType field for the inner type
1850 -- SignedData (when unencrypted) is
1851 -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
1852 -- eContent field contains the DER encoding of the
1853 -- type ReplyKeyPack.
1854 -- ReplyKeyPack is defined below.
1858 DHRepInfo ::= SEQUENCE {
1859 dhSignedData [0] IMPLICIT OCTET STRING,
1860 -- Contains a CMS type ContentInfo encoded according
1862 -- The contentType field of the type ContentInfo is
1863 -- id-signedData (1.2.840.113549.1.7.2), and the
1864 -- content field is a SignedData.
1865 -- The eContentType field for the type SignedData is
1866 -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
1867 -- eContent field contains the DER encoding of the
1868 -- type KDCDHKeyInfo.
1869 -- KDCDHKeyInfo is defined below.
1870 serverDHNonce [1] DHNonce OPTIONAL,
1871 -- Present if and only if dhKeyExpiration is
1876 KDCDHKeyInfo ::= SEQUENCE {
1877 subjectPublicKey [0] BIT STRING,
1878 -- The KDC's DH public key.
1879 -- The DH public key value is encoded as a BIT
1880 -- STRING according to [RFC3279].
1881 nonce [1] INTEGER (0..4294967295),
1882 -- Contains the nonce in the pkAuthenticator field
1883 -- in the request if the DH keys are NOT reused,
1885 dhKeyExpiration [2] KerberosTime OPTIONAL,
1886 -- Expiration time for KDC's key pair,
1887 -- present if and only if the DH keys are reused.
1888 -- If present, the KDC's DH public key MUST not be
1889 -- used past the point of this expiration time.
1890 -- If this field is omitted then the serverDHNonce
1891 -- field MUST also be omitted.
1895 ReplyKeyPack ::= SEQUENCE {
1899 Zhu & Tung Expires June 15, 2006 [Page 34]
1901 Internet-Draft PKINIT December 2005
1904 replyKey [0] EncryptionKey,
1905 -- Contains the session key used to encrypt the
1906 -- enc-part field in the AS-REP, i.e. the
1908 asChecksum [1] Checksum,
1909 -- Contains the checksum of the AS-REQ
1910 -- corresponding to the containing AS-REP.
1911 -- The checksum is performed over the type AS-REQ.
1912 -- The protocol key [RFC3961] of the checksum is the
1913 -- replyKey and the key usage number is 6.
1914 -- If the replyKey's enctype is "newer" [RFC4120]
1915 -- [RFC4121], the checksum is the required
1916 -- checksum operation [RFC3961] for that enctype.
1917 -- The client MUST verify this checksum upon receipt
1922 TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
1923 -- Each AlgorithmIdentifier specifies a set of
1924 -- Diffie-Hellman domain parameters [IEEE1363].
1925 -- This list is in decreasing preference order.
1929 Appendix B. Test Vectors
1931 Function octetstring2key() is defined in Section 3.2.3.1. This
1932 section describes a few sets of test vectors that would be useful for
1933 implementers of octetstring2key().
1938 Input octet string x is:
1940 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1941 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1942 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1943 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1944 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1945 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1946 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1947 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1948 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1949 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1950 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1951 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1955 Zhu & Tung Expires June 15, 2006 [Page 35]
1957 Internet-Draft PKINIT December 2005
1960 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1961 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1962 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1963 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1965 Output of K-truncate() when the key size is 32 octets:
1967 5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83
1968 75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41
1973 Input octet string x is:
1975 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1976 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1977 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1978 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1979 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1980 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1981 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1982 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1984 Output of K-truncate() when the key size is 32 octets:
1986 ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb
1987 a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e
1992 Input octet string x is:
1994 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
1995 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
1996 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
1997 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
1998 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b
1999 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a
2000 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09
2001 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
2003 Output of K-truncate() when the key size is 32 octets:
2005 c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3
2006 73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e
2011 Zhu & Tung Expires June 15, 2006 [Page 36]
2013 Internet-Draft PKINIT December 2005
2018 Input octet string x is:
2020 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
2021 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
2022 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
2023 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
2024 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
2026 Output of K-truncate() when the key size is 32 octets:
2028 00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a
2029 59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc
2032 Appendix C. Miscellaneous Information about Microsoft Windows PKINIT
2035 Earlier revisions of the PKINIT I-D were implemented in various
2036 releases of Microsoft Windows and deployed in fairly large numbers.
2037 To enable the community to better interoperate with systems running
2038 those releases, the following information may be useful.
2040 KDC certificates issued by Windows 2000 Enterprise CAs contain a
2041 dNSName SAN with the DNS name of the host running the KDC, and the
2042 id-kp-serverAuth EKU [RFC3280].
2044 KDC certificates issued by Windows 2003 Enterprise CAs contain a
2045 dNSName SAN with the DNS name of the host running the KDC, the id-kp-
2046 serverAuth EKU and the id-ms-kp-sc-logon EKU.
2048 It is anticipated that the next release of Windows is already too far
2049 along to allow it to support the issuing KDC certificates with id-
2050 pkinit-san SAN as specified in this RFC. Instead, they will have a
2051 dNSName SAN containing the domain name of the KDC and the intended
2052 purpose of these KDC certificates be restricted by the presence of
2053 the id-pkinit-KPKdc EKU and id-kp-serverAuth EKU.
2055 In addition to checking that the above are present in a KDC
2056 certificate, Windows clients verify that the issuer of the KDC
2057 certificate is one of a set of allowed issuers of such certificates,
2058 so those wishing to issue KDC certificates need to configure their
2059 Windows clients appropriately.
2061 Client certificates accepted by Windows 2000 and Windows 2003 Server
2062 KDCs must contain an id-ms-san-sc-logon-upn (1.3.6.1.4.1.311.20.2.3)
2063 SAN and the id-ms-kp-sc-logon EKU. The id-ms-san-sc-logon-upn SAN
2067 Zhu & Tung Expires June 15, 2006 [Page 37]
2069 Internet-Draft PKINIT December 2005
2072 contains a UTF8 encoded string whose value is that of the Directory
2073 Service attribute UserPrincipalName of the client account object, and
2074 the purpose of including the id-ms-san-sc-logon-upn SAN in the client
2075 certificate is to validate the client mapping (in other words, the
2076 client's public key is bound to the account that has this
2077 UserPrincipalName value).
2079 It should be noted that all Microsoft Kerberos realm names are domain
2080 style realm names and strictly in upper case. In addition, the
2081 UserPrincipalName attribute is globally unique in Windows 2000 and
2123 Zhu & Tung Expires June 15, 2006 [Page 38]
2125 Internet-Draft PKINIT December 2005
2131 Microsoft Corporation
2136 Email: lzhu@microsoft.com
2140 USC Information Sciences Institute
2141 4676 Admiralty Way Suite 1001
2142 Marina del Rey, CA 90292
2145 Email: brian@isi.edu
2179 Zhu & Tung Expires June 15, 2006 [Page 39]
2181 Internet-Draft PKINIT December 2005
2184 Intellectual Property Statement
2186 The IETF takes no position regarding the validity or scope of any
2187 Intellectual Property Rights or other rights that might be claimed to
2188 pertain to the implementation or use of the technology described in
2189 this document or the extent to which any license under such rights
2190 might or might not be available; nor does it represent that it has
2191 made any independent effort to identify any such rights. Information
2192 on the procedures with respect to rights in RFC documents can be
2193 found in BCP 78 and BCP 79.
2195 Copies of IPR disclosures made to the IETF Secretariat and any
2196 assurances of licenses to be made available, or the result of an
2197 attempt made to obtain a general license or permission for the use of
2198 such proprietary rights by implementers or users of this
2199 specification can be obtained from the IETF on-line IPR repository at
2200 http://www.ietf.org/ipr.
2202 The IETF invites any interested party to bring to its attention any
2203 copyrights, patents or patent applications, or other proprietary
2204 rights that may cover technology that may be required to implement
2205 this standard. Please address the information to the IETF at
2209 Disclaimer of Validity
2211 This document and the information contained herein are provided on an
2212 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2213 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2214 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2215 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
2216 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2217 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2222 Copyright (C) The Internet Society (2005). This document is subject
2223 to the rights, licenses and restrictions contained in BCP 78, and
2224 except as set forth therein, the authors retain all their rights.
2229 Funding for the RFC Editor function is currently provided by the
2235 Zhu & Tung Expires June 15, 2006 [Page 40]