| blob | 2ff94392897bee8df243612a0a9ab669275d017d |
7 Network Working Group L. Zhu
8 Request for Comments: 4556 Microsoft Corporation
9 Category: Standards Track B. Tung
10 Aerospace Corporation
11 June 2006
14 Public Key Cryptography for
15 Initial Authentication in Kerberos (PKINIT)
18 Status of This Memo
20 This document specifies an Internet standards track protocol for the
21 Internet community, and requests discussion and suggestions for
22 improvements. Please refer to the current edition of the "Internet
23 Official Protocol Standards" (STD 1) for the standardization state
24 and status of this protocol. Distribution of this memo is unlimited.
26 Copyright Notice
28 Copyright (C) The Internet Society (2006).
30 Abstract
32 This document describes protocol extensions (hereafter called PKINIT)
33 to the Kerberos protocol specification. These extensions provide a
34 method for integrating public key cryptography into the initial
35 authentication exchange, by using asymmetric-key signature and/or
36 encryption algorithms in pre-authentication data fields.
38 Table of Contents
40 1. Introduction ....................................................2
41 2. Conventions Used in This Document ...............................4
42 3. Extensions ......................................................5
43 3.1. Definitions, Requirements, and Constants ...................6
44 3.1.1. Required Algorithms .................................6
45 3.1.2. Recommended Algorithms ..............................6
46 3.1.3. Defined Message and Encryption Types ................7
47 3.1.4. Kerberos Encryption Types Defined for CMS
48 Algorithm Identifiers ...............................8
49 3.2. PKINIT Pre-authentication Syntax and Use ...................9
50 3.2.1. Generation of Client Request ........................9
51 3.2.2. Receipt of Client Request ..........................14
52 3.2.3. Generation of KDC Reply ............................18
53 3.2.3.1. Using Diffie-Hellman Key Exchange .........21
54 3.2.3.2. Using Public Key Encryption ...............23
58 Zhu & Tung Standards Track [Page 1]
59 \f
60 RFC 4556 PKINIT June 2006
63 3.2.4. Receipt of KDC Reply ...............................25
64 3.3. Interoperability Requirements .............................26
65 3.4. KDC Indication of PKINIT Support ..........................27
66 4. Security Considerations ........................................27
67 5. Acknowledgements ...............................................30
68 6. References .....................................................30
69 6.1. Normative References ......................................30
70 6.2. Informative References ....................................32
71 Appendix A. PKINIT ASN.1 Module ..................................33
72 Appendix B. Test Vectors .........................................38
73 Appendix C. Miscellaneous Information about Microsoft Windows
74 PKINIT Implementations ...............................40
76 1. Introduction
78 The Kerberos V5 protocol [RFC4120] involves use of a trusted third
79 party known as the Key Distribution Center (KDC) to negotiate shared
80 session keys between clients and services and provide mutual
81 authentication between them.
83 The corner-stones of Kerberos V5 are the Ticket and the
84 Authenticator. A Ticket encapsulates a symmetric key (the ticket
85 session key) in an envelope (a public message) intended for a
86 specific service. The contents of the Ticket are encrypted with a
87 symmetric key shared between the service principal and the issuing
88 KDC. The encrypted part of the Ticket contains the client principal
89 name, among other items. An Authenticator is a record that can be
90 shown to have been recently generated using the ticket session key in
91 the associated Ticket. The ticket session key is known by the client
92 who requested the ticket. The contents of the Authenticator are
93 encrypted with the associated ticket session key. The encrypted part
94 of an Authenticator contains a timestamp and the client principal
95 name, among other items.
97 As shown in Figure 1, below, the Kerberos V5 protocol consists of the
98 following message exchanges between the client and the KDC, and the
99 client and the application service:
101 - The Authentication Service (AS) Exchange
103 The client obtains an "initial" ticket from the Kerberos
104 authentication server (AS), typically a Ticket Granting Ticket
105 (TGT). The AS-REQ message and the AS-REP message are the request
106 and the reply message, respectively, between the client and the
107 AS.
114 Zhu & Tung Standards Track [Page 2]
115 \f
116 RFC 4556 PKINIT June 2006
119 - The Ticket Granting Service (TGS) Exchange
121 The client subsequently uses the TGT to authenticate and request a
122 service ticket for a particular service, from the Kerberos
123 ticket-granting server (TGS). The TGS-REQ message and the TGS-REP
124 message are the request and the reply message respectively between
125 the client and the TGS.
127 - The Client/Server Authentication Protocol (AP) Exchange
129 The client then makes a request with an AP-REQ message, consisting
130 of a service ticket and an authenticator that certifies the
131 client's possession of the ticket session key. The server may
132 optionally reply with an AP-REP message. AP exchanges typically
133 negotiate session-specific symmetric keys.
135 Usually, the AS and TGS are integrated in a single device also known
136 as the KDC.
138 +--------------+
139 +--------->| KDC |
140 AS-REQ / +-------| |
141 / / +--------------+
142 / / ^ |
143 / |AS-REP / |
144 | | / TGS-REQ + TGS-REP
145 | | / /
146 | | / /
147 | | / +---------+
148 | | / /
149 | | / /
150 | | / /
151 | v / v
152 ++-------+------+ +-----------------+
153 | Client +------------>| Application |
154 | | AP-REQ | Server |
155 | |<------------| |
156 +---------------+ AP-REP +-----------------+
158 Figure 1: The Message Exchanges in the Kerberos V5 Protocol
160 In the AS exchange, the KDC reply contains the ticket session key,
161 among other items, that is encrypted using a key (the AS reply key)
162 shared between the client and the KDC. The AS reply key is typically
163 derived from the client's password for human users. Therefore, for
164 human users, the attack resistance strength of the Kerberos protocol
165 is no stronger than the strength of their passwords.
170 Zhu & Tung Standards Track [Page 3]
171 \f
172 RFC 4556 PKINIT June 2006
175 The use of asymmetric cryptography in the form of X.509 certificates
176 [RFC3280] is popular for facilitating data origin authentication and
177 perfect secrecy. An established Public Key Infrastructure (PKI)
178 provides key management and key distribution mechanisms that can be
179 used to establish authentication and secure communication. Adding
180 public-key cryptography to Kerberos provides a nice congruence to
181 public-key protocols, obviates the human users' burden to manage
182 strong passwords, and allows Kerberized applications to take
183 advantage of existing key services and identity management.
185 The advantage afforded by the Kerberos TGT is that the client exposes
186 his long-term secrets only once. The TGT and its associated session
187 key can then be used for any subsequent service ticket requests. One
188 result of this is that all further authentication is independent of
189 the method by which the initial authentication was performed.
190 Consequently, initial authentication provides a convenient place to
191 integrate public-key cryptography into Kerberos authentication. In
192 addition, the use of symmetric cryptography after the initial
193 exchange is preferred for performance.
195 This document describes the methods and data formats using which the
196 client and the KDC can use public and private key pairs to mutually
197 authenticate in the AS exchange and negotiate the AS reply key, known
198 only by the client and the KDC, to encrypt the AS-REP sent by the
199 KDC.
201 2. Conventions Used in This Document
203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
205 document are to be interpreted as described in [RFC2119].
207 In this protocol, both the client and the KDC have a public-private
208 key pair in order to prove their identities to each other over the
209 open network. The term "signature key" is used to refer to the
210 private key of the key pair being used.
212 The encryption key used to encrypt the enc-part field of the KDC-REP
213 in the AS-REP [RFC4120] is referred to as the AS reply key.
215 An empty sequence in an optional field can be either included or
216 omitted: both encodings are permitted and considered equivalent.
218 The term "Modular Exponential Diffie-Hellman" is used to refer to the
219 Diffie-Hellman key exchange, as described in [RFC2631], in order to
220 differentiate it from other equivalent representations of the same
221 key agreement algorithm.
226 Zhu & Tung Standards Track [Page 4]
227 \f
228 RFC 4556 PKINIT June 2006
231 3. Extensions
233 This section describes extensions to [RFC4120] for supporting the use
234 of public-key cryptography in the initial request for a ticket.
236 Briefly, this document defines the following extensions to [RFC4120]:
238 1. The client indicates the use of public-key authentication by
239 including a special preauthenticator in the initial request. This
240 preauthenticator contains the client's public-key data and a
241 signature.
243 2. The KDC tests the client's request against its authentication
244 policy and trusted Certification Authorities (CAs).
246 3. If the request passes the verification tests, the KDC replies as
247 usual, but the reply is encrypted using either:
249 a. a key generated through a Diffie-Hellman (DH) key exchange
250 [RFC2631] [IEEE1363] with the client, signed using the KDC's
251 signature key; or
253 b. a symmetric encryption key, signed using the KDC's signature
254 key and encrypted using the client's public key.
256 Any keying material required by the client to obtain the
257 encryption key for decrypting the KDC reply is returned in a pre-
258 authentication field accompanying the usual reply.
260 4. The client validates the KDC's signature, obtains the encryption
261 key, decrypts the reply, and then proceeds as usual.
263 Section 3.1 of this document enumerates the required algorithms and
264 necessary extension message types. Section 3.2 describes the
265 extension messages in greater detail.
282 Zhu & Tung Standards Track [Page 5]
283 \f
284 RFC 4556 PKINIT June 2006
287 3.1. Definitions, Requirements, and Constants
289 3.1.1. Required Algorithms
291 All PKINIT implementations MUST support the following algorithms:
293 o AS reply key enctypes: aes128-cts-hmac-sha1-96 and aes256-cts-
294 hmac-sha1-96 [RFC3962].
296 o Signature algorithm: sha-1WithRSAEncryption [RFC3370].
298 o AS reply key delivery method: the Diffie-Hellman key delivery
299 method, as described in Section 3.2.3.1.
301 In addition, implementations of this specification MUST be capable of
302 processing the Extended Key Usage (EKU) extension and the id-pkinit-
303 san (as defined in Section 3.2.2) otherName of the Subject
304 Alternative Name (SAN) extension in X.509 certificates [RFC3280].
306 3.1.2. Recommended Algorithms
308 All PKINIT implementations SHOULD support the following algorithm:
310 o AS reply key delivery method: the public key encryption key
311 delivery method, as described in Section 3.2.3.2.
313 For implementations that support the public key encryption key
314 delivery method, the following algorithms MUST be supported:
316 a) Key transport algorithms identified in the keyEncryptionAlgorithm
317 field of the type KeyTransRecipientInfo [RFC3852] for encrypting
318 the temporary key in the encryptedKey field [RFC3852] with a
319 public key, as described in Section 3.2.3.2: rsaEncryption (this
320 is the RSAES-PKCS1-v1_5 encryption scheme) [RFC3370] [RFC3447].
322 b) Content encryption algorithms identified in the
323 contentEncryptionAlgorithm field of the type EncryptedContentInfo
324 [RFC3852] for encrypting the AS reply key with the temporary key
325 contained in the encryptedKey field of the type
326 KeyTransRecipientInfo [RFC3852], as described in Section 3.2.3.2:
327 des-ede3-cbc (three-key 3DES, CBC mode) [RFC3370].
338 Zhu & Tung Standards Track [Page 6]
339 \f
340 RFC 4556 PKINIT June 2006
343 3.1.3. Defined Message and Encryption Types
345 PKINIT makes use of the following new pre-authentication types:
347 PA_PK_AS_REQ 16
348 PA_PK_AS_REP 17
350 PKINIT also makes use of the following new authorization data type:
352 AD_INITIAL_VERIFIED_CAS 9
354 PKINIT introduces the following new error codes:
356 KDC_ERR_CLIENT_NOT_TRUSTED 62
357 KDC_ERR_INVALID_SIG 64
358 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65
359 KDC_ERR_CANT_VERIFY_CERTIFICATE 70
360 KDC_ERR_INVALID_CERTIFICATE 71
361 KDC_ERR_REVOKED_CERTIFICATE 72
362 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
363 KDC_ERR_CLIENT_NAME_MISMATCH 75
364 KDC_ERR_INCONSISTENT_KEY_PURPOSE 77
365 KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED 78
366 KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED 79
367 KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED 80
368 KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED 81
370 PKINIT uses the following typed data types for errors:
372 TD_TRUSTED_CERTIFIERS 104
373 TD_INVALID_CERTIFICATES 105
374 TD_DH_PARAMETERS 109
376 The ASN.1 module for all structures defined in this document (plus
377 IMPORT statements for all imported structures) is given in Appendix
378 A.
380 All structures defined in or imported into this document MUST be
381 encoded using Distinguished Encoding Rules (DER) [X680] [X690]
382 (unless otherwise noted). All data structures carried in OCTET
383 STRINGs MUST be encoded according to the rules specified in the
384 specifications defining each data structure; a reference to the
385 appropriate specification is provided for each data structure.
394 Zhu & Tung Standards Track [Page 7]
395 \f
396 RFC 4556 PKINIT June 2006
399 Interoperability note: Some implementations may not be able to decode
400 wrapped Cryptographic Message Syntax (CMS) [RFC3852] objects encoded
401 with BER; specifically, they may not be able to decode indefinite-
402 length encodings. To maximize interoperability, implementers SHOULD
403 encode CMS objects used in PKINIT with DER.
405 3.1.4. Kerberos Encryption Types Defined for CMS Algorithm Identifiers
407 PKINIT defines the following Kerberos encryption type numbers
408 [RFC3961], which can be used in the etype field of the AS-REQ
409 [RFC4120] message to indicate to the KDC the client's acceptance of
410 the corresponding algorithms (including key transport algorithms
411 [RFC3370], content encryption algorithms [RFC3370], and signature
412 algorithms) for use with Cryptographic Message Syntax (CMS) [RFC3852]
413 [RFC3370].
415 Per [RFC4120], the encryption types in the etype field are in the
416 decreasing preference order of the client. Note that there is no
417 significance in the relative order between any two of different types
418 of algorithms: key transport algorithms, content encryption
419 algorithms, and signature algorithms.
421 The presence of each of these encryption types in the etype field is
422 equivalent to the presence of the corresponding algorithm Object
423 Identifier (OID) in the supportedCMSTypes field as described in
424 Section 3.2.1. And the preference order expressed in the
425 supportedCMSTypes field would override the preference order listed in
426 the etype field.
428 Kerberos Encryption Type Name Num Corresponding Algorithm OID
429 ============================== === ===============================
430 id-dsa-with-sha1-CmsOID 9 id-dsa-with-sha1 [RFC3370]
431 md5WithRSAEncryption-CmsOID 10 md5WithRSAEncryption [RFC3370]
432 sha-1WithRSAEncryption-CmsOID 11 sha-1WithRSAEncryption [RFC3370]
433 rc2-cbc-EnvOID 12 rc2-cbc [RFC3370]
434 rsaEncryption-EnvOID 13 rsaEncryption [RFC3447][RFC3370]
435 id-RSAES-OAEP-EnvOID 14 id-RSAES-OAEP [RFC3447][RFC3560]
436 des-ede3-cbc-EnvOID 15 des-ede3-cbc [RFC3370]
450 Zhu & Tung Standards Track [Page 8]
451 \f
452 RFC 4556 PKINIT June 2006
455 The above encryption type numbers are used only to indicate support
456 for the use of the corresponding algorithms in PKINIT; they do not
457 correspond to actual Kerberos encryption types [RFC3961] and MUST NOT
458 be used in the etype field of the Kerberos EncryptedData type
459 [RFC4120]. The practice of assigning Kerberos encryption type
460 numbers to indicate support for CMS algorithms is considered
461 deprecated, and new numbers should not be assigned for this purpose.
462 Instead, the supportedCMSTypes field should be used to identify the
463 algorithms supported by the client and the preference order of the
464 client.
466 For maximum interoperability, however, PKINIT clients wishing to
467 indicate to the KDC the support for one or more of the algorithms
468 listed above SHOULD include the corresponding encryption type
469 number(s) in the etype field of the AS-REQ.
471 3.2. PKINIT Pre-authentication Syntax and Use
473 This section defines the syntax and use of the various pre-
474 authentication fields employed by PKINIT.
476 3.2.1. Generation of Client Request
478 The initial authentication request (AS-REQ) is sent as per [RFC4120];
479 in addition, a pre-authentication data element, whose padata-type is
480 PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
481 type PA-PK-AS-REQ, is included.
483 PA-PK-AS-REQ ::= SEQUENCE {
484 signedAuthPack [0] IMPLICIT OCTET STRING,
485 -- Contains a CMS type ContentInfo encoded
486 -- according to [RFC3852].
487 -- The contentType field of the type ContentInfo
488 -- is id-signedData (1.2.840.113549.1.7.2),
489 -- and the content field is a SignedData.
490 -- The eContentType field for the type SignedData is
491 -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
492 -- eContent field contains the DER encoding of the
493 -- type AuthPack.
494 -- AuthPack is defined below.
495 trustedCertifiers [1] SEQUENCE OF
496 ExternalPrincipalIdentifier OPTIONAL,
497 -- Contains a list of CAs, trusted by the client,
498 -- that can be used to certify the KDC.
499 -- Each ExternalPrincipalIdentifier identifies a CA
500 -- or a CA certificate (thereby its public key).
501 -- The information contained in the
502 -- trustedCertifiers SHOULD be used by the KDC as
506 Zhu & Tung Standards Track [Page 9]
507 \f
508 RFC 4556 PKINIT June 2006
511 -- hints to guide its selection of an appropriate
512 -- certificate chain to return to the client.
513 kdcPkId [2] IMPLICIT OCTET STRING
514 OPTIONAL,
515 -- Contains a CMS type SignerIdentifier encoded
516 -- according to [RFC3852].
517 -- Identifies, if present, a particular KDC
518 -- public key that the client already has.
519 ...
520 }
522 DHNonce ::= OCTET STRING
524 ExternalPrincipalIdentifier ::= SEQUENCE {
525 subjectName [0] IMPLICIT OCTET STRING OPTIONAL,
526 -- Contains a PKIX type Name encoded according to
527 -- [RFC3280].
528 -- Identifies the certificate subject by the
529 -- distinguished subject name.
530 -- REQUIRED when there is a distinguished subject
531 -- name present in the certificate.
532 issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL,
533 -- Contains a CMS type IssuerAndSerialNumber encoded
534 -- according to [RFC3852].
535 -- Identifies a certificate of the subject.
536 -- REQUIRED for TD-INVALID-CERTIFICATES and
537 -- TD-TRUSTED-CERTIFIERS.
538 subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL,
539 -- Identifies the subject's public key by a key
540 -- identifier. When an X.509 certificate is
541 -- referenced, this key identifier matches the X.509
542 -- subjectKeyIdentifier extension value. When other
543 -- certificate formats are referenced, the documents
544 -- that specify the certificate format and their use
545 -- with the CMS must include details on matching the
546 -- key identifier to the appropriate certificate
547 -- field.
548 -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
549 ...
550 }
552 AuthPack ::= SEQUENCE {
553 pkAuthenticator [0] PKAuthenticator,
554 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
555 -- Type SubjectPublicKeyInfo is defined in
556 -- [RFC3280].
557 -- Specifies Diffie-Hellman domain parameters
558 -- and the client's public key value [IEEE1363].
562 Zhu & Tung Standards Track [Page 10]
563 \f
564 RFC 4556 PKINIT June 2006
567 -- The DH public key value is encoded as a BIT
568 -- STRING according to [RFC3279].
569 -- This field is present only if the client wishes
570 -- to use the Diffie-Hellman key agreement method.
571 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
572 OPTIONAL,
573 -- Type AlgorithmIdentifier is defined in
574 -- [RFC3280].
575 -- List of CMS algorithm [RFC3370] identifiers
576 -- that identify key transport algorithms, or
577 -- content encryption algorithms, or signature
578 -- algorithms supported by the client in order of
579 -- (decreasing) preference.
580 clientDHNonce [3] DHNonce OPTIONAL,
581 -- Present only if the client indicates that it
582 -- wishes to reuse DH keys or to allow the KDC to
583 -- do so (see Section 3.2.3.1).
584 ...
585 }
587 PKAuthenticator ::= SEQUENCE {
588 cusec [0] INTEGER (0..999999),
589 ctime [1] KerberosTime,
590 -- cusec and ctime are used as in [RFC4120], for
591 -- replay prevention.
592 nonce [2] INTEGER (0..4294967295),
593 -- Chosen randomly; this nonce does not need to
594 -- match with the nonce in the KDC-REQ-BODY.
595 paChecksum [3] OCTET STRING OPTIONAL,
596 -- MUST be present.
597 -- Contains the SHA1 checksum, performed over
598 -- KDC-REQ-BODY.
599 ...
600 }
602 The ContentInfo [RFC3852] structure contained in the signedAuthPack
603 field of the type PA-PK-AS-REQ is encoded according to [RFC3852] and
604 is filled out as follows:
606 1. The contentType field of the type ContentInfo is id-signedData
607 (as defined in [RFC3852]), and the content field is a SignedData
608 (as defined in [RFC3852]).
618 Zhu & Tung Standards Track [Page 11]
619 \f
620 RFC 4556 PKINIT June 2006
623 2. The eContentType field for the type SignedData is id-pkinit-
624 authData: { iso(1) org(3) dod(6) internet(1) security(5)
625 kerberosv5(2) pkinit(3) authData(1) }. Notes to CMS
626 implementers: the signed attribute content-type MUST be present
627 in this SignedData instance, and its value is id-pkinit-authData
628 according to [RFC3852].
630 3. The eContent field for the type SignedData contains the DER
631 encoding of the type AuthPack.
633 4. The signerInfos field of the type SignedData contains a single
634 signerInfo, which contains the signature over the type AuthPack.
636 5. The AuthPack structure contains a PKAuthenticator, the client
637 public key information, the CMS encryption types supported by the
638 client, and a DHNonce. The pkAuthenticator field certifies to
639 the KDC that the client has recent knowledge of the signing key
640 that authenticates the client. The clientPublicValue field
641 specifies Diffie-Hellman domain parameters and the client's
642 public key value. The DH public key value is encoded as a BIT
643 STRING according to [RFC3279]. The clientPublicValue field is
644 present only if the client wishes to use the Diffie-Hellman key
645 agreement method. The supportedCMSTypes field specifies the list
646 of CMS algorithm identifiers that are supported by the client in
647 order of (decreasing) preference, and can be used to identify a
648 signature algorithm or a key transport algorithm [RFC3370] in the
649 keyEncryptionAlgorithm field of the type KeyTransRecipientInfo,
650 or a content encryption algorithm [RFC3370] in the
651 contentEncryptionAlgorithm field of the type EncryptedContentInfo
652 [RFC3852] when encrypting the AS reply key as described in
653 Section 3.2.3.2. However, there is no significance in the
654 relative order between any two of different types of algorithms:
655 key transport algorithms, content encryption algorithms, and
656 signature algorithms. The clientDHNonce field is described later
657 in this section.
659 6. The ctime field in the PKAuthenticator structure contains the
660 current time on the client's host, and the cusec field contains
661 the microsecond part of the client's timestamp. The ctime and
662 cusec fields are used together to specify a reasonably accurate
663 timestamp [RFC4120]. The nonce field is chosen randomly. The
664 paChecksum field MUST be present and it contains a SHA1 checksum
665 that is performed over the KDC-REQ-BODY [RFC4120]. In order to
666 ease future migration from the use of SHA1, the paChecksum field
667 is made optional syntactically: when the request is extended to
668 negotiate hash algorithms, the new client wishing not to use SHA1
669 will send the request in the extended message syntax without the
670 paChecksum field. The KDC conforming to this specification MUST
674 Zhu & Tung Standards Track [Page 12]
675 \f
676 RFC 4556 PKINIT June 2006
679 return a KRB-ERROR [RFC4120] message with the code
680 KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED (see Section 3.2.3). That
681 will allow a new client to retry with SHA1 if allowed by the
682 local policy.
684 7. The certificates field of the type SignedData contains
685 certificates intended to facilitate certification path
686 construction, so that the KDC can verify the signature over the
687 type AuthPack. For path validation, these certificates SHOULD be
688 sufficient to construct at least one certification path from the
689 client certificate to one trust anchor acceptable by the KDC
690 [RFC4158]. The client MUST be capable of including such a set of
691 certificates if configured to do so. The certificates field MUST
692 NOT contain "root" CA certificates.
694 8. The client's Diffie-Hellman public value (clientPublicValue) is
695 included if and only if the client wishes to use the Diffie-
696 Hellman key agreement method. The Diffie-Hellman domain
697 parameters [IEEE1363] for the client's public key are specified
698 in the algorithm field of the type SubjectPublicKeyInfo
699 [RFC3279], and the client's Diffie-Hellman public key value is
700 mapped to a subjectPublicKey (a BIT STRING) according to
701 [RFC3279]. When using the Diffie-Hellman key agreement method,
702 implementations MUST support Oakley 1024-bit Modular Exponential
703 (MODP) well-known group 2 [RFC2412] and Oakley 2048-bit MODP
704 well-known group 14 [RFC3526] and SHOULD support Oakley 4096-bit
705 MODP well-known group 16 [RFC3526].
707 The Diffie-Hellman field size should be chosen so as to provide
708 sufficient cryptographic security [RFC3766].
710 When MODP Diffie-Hellman is used, the exponents should have at
711 least twice as many bits as the symmetric keys that will be
712 derived from them [ODL99].
714 9. The client may wish to reuse DH keys or to allow the KDC to do so
715 (see Section 3.2.3.1). If so, then the client includes the
716 clientDHNonce field. This nonce string MUST be as long as the
717 longest key length of the symmetric key types that the client
718 supports. This nonce MUST be chosen randomly.
720 The ExternalPrincipalIdentifier structure is used in this document to
721 identify the subject's public key thereby the subject principal.
722 This structure is filled out as follows:
724 1. The subjectName field contains a PKIX type Name encoded according
725 to [RFC3280]. This field identifies the certificate subject by
726 the distinguished subject name. This field is REQUIRED when
730 Zhu & Tung Standards Track [Page 13]
731 \f
732 RFC 4556 PKINIT June 2006
735 there is a distinguished subject name present in the certificate
736 being used.
738 2. The issuerAndSerialNumber field contains a CMS type
739 IssuerAndSerialNumber encoded according to [RFC3852]. This field
740 identifies a certificate of the subject. This field is REQUIRED
741 for TD-INVALID-CERTIFICATES and TD-TRUSTED-CERTIFIERS (both
742 structures are defined in Section 3.2.2).
744 3. The subjectKeyIdentifier [RFC3852] field identifies the subject's
745 public key by a key identifier. When an X.509 certificate is
746 referenced, this key identifier matches the X.509
747 subjectKeyIdentifier extension value. When other certificate
748 formats are referenced, the documents that specify the
749 certificate format and their use with the CMS must include
750 details on matching the key identifier to the appropriate
751 certificate field. This field is RECOMMENDED for TD-TRUSTED-
752 CERTIFIERS (as defined in Section 3.2.2).
754 The trustedCertifiers field of the type PA-PK-AS-REQ contains a list
755 of CAs, trusted by the client, that can be used to certify the KDC.
756 Each ExternalPrincipalIdentifier identifies a CA or a CA certificate
757 (thereby its public key).
759 The kdcPkId field of the type PA-PK-AS-REQ contains a CMS type
760 SignerIdentifier encoded according to [RFC3852]. This field
761 identifies, if present, a particular KDC public key that the client
762 already has.
764 3.2.2. Receipt of Client Request
766 Upon receiving the client's request, the KDC validates it. This
767 section describes the steps that the KDC MUST (unless otherwise
768 noted) take in validating the request.
770 The KDC verifies the client's signature in the signedAuthPack field
771 according to [RFC3852].
773 If, while validating the client's X.509 certificate [RFC3280], the
774 KDC cannot build a certification path to validate the client's
775 certificate, it sends back a KRB-ERROR [RFC4120] message with the
776 code KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for
777 this error message is a TYPED-DATA (as defined in [RFC4120]) that
778 contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and
779 whose data-value contains the DER encoding of the type TD-TRUSTED-
780 CERTIFIERS:
786 Zhu & Tung Standards Track [Page 14]
787 \f
788 RFC 4556 PKINIT June 2006
791 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
792 ExternalPrincipalIdentifier
793 -- Identifies a list of CAs trusted by the KDC.
794 -- Each ExternalPrincipalIdentifier identifies a CA
795 -- or a CA certificate (thereby its public key).
797 Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
798 TD-TRUSTED-CERTIFIERS structure identifies a CA or a CA certificate
799 (thereby its public key) trusted by the KDC.
801 Upon receiving this error message, the client SHOULD retry only if it
802 has a different set of certificates (from those of the previous
803 requests) that form a certification path (or a partial path) from one
804 of the trust anchors acceptable by the KDC to its own certificate.
806 If, while processing the certification path, the KDC determines that
807 the signature on one of the certificates in the signedAuthPack field
808 is invalid, it returns a KRB-ERROR [RFC4120] message with the code
809 KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data for this error
810 message is a TYPED-DATA that contains an element whose data-type is
811 TD_INVALID_CERTIFICATES, and whose data-value contains the DER
812 encoding of the type TD-INVALID-CERTIFICATES:
814 TD-INVALID-CERTIFICATES ::= SEQUENCE OF
815 ExternalPrincipalIdentifier
816 -- Each ExternalPrincipalIdentifier identifies a
817 -- certificate (sent by the client) with an invalid
818 -- signature.
820 Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
821 TD-INVALID-CERTIFICATES structure identifies a certificate (that was
822 sent by the client) with an invalid signature.
824 If more than one X.509 certificate signature is invalid, the KDC MAY
825 include one IssuerAndSerialNumber per invalid signature within the
826 TD-INVALID-CERTIFICATES.
828 The client's X.509 certificate is validated according to [RFC3280].
830 Depending on local policy, the KDC may also check whether any X.509
831 certificates in the certification path validating the client's
832 certificate have been revoked. If any of them have been revoked, the
833 KDC MUST return an error message with the code
834 KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
835 revocation status but is unable to do so, it SHOULD return an error
836 message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN. The
837 certificate or certificates affected are identified exactly as for
838 the error code KDC_ERR_INVALID_CERTIFICATE (see above).
842 Zhu & Tung Standards Track [Page 15]
843 \f
844 RFC 4556 PKINIT June 2006
847 Note that the TD_INVALID_CERTIFICATES error data is only used to
848 identify invalid certificates sent by the client in the request.
850 The client's public key is then used to verify the signature. If the
851 signature fails to verify, the KDC MUST return an error message with
852 the code KDC_ERR_INVALID_SIG. There is no accompanying e-data for
853 this error message.
855 In addition to validating the client's signature, the KDC MUST also
856 check that the client's public key used to verify the client's
857 signature is bound to the client principal name specified in the AS-
858 REQ as follows:
860 1. If the KDC has its own binding between either the client's
861 signature-verification public key or the client's certificate and
862 the client's Kerberos principal name, it uses that binding.
864 2. Otherwise, if the client's X.509 certificate contains a Subject
865 Alternative Name (SAN) extension carrying a KRB5PrincipalName
866 (defined below) in the otherName field of the type GeneralName
867 [RFC3280], it binds the client's X.509 certificate to that name.
869 The type of the otherName field is AnotherName. The type-id field
870 of the type AnotherName is id-pkinit-san:
872 id-pkinit-san OBJECT IDENTIFIER ::=
873 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
874 x509SanAN (2) }
876 And the value field of the type AnotherName is a
877 KRB5PrincipalName.
879 KRB5PrincipalName ::= SEQUENCE {
880 realm [0] Realm,
881 principalName [1] PrincipalName
882 }
884 If the Kerberos client name in the AS-REQ does not match a name bound
885 by the KDC (the binding can be in the certificate, for example, as
886 described above), or if there is no binding found by the KDC, the KDC
887 MUST return an error message with the code
888 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for
889 this error message.
891 Even if the certification path is validated and the certificate is
892 mapped to the client's principal name, the KDC may decide not to
893 accept the client's certificate, depending on local policy.
898 Zhu & Tung Standards Track [Page 16]
899 \f
900 RFC 4556 PKINIT June 2006
903 The KDC MAY require the presence of an Extended Key Usage (EKU)
904 KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field
905 of the client's X.509 certificate:
907 id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
908 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
909 pkinit(3) keyPurposeClientAuth(4) }
910 -- PKINIT client authentication.
911 -- Key usage bits that MUST be consistent:
912 -- digitalSignature.
914 The digitalSignature key usage bit [RFC3280] MUST be asserted when
915 the intended purpose of the client's X.509 certificate is restricted
916 with the id-pkinit-KPClientAuth EKU.
918 If this EKU KeyPurposeId is required but it is not present, or if the
919 client certificate is restricted not to be used for PKINIT client
920 authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
921 an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE. There
922 is no accompanying e-data for this error message. KDCs implementing
923 this requirement SHOULD also accept the EKU KeyPurposeId
924 id-ms-kp-sc-logon (1.3.6.1.4.1.311.20.2.2) as meeting the
925 requirement, as there are a large number of X.509 client certificates
926 deployed for use with PKINIT that have this EKU.
928 As a matter of local policy, the KDC MAY decide to reject requests on
929 the basis of the absence or presence of other specific EKU OIDs.
931 If the digest algorithm used in generating the CA signature for the
932 public key in any certificate of the request is not acceptable by the
933 KDC, the KDC MUST return a KRB-ERROR [RFC4120] message with the code
934 KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED. The accompanying e-data MUST be
935 encoded in TYPED-DATA, although none is defined at this point.
937 If the client's public key is not accepted with reasons other than
938 those specified above, the KDC returns a KRB-ERROR [RFC4120] message
939 with the code KDC_ERR_CLIENT_NOT_TRUSTED. There is no accompanying
940 e-data currently defined for this error message.
942 The KDC MUST check the timestamp to ensure that the request is not a
943 replay, and that the time skew falls within acceptable limits. The
944 recommendations for clock skew times in [RFC4120] apply here. If the
945 check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
946 KRB_AP_ERR_SKEW, respectively.
948 If the clientPublicValue is filled in, indicating that the client
949 wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
950 check to see if the key parameters satisfy its policy. If they do
954 Zhu & Tung Standards Track [Page 17]
955 \f
956 RFC 4556 PKINIT June 2006
959 not, it MUST return an error message with the code
960 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The accompanying e-data is a
961 TYPED-DATA that contains an element whose data-type is
962 TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
963 the type TD-DH-PARAMETERS:
965 TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
966 -- Each AlgorithmIdentifier specifies a set of
967 -- Diffie-Hellman domain parameters [IEEE1363].
968 -- This list is in decreasing preference order.
970 TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
971 that the KDC supports in decreasing preference order, from which the
972 client SHOULD pick one to retry the request.
974 The AlgorithmIdentifier structure is defined in [RFC3280] and is
975 filled in according to [RFC3279]. More specifically, Section 2.3.3
976 of [RFC3279] describes how to fill in the AlgorithmIdentifier
977 structure in the case where MODP Diffie-Hellman key exchange is used.
979 If the client included a kdcPkId field in the PA-PK-AS-REQ and the
980 KDC does not possess the corresponding key, the KDC MUST ignore the
981 kdcPkId field as if the client did not include one.
983 If the digest algorithm used by the id-pkinit-authData is not
984 acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120]
985 message with the code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED.
986 The accompanying e-data MUST be encoded in TYPED-DATA, although none
987 is defined at this point.
989 3.2.3. Generation of KDC Reply
991 If the paChecksum filed in the request is not present, the KDC
992 conforming to this specification MUST return a KRB-ERROR [RFC4120]
993 message with the code KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED. The
994 accompanying e-data MUST be encoded in TYPED-DATA (no error data is
995 defined by this specification).
997 Assuming that the client's request has been properly validated, the
998 KDC proceeds as per [RFC4120], except as follows.
1000 The KDC MUST set the initial flag and include an authorization data
1001 element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued
1002 ticket. The ad-data [RFC4120] field contains the DER encoding of the
1003 type AD-INITIAL-VERIFIED-CAS:
1010 Zhu & Tung Standards Track [Page 18]
1011 \f
1012 RFC 4556 PKINIT June 2006
1015 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
1016 ExternalPrincipalIdentifier
1017 -- Identifies the certification path with which
1018 -- the client certificate was validated.
1019 -- Each ExternalPrincipalIdentifier identifies a CA
1020 -- or a CA certificate (thereby its public key).
1022 The AD-INITIAL-VERIFIED-CAS structure identifies the certification
1023 path with which the client certificate was validated. Each
1024 ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the AD-
1025 INITIAL-VERIFIED-CAS structure identifies a CA or a CA certificate
1026 (thereby its public key).
1028 Note that the syntax for the AD-INITIAL-VERIFIED-CAS authorization
1029 data does permit empty SEQUENCEs to be encoded. Such empty sequences
1030 may only be used if the KDC itself vouches for the user's
1031 certificate.
1033 The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
1034 containers if the list of CAs satisfies the AS' realm's local policy
1035 (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
1036 [RFC4120]). Furthermore, any TGS MUST copy such authorization data
1037 from tickets used within a PA-TGS-REQ of the TGS-REQ into the
1038 resulting ticket. If the list of CAs satisfies the local KDC's
1039 realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT
1040 container; otherwise, it MAY unwrap the authorization data out of the
1041 AD-IF-RELEVANT container.
1043 Application servers that understand this authorization data type
1044 SHOULD apply local policy to determine whether a given ticket bearing
1045 such a type *not* contained within an AD-IF-RELEVANT container is
1046 acceptable. (This corresponds to the AP server's checking the
1047 transited field when the TRANSITED-POLICY-CHECKED flag has not been
1048 set [RFC4120].) If such a data type is contained within an AD-IF-
1049 RELEVANT container, AP servers MAY apply local policy to determine
1050 whether the authorization data is acceptable.
1052 A pre-authentication data element, whose padata-type is PA_PK_AS_REP
1053 and whose padata-value contains the DER encoding of the type PA-PK-
1054 AS-REP (defined below), is included in the AS-REP [RFC4120].
1056 PA-PK-AS-REP ::= CHOICE {
1057 dhInfo [0] DHRepInfo,
1058 -- Selected when Diffie-Hellman key exchange is
1059 -- used.
1060 encKeyPack [1] IMPLICIT OCTET STRING,
1061 -- Selected when public key encryption is used.
1062 -- Contains a CMS type ContentInfo encoded
1066 Zhu & Tung Standards Track [Page 19]
1067 \f
1068 RFC 4556 PKINIT June 2006
1071 -- according to [RFC3852].
1072 -- The contentType field of the type ContentInfo is
1073 -- id-envelopedData (1.2.840.113549.1.7.3).
1074 -- The content field is an EnvelopedData.
1075 -- The contentType field for the type EnvelopedData
1076 -- is id-signedData (1.2.840.113549.1.7.2).
1077 -- The eContentType field for the inner type
1078 -- SignedData (when unencrypted) is
1079 -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
1080 -- eContent field contains the DER encoding of the
1081 -- type ReplyKeyPack.
1082 -- ReplyKeyPack is defined in Section 3.2.3.2.
1083 ...
1084 }
1086 DHRepInfo ::= SEQUENCE {
1087 dhSignedData [0] IMPLICIT OCTET STRING,
1088 -- Contains a CMS type ContentInfo encoded according
1089 -- to [RFC3852].
1090 -- The contentType field of the type ContentInfo is
1091 -- id-signedData (1.2.840.113549.1.7.2), and the
1092 -- content field is a SignedData.
1093 -- The eContentType field for the type SignedData is
1094 -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
1095 -- eContent field contains the DER encoding of the
1096 -- type KDCDHKeyInfo.
1097 -- KDCDHKeyInfo is defined below.
1098 serverDHNonce [1] DHNonce OPTIONAL,
1099 -- Present if and only if dhKeyExpiration is
1100 -- present in the KDCDHKeyInfo.
1101 ...
1102 }
1104 KDCDHKeyInfo ::= SEQUENCE {
1105 subjectPublicKey [0] BIT STRING,
1106 -- The KDC's DH public key.
1107 -- The DH public key value is encoded as a BIT
1108 -- STRING according to [RFC3279].
1109 nonce [1] INTEGER (0..4294967295),
1110 -- Contains the nonce in the pkAuthenticator field
1111 -- in the request if the DH keys are NOT reused,
1112 -- 0 otherwise.
1113 dhKeyExpiration [2] KerberosTime OPTIONAL,
1114 -- Expiration time for KDC's key pair,
1115 -- present if and only if the DH keys are reused.
1116 -- If present, the KDC's DH public key MUST not be
1117 -- used past the point of this expiration time.
1118 -- If this field is omitted then the serverDHNonce
1122 Zhu & Tung Standards Track [Page 20]
1123 \f
1124 RFC 4556 PKINIT June 2006
1127 -- field MUST also be omitted.
1128 ...
1129 }
1131 The content of the AS-REP is otherwise unchanged from [RFC4120]. The
1132 KDC encrypts the reply as usual, but not with the client's long-term
1133 key. Instead, it encrypts it with either a shared key derived from a
1134 Diffie-Hellman exchange or a generated encryption key. The contents
1135 of the PA-PK-AS-REP indicate which key delivery method is used.
1137 If the client does not wish to use the Diffie-Hellman key delivery
1138 method (the clientPublicValue field is not present in the request)
1139 and the KDC does not support the public key encryption key delivery
1140 method, the KDC MUST return an error message with the code
1141 KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED. There is no
1142 accompanying e-data for this error message.
1144 In addition, the lifetime of the ticket returned by the KDC MUST NOT
1145 exceed that of the client's public-private key pair. The ticket
1146 lifetime, however, can be shorter than that of the client's public-
1147 private key pair. For the implementations of this specification, the
1148 lifetime of the client's public-private key pair is the validity
1149 period in X.509 certificates [RFC3280], unless configured otherwise.
1151 3.2.3.1. Using Diffie-Hellman Key Exchange
1153 In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
1155 The ContentInfo [RFC3852] structure for the dhSignedData field is
1156 filled in as follows:
1158 1. The contentType field of the type ContentInfo is id-signedData
1159 (as defined in [RFC3852]), and the content field is a SignedData
1160 (as defined in [RFC3852]).
1162 2. The eContentType field for the type SignedData is the OID value
1163 for id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1)
1164 security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }. Notes to CMS
1165 implementers: the signed attribute content-type MUST be present
1166 in this SignedData instance, and its value is id-pkinit-DHKeyData
1167 according to [RFC3852].
1169 3. The eContent field for the type SignedData contains the DER
1170 encoding of the type KDCDHKeyInfo.
1172 4. The KDCDHKeyInfo structure contains the KDC's public key, a
1173 nonce, and, optionally, the expiration time of the KDC's DH key
1174 being reused. The subjectPublicKey field of the type
1178 Zhu & Tung Standards Track [Page 21]
1179 \f
1180 RFC 4556 PKINIT June 2006
1183 KDCDHKeyInfo field identifies KDC's DH public key. This DH
1184 public key value is encoded as a BIT STRING according to
1185 [RFC3279]. The nonce field contains the nonce in the
1186 pkAuthenticator field in the request if the DH keys are NOT
1187 reused. The value of this nonce field is 0 if the DH keys are
1188 reused. The dhKeyExpiration field is present if and only if the
1189 DH keys are reused. If the dhKeyExpiration field is present, the
1190 KDC's public key in this KDCDHKeyInfo structure MUST NOT be used
1191 past the point of this expiration time. If this field is
1192 omitted, then the serverDHNonce field MUST also be omitted.
1194 5. The signerInfos field of the type SignedData contains a single
1195 signerInfo, which contains the signature over the type
1196 KDCDHKeyInfo.
1198 6. The certificates field of the type SignedData contains
1199 certificates intended to facilitate certification path
1200 construction, so that the client can verify the KDC's signature
1201 over the type KDCDHKeyInfo. The information contained in the
1202 trustedCertifiers in the request SHOULD be used by the KDC as
1203 hints to guide its selection of an appropriate certificate chain
1204 to return to the client. This field may be left empty if the KDC
1205 public key specified by the kdcPkId field in the PA-PK-AS-REQ was
1206 used for signing. Otherwise, for path validation, these
1207 certificates SHOULD be sufficient to construct at least one
1208 certification path from the KDC certificate to one trust anchor
1209 acceptable by the client [RFC4158]. The KDC MUST be capable of
1210 including such a set of certificates if configured to do so. The
1211 certificates field MUST NOT contain "root" CA certificates.
1213 7. If the client included the clientDHNonce field, then the KDC may
1214 choose to reuse its DH keys. If the server reuses DH keys, then
1215 it MUST include an expiration time in the dhKeyExpiration field.
1216 Past the point of the expiration time, the signature over the
1217 type DHRepInfo is considered expired/invalid. When the server
1218 reuses DH keys then, it MUST include a serverDHNonce at least as
1219 long as the length of keys for the symmetric encryption system
1220 used to encrypt the AS reply. Note that including the
1221 serverDHNonce changes how the client and server calculate the key
1222 to use to encrypt the reply; see below for details. The KDC
1223 SHOULD NOT reuse DH keys unless the clientDHNonce field is
1224 present in the request.
1226 The AS reply key is derived as follows:
1228 1. Both the KDC and the client calculate the shared secret value as
1229 follows:
1234 Zhu & Tung Standards Track [Page 22]
1235 \f
1236 RFC 4556 PKINIT June 2006
1239 a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
1240 shared secret value. DHSharedSecret is the value ZZ, as
1241 described in Section 2.1.1 of [RFC2631].
1243 DHSharedSecret is first padded with leading zeros such that the
1244 size of DHSharedSecret in octets is the same as that of the
1245 modulus, then represented as a string of octets in big-endian
1246 order.
1248 Implementation note: Both the client and the KDC can cache the
1249 triple (ya, yb, DHSharedSecret), where ya is the client's public
1250 key and yb is the KDC's public key. If both ya and yb are the
1251 same in a later exchange, the cached DHSharedSecret can be used.
1253 2. Let K be the key-generation seed length [RFC3961] of the AS reply
1254 key whose enctype is selected according to [RFC4120].
1256 3. Define the function octetstring2key() as follows:
1258 octetstring2key(x) == random-to-key(K-truncate(
1259 SHA1(0x00 | x) |
1260 SHA1(0x01 | x) |
1261 SHA1(0x02 | x) |
1262 ...
1263 ))
1265 where x is an octet string; | is the concatenation operator; 0x00,
1266 0x01, 0x02, etc. are each represented as a single octet; random-
1267 to-key() is an operation that generates a protocol key from a
1268 bitstring of length K; and K-truncate truncates its input to the
1269 first K bits. Both K and random-to-key() are as defined in the
1270 kcrypto profile [RFC3961] for the enctype of the AS reply key.
1272 4. When DH keys are reused, let n_c be the clientDHNonce and n_k be
1273 the serverDHNonce; otherwise, let both n_c and n_k be empty octet
1274 strings.
1276 5. The AS reply key k is:
1277 k = octetstring2key(DHSharedSecret | n_c | n_k)
1279 3.2.3.2. Using Public Key Encryption
1281 In this case, the PA-PK-AS-REP contains the encKeyPack field where
1282 the AS reply key is encrypted.
1284 The ContentInfo [RFC3852] structure for the encKeyPack field is
1285 filled in as follows:
1290 Zhu & Tung Standards Track [Page 23]
1291 \f
1292 RFC 4556 PKINIT June 2006
1295 1. The contentType field of the type ContentInfo is id-envelopedData
1296 (as defined in [RFC3852]), and the content field is an
1297 EnvelopedData (as defined in [RFC3852]).
1299 2. The contentType field for the type EnvelopedData is id-
1300 signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
1301 pkcs (1) pkcs7 (7) signedData (2) }.
1303 3. The eContentType field for the inner type SignedData (when
1304 decrypted from the encryptedContent field for the type
1305 EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6)
1306 internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }.
1307 Notes to CMS implementers: the signed attribute content-type MUST
1308 be present in this SignedData instance, and its value is id-
1309 pkinit-rkeyData according to [RFC3852].
1311 4. The eContent field for the inner type SignedData contains the DER
1312 encoding of the type ReplyKeyPack (as described below).
1314 5. The signerInfos field of the inner type SignedData contains a
1315 single signerInfo, which contains the signature for the type
1316 ReplyKeyPack.
1318 6. The certificates field of the inner type SignedData contains
1319 certificates intended to facilitate certification path
1320 construction, so that the client can verify the KDC's signature
1321 for the type ReplyKeyPack. The information contained in the
1322 trustedCertifiers in the request SHOULD be used by the KDC as
1323 hints to guide its selection of an appropriate certificate chain
1324 to return to the client. This field may be left empty if the KDC
1325 public key specified by the kdcPkId field in the PA-PK-AS-REQ was
1326 used for signing. Otherwise, for path validation, these
1327 certificates SHOULD be sufficient to construct at least one
1328 certification path from the KDC certificate to one trust anchor
1329 acceptable by the client [RFC4158]. The KDC MUST be capable of
1330 including such a set of certificates if configured to do so. The
1331 certificates field MUST NOT contain "root" CA certificates.
1333 7. The recipientInfos field of the type EnvelopedData is a SET that
1334 MUST contain exactly one member of type KeyTransRecipientInfo.
1335 The encryptedKey of this member contains the temporary key that
1336 is encrypted using the client's public key.
1338 8. The unprotectedAttrs or originatorInfo fields of the type
1339 EnvelopedData MAY be present.
1346 Zhu & Tung Standards Track [Page 24]
1347 \f
1348 RFC 4556 PKINIT June 2006
1351 If there is a supportedCMSTypes field in the AuthPack, the KDC must
1352 check to see if it supports any of the listed types. If it supports
1353 more than one of the types, the KDC SHOULD use the one listed first.
1354 If it does not support any of them, it MUST return an error message
1355 with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].
1357 Furthermore, the KDC computes the checksum of the AS-REQ in the
1358 client request. This checksum is performed over the type AS-REQ, and
1359 the protocol key [RFC3961] of the checksum operation is the replyKey,
1360 and the key usage number is 6. If the replyKey's enctype is "newer"
1361 [RFC4120] [RFC4121], the checksum operation is the required checksum
1362 operation [RFC3961] of that enctype.
1364 ReplyKeyPack ::= SEQUENCE {
1365 replyKey [0] EncryptionKey,
1366 -- Contains the session key used to encrypt the
1367 -- enc-part field in the AS-REP, i.e., the
1368 -- AS reply key.
1369 asChecksum [1] Checksum,
1370 -- Contains the checksum of the AS-REQ
1371 -- corresponding to the containing AS-REP.
1372 -- The checksum is performed over the type AS-REQ.
1373 -- The protocol key [RFC3961] of the checksum is the
1374 -- replyKey and the key usage number is 6.
1375 -- If the replyKey's enctype is "newer" [RFC4120]
1376 -- [RFC4121], the checksum is the required
1377 -- checksum operation [RFC3961] for that enctype.
1378 -- The client MUST verify this checksum upon receipt
1379 -- of the AS-REP.
1380 ...
1381 }
1383 Implementations of this RSA encryption key delivery method are
1384 RECOMMENDED to support RSA keys at least 2048 bits in size.
1386 3.2.4. Receipt of KDC Reply
1388 Upon receipt of the KDC's reply, the client proceeds as follows. If
1389 the PA-PK-AS-REP contains the dhSignedData field, the client derives
1390 the AS reply key using the same procedure used by the KDC, as defined
1391 in Section 3.2.3.1. Otherwise, the message contains the encKeyPack
1392 field, and the client decrypts and extracts the temporary key in the
1393 encryptedKey field of the member KeyTransRecipientInfo and then uses
1394 that as the AS reply key.
1396 If the public key encryption method is used, the client MUST verify
1397 the asChecksum contained in the ReplyKeyPack.
1402 Zhu & Tung Standards Track [Page 25]
1403 \f
1404 RFC 4556 PKINIT June 2006
1407 In either case, the client MUST verify the signature in the
1408 SignedData according to [RFC3852]. The KDC's X.509 certificate MUST
1409 be validated according to [RFC3280]. In addition, unless the client
1410 can otherwise verify that the public key used to verify the KDC's
1411 signature is bound to the KDC of the target realm, the KDC's X.509
1412 certificate MUST contain a Subject Alternative Name extension
1413 [RFC3280] carrying an AnotherName whose type-id is id-pkinit-san (as
1414 defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
1415 matches the name of the TGS of the target realm (as defined in
1416 Section 7.3 of [RFC4120]).
1418 Unless the client knows by some other means that the KDC certificate
1419 is intended for a Kerberos KDC, the client MUST require that the KDC
1420 certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc:
1422 id-pkinit-KPKdc OBJECT IDENTIFIER ::=
1423 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
1424 pkinit(3) keyPurposeKdc(5) }
1425 -- Signing KDC responses.
1426 -- Key usage bits that MUST be consistent:
1427 -- digitalSignature.
1429 The digitalSignature key usage bit [RFC3280] MUST be asserted when
1430 the intended purpose of the KDC's X.509 certificate is restricted
1431 with the id-pkinit-KPKdc EKU.
1433 If the KDC certificate contains the Kerberos TGS name encoded as an
1434 id-pkinit-san SAN, this certificate is certified by the issuing CA as
1435 a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required.
1437 If all applicable checks are satisfied, the client then decrypts the
1438 enc-part field of the KDC-REP in the AS-REP, using the AS reply key,
1439 and then proceeds as described in [RFC4120].
1441 3.3. Interoperability Requirements
1443 The client MUST be capable of sending a set of certificates
1444 sufficient to allow the KDC to construct a certification path for the
1445 client's certificate, if the correct set of certificates is provided
1446 through configuration or policy.
1448 If the client sends all the X.509 certificates on a certification
1449 path to a trust anchor acceptable by the KDC, and if the KDC cannot
1450 verify the client's public key otherwise, the KDC MUST be able to
1451 process path validation for the client's certificate based on the
1452 certificates in the request.
1458 Zhu & Tung Standards Track [Page 26]
1459 \f
1460 RFC 4556 PKINIT June 2006
1463 The KDC MUST be capable of sending a set of certificates sufficient
1464 to allow the client to construct a certification path for the KDC's
1465 certificate, if the correct set of certificates is provided through
1466 configuration or policy.
1468 If the KDC sends all the X.509 certificates on a certification path
1469 to a trust anchor acceptable by the client, and the client can not
1470 verify the KDC's public key otherwise, the client MUST be able to
1471 process path validation for the KDC's certificate based on the
1472 certificates in the reply.
1474 3.4. KDC Indication of PKINIT Support
1476 If pre-authentication is required but was not present in the request,
1477 per [RFC4120] an error message with the code KDC_ERR_PREAUTH_FAILED
1478 is returned, and a METHOD-DATA object will be stored in the e-data
1479 field of the KRB-ERROR message to specify which pre-authentication
1480 mechanisms are acceptable. The KDC can then indicate the support of
1481 PKINIT by including an empty element whose padata-type is
1482 PA_PK_AS_REQ in that METHOD-DATA object.
1484 Otherwise if it is required by the KDC's local policy that the client
1485 must be pre-authenticated using the pre-authentication mechanism
1486 specified in this document, but no PKINIT pre-authentication was
1487 present in the request, an error message with the code
1488 KDC_ERR_PREAUTH_FAILED SHOULD be returned.
1490 KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
1491 the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
1492 STRING), and clients MUST ignore this and any other value. Future
1493 extensions to this protocol may specify other data to send instead of
1494 an empty OCTET STRING.
1496 4. Security Considerations
1498 The security of cryptographic algorithms is dependent on generating
1499 secret quantities [RFC4086]. The number of truly random bits is
1500 extremely important in determining the attack resistance strength of
1501 the cryptosystem; for example, the secret Diffie-Hellman exponents
1502 must be chosen based on n truly random bits (where n is the system
1503 security requirement). The security of the overall system is
1504 significantly weakened by using insufficient random inputs: a
1505 sophisticated attacker may find it easier to reproduce the
1506 environment that produced the secret quantities and to search the
1507 resulting small set of possibilities than to locate the quantities in
1508 the whole of the potential number space.
1514 Zhu & Tung Standards Track [Page 27]
1515 \f
1516 RFC 4556 PKINIT June 2006
1519 Kerberos error messages are not integrity protected; as a result, the
1520 domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered
1521 with by an attacker so that the set of domain parameters selected
1522 could be either weaker or not mutually preferred. Local policy can
1523 configure sets of domain parameters acceptable locally, or disallow
1524 the negotiation of DH domain parameters.
1526 The symmetric reply key size and Diffie-Hellman field size or RSA
1527 modulus size should be chosen so as to provide sufficient
1528 cryptographic security [RFC3766].
1530 When MODP Diffie-Hellman is used, the exponents should have at least
1531 twice as many bits as the symmetric keys that will be derived from
1532 them [ODL99].
1534 PKINIT raises certain security considerations beyond those that can
1535 be regulated strictly in protocol definitions. We will address them
1536 in this section.
1538 PKINIT extends the cross-realm model to the public-key
1539 infrastructure. Users of PKINIT must understand security policies
1540 and procedures appropriate to the use of Public Key Infrastructures
1541 [RFC3280].
1543 In order to trust a KDC certificate that is certified by a CA as a
1544 KDC certificate for a target realm (for example, by asserting the TGS
1545 name of that Kerberos realm as an id-pkinit-san SAN and/or
1546 restricting the certificate usage by using the id-pkinit-KPKdc EKU,
1547 as described in Section 3.2.4), the client MUST verify that the KDC
1548 certificate's issuing CA is authorized to issue KDC certificates for
1549 that target realm. Otherwise, the binding between the KDC
1550 certificate and the KDC of the target realm is not established.
1552 How to validate this authorization is a matter of local policy. A
1553 way to achieve this is the configuration of specific sets of
1554 intermediary CAs and trust anchors, one of which must be on the KDC
1555 certificate's certification path [RFC3280], and, for each CA or trust
1556 anchor, the realms for which it is allowed to issue certificates.
1558 In addition, if any CA that is trusted to issue KDC certificates can
1559 also issue other kinds of certificates, then local policy must be
1560 able to distinguish between them; for example, it could require that
1561 KDC certificates contain the id-pkinit-KPKdc EKU or that the realm be
1562 specified with the id-pkinit-san SAN.
1564 It is the responsibility of the PKI administrators for an
1565 organization to ensure that KDC certificates are only issued to KDCs,
1566 and that clients can ascertain this using their local policy.
1570 Zhu & Tung Standards Track [Page 28]
1571 \f
1572 RFC 4556 PKINIT June 2006
1575 Standard Kerberos allows the possibility of interactions between
1576 cryptosystems of varying strengths; this document adds interactions
1577 with public-key cryptosystems to Kerberos. Some administrative
1578 policies may allow the use of relatively weak public keys. When
1579 using such weak asymmetric keys to protect/exchange stronger
1580 symmetric Keys, the attack resistant strength of the overall system
1581 is no better than that of these weak keys [RFC3766].
1583 PKINIT requires that keys for symmetric cryptosystems be generated.
1584 Some such systems contain "weak" keys. For recommendations regarding
1585 these weak keys, see [RFC4120].
1587 PKINIT allows the use of the same RSA key pair for encryption and
1588 signing when doing RSA encryption-based key delivery. This is not
1589 recommended usage of RSA keys [RFC3447]; by using DH-based key
1590 delivery, this is avoided.
1592 Care should be taken in how certificates are chosen for the purposes
1593 of authentication using PKINIT. Some local policies may require that
1594 key escrow be used for certain certificate types. Deployers of
1595 PKINIT should be aware of the implications of using certificates that
1596 have escrowed keys for the purposes of authentication. Because
1597 signing-only certificates are normally not escrowed, by using DH-
1598 based key delivery this is avoided.
1600 PKINIT does not provide for a "return routability" test to prevent
1601 attackers from mounting a denial-of-service attack on the KDC by
1602 causing it to perform unnecessary and expensive public-key
1603 operations. Strictly speaking, this is also true of standard
1604 Kerberos, although the potential cost is not as great, because
1605 standard Kerberos does not make use of public-key cryptography. By
1606 using DH-based key delivery and reusing DH keys, the necessary crypto
1607 processing cost per request can be minimized.
1609 When the Diffie-Hellman key exchange method is used, additional pre-
1610 authentication data [RFC4120] (in addition to the PA_PK_AS_REQ, as
1611 defined in this specification) is not bound to the AS_REQ by the
1612 mechanisms discussed in this specification (meaning it may be dropped
1613 or added by attackers without being detected by either the client or
1614 the KDC). Designers of additional pre-authentication data should
1615 take that into consideration if such additional pre-authentication
1616 data can be used in conjunction with the PA_PK_AS_REQ. The future
1617 work of the Kerberos working group is expected to update the hash
1618 algorithms specified in this document and provide a generic mechanism
1619 to bind additional pre-authentication data with the accompanying
1620 AS_REQ.
1626 Zhu & Tung Standards Track [Page 29]
1627 \f
1628 RFC 4556 PKINIT June 2006
1631 The key usage number 6 used by the asChecksum field is also used for
1632 the authenticator checksum (cksum field of AP-REQ) contained in the
1633 PA-TGS-REQ preauthentication data contained in a TGS-REQ [RFC4120].
1634 This conflict is present for historical reasons; the reuse of key
1635 usage numbers is strongly discouraged.
1637 5. Acknowledgements
1639 The following people have made significant contributions to this
1640 document: Paul Leach, Stefan Santesson, Sam Hartman, Love Hornquist
1641 Astrand, Ken Raeburn, Nicolas Williams, John Wray, Tom Yu, Jeffrey
1642 Hutzelman, David Cross, Dan Simon, Karthik Jaganathan, Chaskiel M
1643 Grundman, and Jeffrey Altman.
1645 Andre Scedrov, Aaron D. Jaggard, Iliano Cervesato, Joe-Kai Tsay, and
1646 Chris Walstad discovered a binding issue between the AS-REQ and AS-
1647 REP in draft -26; the asChecksum field was added as the result.
1649 Special thanks to Clifford Neuman, Matthew Hur, Ari Medvinsky, Sasha
1650 Medvinsky, and Jonathan Trostle who wrote earlier versions of this
1651 document.
1653 The authors are indebted to the Kerberos working group chair, Jeffrey
1654 Hutzelman, who kept track of various issues and was enormously
1655 helpful during the creation of this document.
1657 Some of the ideas on which this document is based arose during
1658 discussions over several years between members of the SAAG, the IETF
1659 CAT working group, and the PSRG, regarding integration of Kerberos
1660 and SPX. Some ideas have also been drawn from the DASS system.
1661 These changes are by no means endorsed by these groups. This is an
1662 attempt to revive some of the goals of those groups, and this
1663 document approaches those goals primarily from the Kerberos
1664 perspective.
1666 Lastly, comments from groups working on similar ideas in DCE have
1667 been invaluable.
1669 6. References
1671 6.1. Normative References
1673 [IEEE1363] IEEE, "Standard Specifications for Public Key
1674 Cryptography", IEEE 1363, 2000.
1676 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1677 Requirement Levels", BCP 14, RFC 2119, March 1997.
1682 Zhu & Tung Standards Track [Page 30]
1683 \f
1684 RFC 4556 PKINIT June 2006
1687 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC
1688 2412, November 1998.
1690 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
1691 2631, June 1999.
1693 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
1694 Identifiers for the Internet X.509 Public Key
1695 Infrastructure Certificate and Certificate Revocation List
1696 (CRL) Profile", RFC 3279, April 2002.
1698 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
1699 X.509 Public Key Infrastructure Certificate and
1700 Certificate Revocation List (CRL) Profile", RFC 3280,
1701 April 2002.
1703 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
1704 Algorithms", RFC 3370, August 2002.
1706 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
1707 Standards (PKCS) #1: RSA Cryptography Specifications
1708 Version 2.1", RFC 3447, February 2003.
1710 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
1711 Diffie-Hellman groups for Internet Key Exchange (IKE)",
1712 RFC 3526, May 2003.
1714 [RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport
1715 Algorithm in Cryptographic Message Syntax (CMS)", RFC
1716 3560, July 2003.
1718 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
1719 Public Keys Used For Exchanging Symmetric Keys", BCP 86,
1720 RFC 3766, April 2004.
1722 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
1723 3852, July 2004.
1725 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
1726 Kerberos 5", RFC 3961, February 2005.
1728 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES)
1729 Encryption for Kerberos 5", RFC 3962, February 2005.
1731 [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
1732 "Randomness Requirements for Security", BCP 106, RFC 4086,
1733 June 2005.
1738 Zhu & Tung Standards Track [Page 31]
1739 \f
1740 RFC 4556 PKINIT June 2006
1743 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
1744 Kerberos Network Authentication Service (V5)", RFC 4120,
1745 July 2005.
1747 [X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
1748 Information technology - Abstract Syntax Notation One
1749 (ASN.1): Specification of basic notation.
1751 [X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
1752 Information technology - ASN.1 encoding Rules:
1753 Specification of Basic Encoding Rules (BER), Canonical
1754 Encoding Rules (CER) and Distinguished Encoding Rules
1755 (DER).
1757 6.2. Informative References
1759 [ODL99] Odlyzko, A., "Discrete logarithms: The past and the
1760 future, Designs, Codes, and Cryptography (1999)". April
1761 1999.
1763 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
1764 Version 5 Generic Security Service Application Program
1765 Interface (GSS-API) Mechanism: Version 2", RFC 4121, July
1766 2005.
1768 [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
1769 Nicholas, "Internet X.509 Public Key Infrastructure:
1770 Certification Path Building", RFC 4158, September 2005.
1794 Zhu & Tung Standards Track [Page 32]
1795 \f
1796 RFC 4556 PKINIT June 2006
1799 Appendix A. PKINIT ASN.1 Module
1801 KerberosV5-PK-INIT-SPEC {
1802 iso(1) identified-organization(3) dod(6) internet(1)
1803 security(5) kerberosV5(2) modules(4) pkinit(5)
1804 } DEFINITIONS EXPLICIT TAGS ::= BEGIN
1806 IMPORTS
1808 SubjectPublicKeyInfo, AlgorithmIdentifier
1809 FROM PKIX1Explicit88 { iso (1)
1810 identified-organization (3) dod (6) internet (1)
1811 security (5) mechanisms (5) pkix (7) id-mod (0)
1812 id-pkix1-explicit (18) }
1813 -- As defined in RFC 3280.
1815 KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum
1816 FROM KerberosV5Spec2 { iso(1) identified-organization(3)
1817 dod(6) internet(1) security(5) kerberosV5(2)
1818 modules(4) krb5spec2(2) };
1819 -- as defined in RFC 4120.
1821 id-pkinit OBJECT IDENTIFIER ::=
1822 { iso(1) identified-organization(3) dod(6) internet(1)
1823 security(5) kerberosv5(2) pkinit (3) }
1825 id-pkinit-authData OBJECT IDENTIFIER ::= { id-pkinit 1 }
1826 id-pkinit-DHKeyData OBJECT IDENTIFIER ::= { id-pkinit 2 }
1827 id-pkinit-rkeyData OBJECT IDENTIFIER ::= { id-pkinit 3 }
1828 id-pkinit-KPClientAuth OBJECT IDENTIFIER ::= { id-pkinit 4 }
1829 id-pkinit-KPKdc OBJECT IDENTIFIER ::= { id-pkinit 5 }
1831 id-pkinit-san OBJECT IDENTIFIER ::=
1832 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
1833 x509SanAN (2) }
1835 pa-pk-as-req INTEGER ::= 16
1836 pa-pk-as-rep INTEGER ::= 17
1838 ad-initial-verified-cas INTEGER ::= 9
1840 td-trusted-certifiers INTEGER ::= 104
1841 td-invalid-certificates INTEGER ::= 105
1842 td-dh-parameters INTEGER ::= 109
1844 PA-PK-AS-REQ ::= SEQUENCE {
1845 signedAuthPack [0] IMPLICIT OCTET STRING,
1846 -- Contains a CMS type ContentInfo encoded
1850 Zhu & Tung Standards Track [Page 33]
1851 \f
1852 RFC 4556 PKINIT June 2006
1855 -- according to [RFC3852].
1856 -- The contentType field of the type ContentInfo
1857 -- is id-signedData (1.2.840.113549.1.7.2),
1858 -- and the content field is a SignedData.
1859 -- The eContentType field for the type SignedData is
1860 -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
1861 -- eContent field contains the DER encoding of the
1862 -- type AuthPack.
1863 -- AuthPack is defined below.
1864 trustedCertifiers [1] SEQUENCE OF
1865 ExternalPrincipalIdentifier OPTIONAL,
1866 -- Contains a list of CAs, trusted by the client,
1867 -- that can be used to certify the KDC.
1868 -- Each ExternalPrincipalIdentifier identifies a CA
1869 -- or a CA certificate (thereby its public key).
1870 -- The information contained in the
1871 -- trustedCertifiers SHOULD be used by the KDC as
1872 -- hints to guide its selection of an appropriate
1873 -- certificate chain to return to the client.
1874 kdcPkId [2] IMPLICIT OCTET STRING
1875 OPTIONAL,
1876 -- Contains a CMS type SignerIdentifier encoded
1877 -- according to [RFC3852].
1878 -- Identifies, if present, a particular KDC
1879 -- public key that the client already has.
1880 ...
1881 }
1883 DHNonce ::= OCTET STRING
1885 ExternalPrincipalIdentifier ::= SEQUENCE {
1886 subjectName [0] IMPLICIT OCTET STRING OPTIONAL,
1887 -- Contains a PKIX type Name encoded according to
1888 -- [RFC3280].
1889 -- Identifies the certificate subject by the
1890 -- distinguished subject name.
1891 -- REQUIRED when there is a distinguished subject
1892 -- name present in the certificate.
1893 issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL,
1894 -- Contains a CMS type IssuerAndSerialNumber encoded
1895 -- according to [RFC3852].
1896 -- Identifies a certificate of the subject.
1897 -- REQUIRED for TD-INVALID-CERTIFICATES and
1898 -- TD-TRUSTED-CERTIFIERS.
1899 subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL,
1900 -- Identifies the subject's public key by a key
1901 -- identifier. When an X.509 certificate is
1902 -- referenced, this key identifier matches the X.509
1906 Zhu & Tung Standards Track [Page 34]
1907 \f
1908 RFC 4556 PKINIT June 2006
1911 -- subjectKeyIdentifier extension value. When other
1912 -- certificate formats are referenced, the documents
1913 -- that specify the certificate format and their use
1914 -- with the CMS must include details on matching the
1915 -- key identifier to the appropriate certificate
1916 -- field.
1917 -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
1918 ...
1919 }
1921 AuthPack ::= SEQUENCE {
1922 pkAuthenticator [0] PKAuthenticator,
1923 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
1924 -- Type SubjectPublicKeyInfo is defined in
1925 -- [RFC3280].
1926 -- Specifies Diffie-Hellman domain parameters
1927 -- and the client's public key value [IEEE1363].
1928 -- The DH public key value is encoded as a BIT
1929 -- STRING according to [RFC3279].
1930 -- This field is present only if the client wishes
1931 -- to use the Diffie-Hellman key agreement method.
1932 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
1933 OPTIONAL,
1934 -- Type AlgorithmIdentifier is defined in
1935 -- [RFC3280].
1936 -- List of CMS algorithm [RFC3370] identifiers
1937 -- that identify key transport algorithms, or
1938 -- content encryption algorithms, or signature
1939 -- algorithms supported by the client in order of
1940 -- (decreasing) preference.
1941 clientDHNonce [3] DHNonce OPTIONAL,
1942 -- Present only if the client indicates that it
1943 -- wishes to reuse DH keys or to allow the KDC to
1944 -- do so.
1945 ...
1946 }
1948 PKAuthenticator ::= SEQUENCE {
1949 cusec [0] INTEGER (0..999999),
1950 ctime [1] KerberosTime,
1951 -- cusec and ctime are used as in [RFC4120], for
1952 -- replay prevention.
1953 nonce [2] INTEGER (0..4294967295),
1954 -- Chosen randomly; this nonce does not need to
1955 -- match with the nonce in the KDC-REQ-BODY.
1956 paChecksum [3] OCTET STRING OPTIONAL,
1957 -- MUST be present.
1958 -- Contains the SHA1 checksum, performed over
1962 Zhu & Tung Standards Track [Page 35]
1963 \f
1964 RFC 4556 PKINIT June 2006
1967 -- KDC-REQ-BODY.
1968 ...
1969 }
1971 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
1972 ExternalPrincipalIdentifier
1973 -- Identifies a list of CAs trusted by the KDC.
1974 -- Each ExternalPrincipalIdentifier identifies a CA
1975 -- or a CA certificate (thereby its public key).
1977 TD-INVALID-CERTIFICATES ::= SEQUENCE OF
1978 ExternalPrincipalIdentifier
1979 -- Each ExternalPrincipalIdentifier identifies a
1980 -- certificate (sent by the client) with an invalid
1981 -- signature.
1983 KRB5PrincipalName ::= SEQUENCE {
1984 realm [0] Realm,
1985 principalName [1] PrincipalName
1986 }
1988 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
1989 ExternalPrincipalIdentifier
1990 -- Identifies the certification path based on which
1991 -- the client certificate was validated.
1992 -- Each ExternalPrincipalIdentifier identifies a CA
1993 -- or a CA certificate (thereby its public key).
1995 PA-PK-AS-REP ::= CHOICE {
1996 dhInfo [0] DHRepInfo,
1997 -- Selected when Diffie-Hellman key exchange is
1998 -- used.
1999 encKeyPack [1] IMPLICIT OCTET STRING,
2000 -- Selected when public key encryption is used.
2001 -- Contains a CMS type ContentInfo encoded
2002 -- according to [RFC3852].
2003 -- The contentType field of the type ContentInfo is
2004 -- id-envelopedData (1.2.840.113549.1.7.3).
2005 -- The content field is an EnvelopedData.
2006 -- The contentType field for the type EnvelopedData
2007 -- is id-signedData (1.2.840.113549.1.7.2).
2008 -- The eContentType field for the inner type
2009 -- SignedData (when unencrypted) is
2010 -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
2011 -- eContent field contains the DER encoding of the
2012 -- type ReplyKeyPack.
2013 -- ReplyKeyPack is defined below.
2014 ...
2018 Zhu & Tung Standards Track [Page 36]
2019 \f
2020 RFC 4556 PKINIT June 2006
2023 }
2025 DHRepInfo ::= SEQUENCE {
2026 dhSignedData [0] IMPLICIT OCTET STRING,
2027 -- Contains a CMS type ContentInfo encoded according
2028 -- to [RFC3852].
2029 -- The contentType field of the type ContentInfo is
2030 -- id-signedData (1.2.840.113549.1.7.2), and the
2031 -- content field is a SignedData.
2032 -- The eContentType field for the type SignedData is
2033 -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
2034 -- eContent field contains the DER encoding of the
2035 -- type KDCDHKeyInfo.
2036 -- KDCDHKeyInfo is defined below.
2037 serverDHNonce [1] DHNonce OPTIONAL,
2038 -- Present if and only if dhKeyExpiration is
2039 -- present.
2040 ...
2041 }
2043 KDCDHKeyInfo ::= SEQUENCE {
2044 subjectPublicKey [0] BIT STRING,
2045 -- The KDC's DH public key.
2046 -- The DH public key value is encoded as a BIT
2047 -- STRING according to [RFC3279].
2048 nonce [1] INTEGER (0..4294967295),
2049 -- Contains the nonce in the pkAuthenticator field
2050 -- in the request if the DH keys are NOT reused,
2051 -- 0 otherwise.
2052 dhKeyExpiration [2] KerberosTime OPTIONAL,
2053 -- Expiration time for KDC's key pair,
2054 -- present if and only if the DH keys are reused.
2055 -- If present, the KDC's DH public key MUST not be
2056 -- used past the point of this expiration time.
2057 -- If this field is omitted then the serverDHNonce
2058 -- field MUST also be omitted.
2059 ...
2060 }
2062 ReplyKeyPack ::= SEQUENCE {
2063 replyKey [0] EncryptionKey,
2064 -- Contains the session key used to encrypt the
2065 -- enc-part field in the AS-REP, i.e., the
2066 -- AS reply key.
2067 asChecksum [1] Checksum,
2068 -- Contains the checksum of the AS-REQ
2069 -- corresponding to the containing AS-REP.
2070 -- The checksum is performed over the type AS-REQ.
2074 Zhu & Tung Standards Track [Page 37]
2075 \f
2076 RFC 4556 PKINIT June 2006
2079 -- The protocol key [RFC3961] of the checksum is the
2080 -- replyKey and the key usage number is 6.
2081 -- If the replyKey's enctype is "newer" [RFC4120]
2082 -- [RFC4121], the checksum is the required
2083 -- checksum operation [RFC3961] for that enctype.
2084 -- The client MUST verify this checksum upon receipt
2085 -- of the AS-REP.
2086 ...
2087 }
2089 TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
2090 -- Each AlgorithmIdentifier specifies a set of
2091 -- Diffie-Hellman domain parameters [IEEE1363].
2092 -- This list is in decreasing preference order.
2093 END
2095 Appendix B. Test Vectors
2097 Function octetstring2key() is defined in Section 3.2.3.1. This
2098 section describes a few sets of test vectors that would be useful for
2099 implementers of octetstring2key().
2101 Set 1:
2102 =====
2103 Input octet string x is:
2105 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2106 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2107 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2108 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2109 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2111 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2112 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2113 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2114 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2115 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2116 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2117 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2118 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2119 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2122 Output of K-truncate() when the key size is 32 octets:
2124 5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83
2125 75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41
2130 Zhu & Tung Standards Track [Page 38]
2131 \f
2132 RFC 4556 PKINIT June 2006
2135 Set 2:
2136 =====
2137 Input octet string x is:
2139 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2141 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2142 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2143 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2144 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2145 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2146 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2148 Output of K-truncate() when the key size is 32 octets:
2150 ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb
2151 a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e
2154 Set 3:
2155 ======
2156 Input octet string x is:
2158 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
2159 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
2160 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
2161 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
2162 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b
2163 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a
2164 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09
2165 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
2167 Output of K-truncate() when the key size is 32 octets:
2169 c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3
2170 73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e
2173 Set 4:
2174 =====
2175 Input octet string x is:
2177 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
2178 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
2179 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
2180 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
2181 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
2186 Zhu & Tung Standards Track [Page 39]
2187 \f
2188 RFC 4556 PKINIT June 2006
2191 Output of K-truncate() when the key size is 32 octets:
2193 00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a
2194 59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc
2196 Appendix C. Miscellaneous Information about Microsoft Windows PKINIT
2197 Implementations
2199 Earlier revisions of the PKINIT I-D were implemented in various
2200 releases of Microsoft Windows and deployed in fairly large numbers.
2201 To enable the community to interoperate better with systems running
2202 those releases, the following information may be useful.
2204 KDC certificates issued by Windows 2000 Enterprise CAs contain a
2205 dNSName SAN with the DNS name of the host running the KDC, and the
2206 id-kp-serverAuth EKU [RFC3280].
2208 KDC certificates issued by Windows 2003 Enterprise CAs contain a
2209 dNSName SAN with the DNS name of the host running the KDC, the id-
2210 kp-serverAuth EKU, and the id-ms-kp-sc-logon EKU.
2212 It is anticipated that the next release of Windows is already too far
2213 along to allow it to support the issuing KDC certificates with id-
2214 pkinit-san SAN as specified in this RFC. Instead, they will have a
2215 dNSName SAN containing the domain name of the KDC, and the intended
2216 purpose of these KDC certificates will be restricted by the presence
2217 of the id-pkinit-KPKdc EKU and id-kp-serverAuth EKU.
2219 In addition to checking that the above are present in a KDC
2220 certificate, Windows clients verify that the issuer of the KDC
2221 certificate is one of a set of allowed issuers of such certificates,
2222 so those wishing to issue KDC certificates need to configure their
2223 Windows clients appropriately.
2225 Client certificates accepted by Windows 2000 and Windows 2003 Server
2226 KDCs must contain an id-ms-san-sc-logon-upn (1.3.6.1.4.1.311.20.2.3)
2227 SAN and the id-ms-kp-sc-logon EKU. The id-ms-san-sc-logon-upn SAN
2228 contains a UTF8-encoded string whose value is that of the Directory
2229 Service attribute UserPrincipalName of the client account object, and
2230 the purpose of including the id-ms-san-sc-logon-upn SAN in the client
2231 certificate is to validate the client mapping (in other words, the
2232 client's public key is bound to the account that has this
2233 UserPrincipalName value).
2235 It should be noted that all Microsoft Kerberos realm names are
2236 domain-style realm names and strictly in uppercase. In addition, the
2237 UserPrincipalName attribute is globally unique in Windows 2000 and
2238 Windows 2003.
2242 Zhu & Tung Standards Track [Page 40]
2243 \f
2244 RFC 4556 PKINIT June 2006
2247 Authors' Addresses
2249 Larry Zhu
2250 Microsoft Corporation
2251 One Microsoft Way
2252 Redmond, WA 98052
2253 US
2255 EMail: lzhu@microsoft.com
2258 Brian Tung
2259 Aerospace Corporation
2260 2350 E. El Segundo Blvd.
2261 El Segundo, CA 90245
2262 US
2264 EMail: brian@aero.org
2298 Zhu & Tung Standards Track [Page 41]
2299 \f
2300 RFC 4556 PKINIT June 2006
2303 Full Copyright Statement
2305 Copyright (C) The Internet Society (2006).
2307 This document is subject to the rights, licenses and restrictions
2308 contained in BCP 78, and except as set forth therein, the authors
2309 retain all their rights.
2311 This document and the information contained herein are provided on an
2312 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2313 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2314 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2315 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
2316 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2317 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2319 Intellectual Property
2321 The IETF takes no position regarding the validity or scope of any
2322 Intellectual Property Rights or other rights that might be claimed to
2323 pertain to the implementation or use of the technology described in
2324 this document or the extent to which any license under such rights
2325 might or might not be available; nor does it represent that it has
2326 made any independent effort to identify any such rights. Information
2327 on the procedures with respect to rights in RFC documents can be
2328 found in BCP 78 and BCP 79.
2330 Copies of IPR disclosures made to the IETF Secretariat and any
2331 assurances of licenses to be made available, or the result of an
2332 attempt made to obtain a general license or permission for the use of
2333 such proprietary rights by implementers or users of this
2334 specification can be obtained from the IETF on-line IPR repository at
2335 http://www.ietf.org/ipr.
2337 The IETF invites any interested party to bring to its attention any
2338 copyrights, patents or patent applications, or other proprietary
2339 rights that may cover technology that may be required to implement
2340 this standard. Please address the information to the IETF at
2341 ietf-ipr@ietf.org.
2343 Acknowledgement
2345 Funding for the RFC Editor function is provided by the IETF
2346 Administrative Support Activity (IASA).
2354 Zhu & Tung Standards Track [Page 42]
2355 \f