| blob | 6cfe5c9d21efb1e98521696c1d68fc6104fd9a97 |
4 NETWORK WORKING GROUP B. Tung
5 Internet-Draft USC Information Sciences Institute
6 Expires: November 24, 2005 L. Zhu
7 Microsoft Corporation
8 May 23, 2005
11 Public Key Cryptography for Initial Authentication in Kerberos
12 draft-ietf-cat-kerberos-pk-init-26
14 Status of this Memo
16 This document is an Internet-Draft and is subject to all provisions
17 of Section 3 of RFC 3667.
19 By submitting this Internet-Draft, each author represents that any
20 applicable patent or other IPR claims of which he or she is aware
21 have been or will be disclosed, and any of which he or she becomes
22 aware will be disclosed, in accordance with Section 6 of BCP 79.
24 Internet-Drafts are working documents of the Internet Engineering
25 Task Force (IETF), its areas, and its working groups. Note that
26 other groups may also distribute working documents as Internet-
27 Drafts.
29 Internet-Drafts are draft documents valid for a maximum of six months
30 and may be updated, replaced, or obsoleted by other documents at any
31 time. It is inappropriate to use Internet-Drafts as reference
32 material or to cite them other than as "work in progress."
34 The list of current Internet-Drafts can be accessed at
35 http://www.ietf.org/ietf/1id-abstracts.txt.
37 The list of Internet-Draft Shadow Directories can be accessed at
38 http://www.ietf.org/shadow.html.
40 This Internet-Draft will expire on November 24, 2005.
42 Copyright Notice
44 Copyright (C) The Internet Society (2005).
46 Abstract
48 This document describes protocol extensions (hereafter called PKINIT)
49 to the Kerberos protocol specification. These extensions provide a
50 method for integrating public key cryptography into the initial
51 authentication exchange, by using asymmetric-key signature and/or
52 encryption algorithms in pre-authentication data fields.
56 Tung & Zhu Expires November 24, 2005 [Page 1]
57 \f
58 Internet-Draft PKINIT May 2005
61 Table of Contents
63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
64 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
65 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
66 3.1 Definitions, Requirements, and Constants . . . . . . . . . 4
67 3.1.1 Required Algorithms . . . . . . . . . . . . . . . . . 4
68 3.1.2 Defined Message and Encryption Types . . . . . . . . . 5
69 3.1.3 Algorithm Identifiers . . . . . . . . . . . . . . . . 6
70 3.2 PKINIT Pre-authentication Syntax and Use . . . . . . . . . 7
71 3.2.1 Generation of Client Request . . . . . . . . . . . . . 7
72 3.2.2 Receipt of Client Request . . . . . . . . . . . . . . 10
73 3.2.3 Generation of KDC Reply . . . . . . . . . . . . . . . 13
74 3.2.4 Receipt of KDC Reply . . . . . . . . . . . . . . . . . 19
75 3.3 Interoperability Requirements . . . . . . . . . . . . . . 20
76 3.4 KDC Indication of PKINIT Support . . . . . . . . . . . . . 20
77 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21
78 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
81 7.1 Normative References . . . . . . . . . . . . . . . . . . . 22
82 7.2 Informative References . . . . . . . . . . . . . . . . . . 24
83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
84 A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 25
85 Intellectual Property and Copyright Statements . . . . . . . . 30
112 Tung & Zhu Expires November 24, 2005 [Page 2]
113 \f
114 Internet-Draft PKINIT May 2005
117 1. Introduction
119 A client typically authenticates itself to a service in Kerberos
120 using three distinct though related exchanges. First, the client
121 requests a ticket-granting ticket (TGT) from the Kerberos
122 authentication server (AS). Then, it uses the TGT to request a
123 service ticket from the Kerberos ticket-granting server (TGS).
124 Usually, the AS and TGS are integrated in a single device known as a
125 Kerberos Key Distribution Center, or KDC. Finally, the client uses
126 the service ticket to authenticate itself to the service.
128 The advantage afforded by the TGT is that the client exposes his
129 long-term secrets only once. The TGT and its associated session key
130 can then be used for any subsequent service ticket requests. One
131 result of this is that all further authentication is independent of
132 the method by which the initial authentication was performed.
133 Consequently, initial authentication provides a convenient place to
134 integrate public-key cryptography into Kerberos authentication.
136 As defined in [CLAR], Kerberos authentication exchanges use
137 symmetric-key cryptography, in part for performance. One
138 disadvantage of using symmetric-key cryptography is that the keys
139 must be shared, so that before a client can authenticate itself, he
140 must already be registered with the KDC.
142 Conversely, public-key cryptography (in conjunction with an
143 established Public Key Infrastructure) permits authentication without
144 prior registration with a KDC. Adding it to Kerberos allows the
145 widespread use of Kerberized applications by clients without
146 requiring them to register first with a KDC--a requirement that has
147 no inherent security benefit.
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
153 authentication.
155 2. Conventions Used in This Document
157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
159 document are to be interpreted as described in [RFC2119].
161 Both the AS and the TGS are referred to as the KDC.
163 In this document, the encryption key used to encrypt the enc-part
164 field of the KDC-REP in the AS-REP [CLAR] is referred to as the AS
168 Tung & Zhu Expires November 24, 2005 [Page 3]
169 \f
170 Internet-Draft PKINIT May 2005
173 reply key.
175 3. Extensions
177 This section describes extensions to [CLAR] for supporting the use of
178 public-key cryptography in the initial request for a ticket.
180 Briefly, this document defines the following extensions to [CLAR]:
182 1. The client indicates the use of public-key authentication by
183 including a special preauthenticator in the initial request. This
184 preauthenticator contains the client's public-key data and a
185 signature.
187 2. The KDC tests the client's request against its authentication
188 policy and trusted Certification Authorities (CAs).
190 3. If the request passes the verification tests, the KDC replies as
191 usual, but the reply is encrypted using either:
193 a. a key generated through a Diffie-Hellman (DH) key exchange
194 [RFC2631] [IEEE1363] with the client, signed using the KDC's
195 signature key; or
197 b. a symmetric encryption key, signed using the KDC's signature
198 key and encrypted using the client's public key.
200 Any keying material required by the client to obtain the
201 encryption key for decrypting the KDC reply is returned in a pre-
202 authentication field accompanying the usual reply.
204 4. The client validates the KDC's signature, obtains the encryption
205 key, decrypts the reply, and then proceeds as usual.
207 Section 3.1 of this document enumerates the required algorithms and
208 necessary extension message types. Section 3.2 describes the
209 extension messages in greater detail.
211 3.1 Definitions, Requirements, and Constants
213 3.1.1 Required Algorithms
215 All PKINIT implementations MUST support the following algorithms:
217 o AS reply key enctype: AES256-CTS-HMAC-SHA1-96 etype [RFC3962].
224 Tung & Zhu Expires November 24, 2005 [Page 4]
225 \f
226 Internet-Draft PKINIT May 2005
229 o Signature algorithm: sha-1WithRSAEncryption [RFC3279].
231 o AS reply key delivery method: Diffie-Hellman key exchange
232 [RFC2631].
235 3.1.2 Defined Message and Encryption Types
237 PKINIT makes use of the following new pre-authentication types:
239 PA_PK_AS_REQ 16
240 PA_PK_AS_REP 17
242 PKINIT also makes use of the following new authorization data type:
244 AD_INITIAL_VERIFIED_CAS 9
246 PKINIT introduces the following new error codes:
248 KDC_ERR_CLIENT_NOT_TRUSTED 62
249 KDC_ERR_INVALID_SIG 64
250 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65
251 KDC_ERR_CANT_VERIFY_CERTIFICATE 70
252 KDC_ERR_INVALID_CERTIFICATE 71
253 KDC_ERR_REVOKED_CERTIFICATE 72
254 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
255 KDC_ERR_CLIENT_NAME_MISMATCH 75
256 KDC_ERR_INCONSISTENT_KEY_PURPOSE 76
258 PKINIT uses the following typed data types for errors:
260 TD_TRUSTED_CERTIFIERS 104
261 TD_INVALID_CERTIFICATES 105
262 TD_DH_PARAMETERS 109
264 PKINIT defines the following encryption types, for use in the AS-REQ
265 message to indicate acceptance of the corresponding algorithms that
266 can used by Cryptographic Message Syntax (CMS) [RFC3852] messages in
267 the reply:
269 dsaWithSHA1-CmsOID 9
270 md5WithRSAEncryption-CmsOID 10
271 sha1WithRSAEncryption-CmsOID 11
272 rc2CBC-EnvOID 12
273 rsaEncryption-EnvOID (PKCS1 v1.5) 13
274 rsaES-OAEP-EnvOID (PKCS1 v2.0) 14
275 des-ede3-cbc-EnvOID 15
280 Tung & Zhu Expires November 24, 2005 [Page 5]
281 \f
282 Internet-Draft PKINIT May 2005
285 The ASN.1 module for all structures defined in this document (plus
286 IMPORT statements for all imported structures) is given in
287 Appendix A.
289 All structures defined in or imported into this document MUST be
290 encoded using Distinguished Encoding Rules (DER) [X690] (unless
291 otherwise noted). All data structures carried in OCTET STRINGs must
292 be encoded according to the rules specified in corresponding
293 specifications.
295 Interoperability note: Some implementations may not be able to decode
296 wrapped CMS objects encoded with BER but not DER; specifically, they
297 may not be able to decode infinite length encodings. To maximize
298 interoperability, implementers SHOULD encode CMS objects used in
299 PKINIT with DER.
301 3.1.3 Algorithm Identifiers
303 PKINIT does not define, but does make use of, the following algorithm
304 identifiers.
306 PKINIT uses the following algorithm identifiers for Diffie-Hellman
307 key agreement [RFC3279]:
309 dhpublicnumber (Modular Exponential Diffie-Hellman [RFC2631])
310 id-ecPublicKey (Elliptic Curve Diffie-Hellman [IEEE1363])
312 PKINIT uses the following signature algorithm identifiers [RFC3279]:
314 sha-1WithRSAEncryption (RSA with SHA1)
315 md5WithRSAEncryption (RSA with MD5)
316 id-dsa-with-sha1 (DSA with SHA1)
318 PKINIT uses the following encryption algorithm identifiers [RFC3447]
319 for encrypting the temporary key with a public key:
321 rsaEncryption (PKCS1 v1.5)
322 id-RSAES-OAEP (PKCS1 v2.0)
324 PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565]
325 for encrypting the AS reply key with the temporary key:
327 des-ede3-cbc (three-key 3DES, CBC mode)
328 rc2-cbc (RC2, CBC mode)
329 id-aes256-CBC (AES-256, CBC mode)
336 Tung & Zhu Expires November 24, 2005 [Page 6]
337 \f
338 Internet-Draft PKINIT May 2005
341 3.2 PKINIT Pre-authentication Syntax and Use
343 This section defines the syntax and use of the various pre-
344 authentication fields employed by PKINIT.
346 3.2.1 Generation of Client Request
348 The initial authentication request (AS-REQ) is sent as per [CLAR]; in
349 addition, a pre-authentication data element, whose padata-type is
350 PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
351 type PA-PK-AS-REQ, is included.
353 PA-PK-AS-REQ ::= SEQUENCE {
354 signedAuthPack [0] IMPLICIT OCTET STRING,
355 -- Contains a CMS type ContentInfo encoded
356 -- according to [RFC3852].
357 -- The contentType field of the type ContentInfo
358 -- is id-signedData (1.2.840.113549.1.7.2),
359 -- and the content field is a SignedData.
360 -- The eContentType field for the type SignedData is
361 -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
362 -- eContent field contains the DER encoding of the
363 -- type AuthPack.
364 -- AuthPack is defined below.
365 trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,
366 -- A list of CAs, trusted by the client, that can
367 -- be used to certify the KDC.
368 -- Each TrustedCA identifies a CA or a CA
369 -- certificate (thereby its public key).
370 -- The information contained in the
371 -- trustedCertifiers SHOULD be used by the KDC as
372 -- hints to guide its selection of an appropriate
373 -- certificate chain to return to the client.
374 kdcPkId [2] IMPLICIT OCTET STRING
375 OPTIONAL,
376 -- Contains a CMS type SignerIdentifier encoded
377 -- according to [RFC3852].
378 -- Identifies, if present, a particular KDC
379 -- public key that the client already has.
380 ...
381 }
383 DHNonce ::= OCTET STRING
385 TrustedCA ::= SEQUENCE {
386 caName [0] IMPLICIT OCTET STRING,
387 -- Contains a PKIX type Name encoded according to
388 -- [RFC3280].
392 Tung & Zhu Expires November 24, 2005 [Page 7]
393 \f
394 Internet-Draft PKINIT May 2005
397 -- Identifies a CA by the CA's distinguished subject
398 -- name.
399 certificateSerialNumber [1] INTEGER OPTIONAL,
400 -- Specifies the CA certificate's serial number.
401 -- The defintion of the certificate serial number
402 -- is taken from X.509 [X.509-97].
403 subjectKeyIdentifier [2] OCTET STRING OPTIONAL,
404 -- Identifies the CA's public key by a key
405 -- identifier. When an X.509 certificate is
406 -- referenced, this key identifier matches the X.509
407 -- subjectKeyIdentifier extension value. When other
408 -- certificate formats are referenced, the documents
409 -- that specify the certificate format and their use
410 -- with the CMS must include details on matching the
411 -- key identifier to the appropriate certificate
412 -- field.
413 ...
414 }
416 AuthPack ::= SEQUENCE {
417 pkAuthenticator [0] PKAuthenticator,
418 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
419 -- Type SubjectPublicKeyInfo is defined in
420 -- [RFC3280].
421 -- Specifies Diffie-Hellman domain parameters
422 -- and the client's public key value [IEEE1363].
423 -- The DH public key value is encoded as a BIT
424 -- STRING, as specified in Section 2.3.3 of
425 -- [RFC3279].
426 -- This field is present only if the client wishes
427 -- to use the Diffie-Hellman key agreement method.
428 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
429 OPTIONAL,
430 -- Type AlgorithmIdentifier is defined in
431 -- [RFC3280].
432 -- List of CMS encryption types supported by the
433 -- client in order of (decreasing) preference.
434 clientDHNonce [3] DHNonce OPTIONAL,
435 -- Present only if the client indicates that it
436 -- wishes to reuse DH keys or to allow the KDC to
437 -- do so (see Section 3.2.3.1).
438 ...
439 }
441 PKAuthenticator ::= SEQUENCE {
442 cusec [0] INTEGER (0..999999),
443 ctime [1] KerberosTime,
444 -- cusec and ctime are used as in [CLAR], for replay
448 Tung & Zhu Expires November 24, 2005 [Page 8]
449 \f
450 Internet-Draft PKINIT May 2005
453 -- prevention.
454 nonce [2] INTEGER (0..4294967295),
455 -- Chosen randomly; This nonce does not need to
456 -- match with the nonce in the KDC-REQ-BODY.
457 paChecksum [3] OCTET STRING,
458 -- Contains the SHA1 checksum, performed over
459 -- KDC-REQ-BODY.
460 ...
461 }
463 The ContentInfo [RFC3852] structure for the signedAuthPack field is
464 filled out as follows:
466 1. The contentType field of the type ContentInfo is id-signedData
467 (as defined in [RFC3852]), and the content field is a SignedData
468 (as defined in [RFC3852]).
470 2. The eContentType field for the type SignedData is id-pkauthdata:
471 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
472 pkinit(3) pkauthdata(1) }.
474 3. The eContent field for the type SignedData contains the DER
475 encoding of the type AuthPack.
477 4. The signerInfos field of the type SignedData contains a single
478 signerInfo, which contains the signature over the type AuthPack.
480 5. The certificates field of the type SignedData contains
481 certificates intended to facilitate certification path
482 construction, so that the KDC can verify the signature over the
483 type AuthPack. For path validation, these certificates SHOULD be
484 sufficient to construct at least one certification path from the
485 client certificate to one trust anchor acceptable by the KDC
486 [CAPATH]. The client MUST be capable of including such a set of
487 certificates if configured to do so. The certificates field MUST
488 NOT contain "root" CA certificates.
490 6. The client's Diffie-Hellman public value (clientPublicValue) is
491 included if and only if the client wishes to use the Diffie-
492 Hellman key agreement method. The Diffie-Hellman domain
493 parameters [IEEE1363] for the client's public key are specified
494 in the algorithm field of the type SubjectPublicKeyInfo [RFC3279]
495 and the client's Diffie-Hellman public key value is mapped to a
496 subjectPublicKey (a BIT STRING) according to [RFC3279]. When
497 using the Diffie-Hellman key agreement method, implementations
498 MUST support Oakley 1024-bit Modular Exponential (MODP) well-
499 known group 2 [RFC2412] and SHOULD support Oakley 2048-bit MODP
500 well-known group 14 and Oakley 4096-bit MODP well-known group 16
504 Tung & Zhu Expires November 24, 2005 [Page 9]
505 \f
506 Internet-Draft PKINIT May 2005
509 [RFC3526].
511 The Diffie-Hellman field size should be chosen so as to provide
512 sufficient cryptographic security [RFC3766].
514 When MODP Diffie-Hellman is used, the exponents should have at
515 least twice as many bits as the symmetric keys that will be
516 derived from them [ODL99].
518 7. The client may wish to reuse DH keys or to allow the KDC to do so
519 (see Section 3.2.3.1). If so, then the client includes the
520 clientDHNonce field. This nonce string needs to be as long as
521 the longest key length of the symmetric key types that the client
522 supports. This nonce MUST be chosen randomly.
525 3.2.2 Receipt of Client Request
527 Upon receiving the client's request, the KDC validates it. This
528 section describes the steps that the KDC MUST (unless otherwise
529 noted) take in validating the request.
531 The KDC verifies the client's signature in the signedAuthPack field
532 according to [RFC3852].
534 If, while validating the client's X.509 certificate [RFC3280], the
535 KDC cannot build a certification path to validate the client's
536 certificate, it sends back a KRB-ERROR [CLAR] message with the code
537 KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for this
538 error message is a TYPED-DATA (as defined in [CLAR]) that contains an
539 element whose data-type is TD_TRUSTED_CERTIFIERS, and whose data-
540 value contains the DER encoding of the type TD-TRUSTED-CERTIFIERS:
542 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TrustedCA
543 -- Identifies a list of CAs trusted by the KDC.
544 -- Each TrustedCA identifies a CA or a CA
545 -- certificate (thereby its public key).
547 Upon receiving this error message, the client SHOULD retry only if it
548 has a different set of certificates (from those of the previous
549 requests) that form a certification path (or a partial path) from one
550 of the trust anchors acceptable by the KDC to its own certificate.
552 If, while processing the certification path, the KDC determines that
553 the signature on one of the certificates in the signedAuthPack field
554 is invalid, it returns a KRB-ERROR [CLAR] message with the code
555 KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data for this error
556 message is a TYPED-DATA that contains an element whose data-type is
560 Tung & Zhu Expires November 24, 2005 [Page 10]
561 \f
562 Internet-Draft PKINIT May 2005
565 TD_INVALID_CERTIFICATES, and whose data-value contains the DER
566 encoding of the type TD-INVALID-CERTIFICATES:
568 TD-INVALID-CERTIFICATES ::= SEQUENCE OF OCTET STRING
569 -- Each OCTET STRING contains a CMS type
570 -- IssuerAndSerialNumber encoded according to
571 -- [RFC3852].
572 -- Each IssuerAndSerialNumber identifies a
573 -- certificate (sent by the client) with an invalid
574 -- signature.
576 If more than one X.509 certificate signature is invalid, the KDC MAY
577 include one IssuerAndSerialNumber per invalid signature within the
578 TD-INVALID-CERTIFICATES.
580 The client's X.509 certificate is validated according to [RFC3280].
582 Based on local policy, the KDC may also check whether any X.509
583 certificates in the certification path validating the client's
584 certificate have been revoked. If any of them have been revoked, the
585 KDC MUST return an error message with the code
586 KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
587 revocation status but is unable to do so, it SHOULD return an error
588 message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN. The
589 certificate or certificates affected are identified exactly as for
590 the error code KDC_ERR_INVALID_CERTIFICATE (see above).
592 Note that the TD_INVALID_CERTIFICATES error data is only used to
593 identify invalid certificates sent by the client in the request.
595 The client's public key is then used to verify the signature. If the
596 signature fails to verify, the KDC MUST return an error message with
597 the code KDC_ERR_INVALID_SIG. There is no accompanying e-data for
598 this error message.
600 In addition to validating the client's signature, the KDC MUST also
601 check that the client's public key used to verify the client's
602 signature is bound to the client's principal name as specified in the
603 AS-REQ as follows:
605 1. If the KDC has its own binding between either the client's
606 signature-verification public key or the client's certificate and
607 the client's Kerberos principal name, it uses that binding.
616 Tung & Zhu Expires November 24, 2005 [Page 11]
617 \f
618 Internet-Draft PKINIT May 2005
621 2. Otherwise, if the client's X.509 certificate contains a Subject
622 Alternative Name (SAN) extension carrying a KRB5PrincipalName
623 (defined below) in the otherName field of the type GeneralName
624 [RFC3280], it binds the client's X.509 certificate to that name.
626 The type of the otherName field is AnotherName. The type-id field
627 of the type AnotherName is id-pksan:
629 id-pksan OBJECT IDENTIFIER ::=
630 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
631 x509-sanan (2) }
633 And the value field of the type AnotherName is a
634 KRB5PrincipalName.
636 KRB5PrincipalName ::= SEQUENCE {
637 realm [0] Realm,
638 principalName [1] PrincipalName
639 }
641 If the KDC does not have its own binding and there is no
642 KRB5PrincipalName name present in the client's X.509 certificate, or
643 if the Kerberos name in the request does not match the
644 KRB5PrincipalName in the client's X.509 certificate (including the
645 realm name), the KDC MUST return an error message with the code
646 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for
647 this error message.
649 The KDC MAY require the presence of an Extended Key Usage (EKU)
650 KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the
651 client's X.509 certificate:
653 id-pkekuoid OBJECT IDENTIFIER ::=
654 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
655 pkinit(3) pkekuoid(4) }
656 -- PKINIT client authentication.
657 -- Key usage bits that MUST be consistent:
658 -- digitalSignature.
660 If this EKU KeyPurposeId is required but it is not present or if the
661 client certificate is restricted not to be used for PKINIT client
662 authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
663 an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE. There
664 is no accompanying e-data for this error message. KDCs implementing
665 this requirement SHOULD also accept the EKU KeyPurposeId id-ms-sc-
666 logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there
667 are a large number of X.509 client certificates deployed for use with
668 PKINIT which have this EKU.
672 Tung & Zhu Expires November 24, 2005 [Page 12]
673 \f
674 Internet-Draft PKINIT May 2005
677 If for any other reasons, the client's public key is not accepted,
678 the KDC MUST return an error message with the code
679 KDC_ERR_CLIENT_NOT_TRUSTED.
681 The KDC MUST check the timestamp to ensure that the request is not a
682 replay, and that the time skew falls within acceptable limits. The
683 recommendations for clock skew times in [CLAR] apply here. If the
684 check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
685 KRB_AP_ERR_SKEW, respectively.
687 If the clientPublicValue is filled in, indicating that the client
688 wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
689 check to see if the key parameters satisfy its policy. If they do
690 not, it MUST return an error message with the code
691 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The accompanying e-data is a
692 TYPED-DATA that contains an element whose data-type is
693 TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
694 the type TD-DH-PARAMETERS:
696 TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
697 -- Each AlgorithmIdentifier specifies a set of
698 -- Diffie-Hellman domain parameters [IEEE1363].
699 -- This list is in decreasing preference order.
701 TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
702 that the KDC supports in decreasing preference order, from which the
703 client SHOULD pick one to retry the request.
705 If the client included a kdcPkId field in the PA-PK-AS-REQ and the
706 KDC does not possess the corresponding key, the KDC MUST ignore the
707 kdcPkId field as if the client did not include one.
709 If there is a supportedCMSTypes field in the AuthPack, the KDC must
710 check to see if it supports any of the listed types. If it supports
711 more than one of the types, the KDC SHOULD use the one listed first.
712 If it does not support any of them, it MUST return an error message
713 with the code KDC_ERR_ETYPE_NOSUPP [CLAR].
715 3.2.3 Generation of KDC Reply
717 Assuming that the client's request has been properly validated, the
718 KDC proceeds as per [CLAR], except as follows.
720 The KDC MUST set the initial flag and include an authorization data
721 element of ad-type [CLAR] AD_INITIAL_VERIFIED_CAS in the issued
722 ticket. The ad-data [CLAR] field contains the DER encoding of the
723 type AD-INITIAL-VERIFIED-CAS:
728 Tung & Zhu Expires November 24, 2005 [Page 13]
729 \f
730 Internet-Draft PKINIT May 2005
733 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF TrustedCA
734 -- Identifies the certification path based on which
735 -- the client certificate was validated.
736 -- Each TrustedCA identifies a CA or a CA
737 -- certificate (thereby its public key).
739 The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
740 containers if the list of CAs satisfies the AS' realm's local policy
741 (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
742 [CLAR]). Furthermore, any TGS MUST copy such authorization data from
743 tickets used within a PA-TGS-REQ of the TGS-REQ into the resulting
744 ticket. If the list of CAs satisfies the local KDC's realm's policy,
745 the TGS MAY wrap the data into the AD-IF-RELEVANT container,
746 otherwise it MAY unwrap the authorization data out of the AD-IF-
747 RELEVANT container.
749 Application servers that understand this authorization data type
750 SHOULD apply local policy to determine whether a given ticket bearing
751 such a type *not* contained within an AD-IF-RELEVANT container is
752 acceptable. (This corresponds to the AP server checking the
753 transited field when the TRANSITED-POLICY-CHECKED flag has not been
754 set [CLAR].) If such a data type is contained within an AD-IF-
755 RELEVANT container, AP servers MAY apply local policy to determine
756 whether the authorization data is acceptable.
758 The content of the AS-REP is otherwise unchanged from [CLAR]. The
759 KDC encrypts the reply as usual, but not with the client's long-term
760 key. Instead, it encrypts it with either a shared key derived from a
761 Diffie-Hellman exchange, or a generated encryption key. The contents
762 of the PA-PK-AS-REP indicate which key delivery method is used:
764 PA-PK-AS-REP ::= CHOICE {
765 dhInfo [0] DHRepInfo,
766 -- Selected when Diffie-Hellman key exchange is
767 -- used.
768 encKeyPack [1] IMPLICIT OCTET STRING,
769 -- Selected when public key encryption is used.
770 -- Contains a CMS type ContentInfo encoded
771 -- according to [RFC3852].
772 -- The contentType field of the type ContentInfo is
773 -- id-envelopedData (1.2.840.113549.1.7.3).
774 -- The content field is an EnvelopedData.
775 -- The contentType field for the type EnvelopedData
776 -- is id-signedData (1.2.840.113549.1.7.2).
777 -- The eContentType field for the inner type
778 -- SignedData (when unencrypted) is id-pkrkeydata
779 -- (1.2.840.113549.1.7.3) and the eContent field
780 -- contains the DER encoding of the type
784 Tung & Zhu Expires November 24, 2005 [Page 14]
785 \f
786 Internet-Draft PKINIT May 2005
789 -- ReplyKeyPack.
790 -- ReplyKeyPack is defined in Section 3.2.3.2.
791 ...
792 }
794 DHRepInfo ::= SEQUENCE {
795 dhSignedData [0] IMPLICIT OCTET STRING,
796 -- Contains a CMS type ContentInfo encoded according
797 -- to [RFC3852].
798 -- The contentType field of the type ContentInfo is
799 -- id-signedData (1.2.840.113549.1.7.2), and the
800 -- content field is a SignedData.
801 -- The eContentType field for the type SignedData is
802 -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
803 -- eContent field contains the DER encoding of the
804 -- type KDCDHKeyInfo.
805 -- KDCDHKeyInfo is defined below.
806 serverDHNonce [1] DHNonce OPTIONAL
807 -- Present if and only if dhKeyExpiration is
808 -- present in the KDCDHKeyInfo.
809 }
811 KDCDHKeyInfo ::= SEQUENCE {
812 subjectPublicKey [0] BIT STRING,
813 -- KDC's DH public key.
814 -- The DH public key value is encoded as a BIT
815 -- STRING, as specified in Section 2.3.3 of
816 -- [RFC3279].
817 nonce [1] INTEGER (0..4294967295),
818 -- Contains the nonce in the PKAuthenticator of the
819 -- request if DH keys are NOT reused,
820 -- 0 otherwise.
821 dhKeyExpiration [2] KerberosTime OPTIONAL,
822 -- Expiration time for KDC's key pair,
823 -- present if and only if DH keys are reused. If
824 -- this field is omitted then the serverDHNonce
825 -- field MUST also be omitted. See Section 3.2.3.1.
826 ...
827 }
830 3.2.3.1 Using Diffie-Hellman Key Exchange
832 In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
834 The ContentInfo [RFC3852] structure for the dhSignedData field is
835 filled in as follows:
840 Tung & Zhu Expires November 24, 2005 [Page 15]
841 \f
842 Internet-Draft PKINIT May 2005
845 1. The contentType field of the type ContentInfo is id-signedData
846 (as defined in [RFC3852]), and the content field is a SignedData
847 (as defined in [RFC3852]).
849 2. The eContentType field for the type SignedData is the OID value
850 for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
851 security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }.
853 3. The eContent field for the type SignedData contains the DER
854 encoding of the type KDCDHKeyInfo.
856 4. The signerInfos field of the type SignedData contains a single
857 signerInfo, which contains the signature over the type
858 KDCDHKeyInfo.
860 5. The certificates field of the type SignedData contains
861 certificates intended to facilitate certification path
862 construction, so that the client can verify the KDC's signature
863 over the type KDCDHKeyInfo. The information contained in the
864 trustedCertifiers in the request SHOULD be used by the KDC as
865 hints to guide its selection of an appropriate certificate chain
866 to return to the client. This field may only. be left empty if
867 the KDC public key specified by the kdcPkId field in the PA-PK-
868 AS-REQ was used for signing. Otherwise, for path validation,
869 these certificates SHOULD be sufficient to construct at least one
870 certification path from the KDC certificate to one trust anchor
871 acceptable by the client [CAPATH]. The KDC MUST be capable of
872 including such a set of certificates if configured to do so. The
873 certificates field MUST NOT contain "root" CA certificates.
875 6. If the client included the clientDHNonce field, then the KDC may
876 choose to reuse its DH keys (see Section 3.2.3.1). If the server
877 reuses DH keys then it MUST include an expiration time in the
878 dhKeyExpiration field. Past the point of the expiration time,
879 the signature over the type DHRepInfo is considered expired/
880 invalid. When the server reuses DH keys then it MUST include a
881 serverDHNonce at least as long as the length of keys for the
882 symmetric encryption system used to encrypt the AS reply. Note
883 that including the serverDHNonce changes how the client and
884 server calculate the key to use to encrypt the reply; see below
885 for details. The KDC SHOULD NOT reuse DH keys unless the
886 clientDHNonce field is present in the request.
888 The AS reply key is derived as follows:
896 Tung & Zhu Expires November 24, 2005 [Page 16]
897 \f
898 Internet-Draft PKINIT May 2005
901 1. Both the KDC and the client calculate the shared secret value as
902 follows:
904 a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
905 shared secret value. DHSharedSecret is the value ZZ as
906 described in Section 2.1.1 of [RFC2631].
908 b) When Elliptic Curve Diffie-Hellman (ECDH) (with each party
909 contributing one key pair) is used, let DHSharedSecret be the
910 x-coordinate of the shared secret value (an elliptic curve
911 point). DHSharedSecret is the output of operation ECSVDP-DH as
912 described in Section 7.2.1 of [IEEE1363].
914 DHSharedSecret is first padded with leading zeros such that the
915 size of DHSharedSecret in octets is the same as that of the
916 modulus, then represented as a string of octets in big-endian
917 order.
919 Implementation note: Both the client and the KDC can cache the
920 triple (ya, yb, DHSharedSecret), where ya is the client's public
921 key and yb is the KDC's public key. If both ya and yb are the
922 same in a later exchange, the cached DHSharedSecret can be used.
924 2. Let K be the key-generation seed length [RFC3961] of the AS reply
925 key whose enctype is selected according to [CLAR].
927 3. Define the function octetstring2key() as follows:
929 octetstring2key(x) == random-to-key(K-truncate(
930 SHA1(0x00 | x) |
931 SHA1(0x01 | x) |
932 SHA1(0x02 | x) |
933 ...
934 ))
936 where x is an octet string; | is the concatenation operator; 0x00,
937 0x01, 0x02, etc., are each represented as a single octet; random-
938 to-key() is an operation that generates a protocol key from a
939 bitstring of length K; and K-truncate truncates its input to the
940 first K bits. Both K and random-to-key() are as defined in the
941 kcrypto profile [RFC3961] for the enctype of the AS reply key.
943 4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
944 the serverDHNonce; otherwise, let both n_c and n_k be empty octet
945 strings.
952 Tung & Zhu Expires November 24, 2005 [Page 17]
953 \f
954 Internet-Draft PKINIT May 2005
957 5. The AS reply key k is:
959 k = octetstring2key(DHSharedSecret | n_c | n_k)
962 3.2.3.2 Using Public Key Encryption
964 In this case, the PA-PK-AS-REP contains a ContentInfo structure
965 wrapped in an OCTET STRING. The AS reply key is encrypted in the
966 encKeyPack field, which contains data of type ReplyKeyPack:
968 ReplyKeyPack ::= SEQUENCE {
969 replyKey [0] EncryptionKey,
970 -- Contains the session key used to encrypt the
971 -- enc-part field in the AS-REP.
972 nonce [1] INTEGER (0..4294967295),
973 -- Contains the nonce in the PKAuthenticator of the
974 -- request.
975 ...
976 }
978 The ContentInfo [RFC3852] structure for the encKeyPack field is
979 filled in as follows:
981 1. The contentType field of the type ContentInfo is id-envelopedData
982 (as defined in [RFC3852]), and the content field is an
983 EnvelopedData (as defined in [RFC3852]).
985 2. The contentType field for the type EnvelopedData is id-
986 signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
987 pkcs (1) pkcs7 (7) signedData (2) }.
989 3. The eContentType field for the inner type SignedData (when
990 decrypted from the encryptedContent field for the type
991 EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6)
992 internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }.
994 4. The eContent field for the inner type SignedData contains the DER
995 encoding of the type ReplyKeyPack.
997 5. The signerInfos field of the inner type SignedData contains a
998 single signerInfo, which contains the signature over the type
999 ReplyKeyPack.
1001 6. The certificates field of the inner type SignedData contains
1002 certificates intended to facilitate certification path
1003 construction, so that the client can verify the KDC's signature
1004 over the type ReplyKeyPack. The information contained in the
1008 Tung & Zhu Expires November 24, 2005 [Page 18]
1009 \f
1010 Internet-Draft PKINIT May 2005
1013 trustedCertifiers in the request SHOULD be used by the KDC as
1014 hints to guide its selection of an appropriate certificate chain
1015 to return to the client. This field may only be left empty if
1016 the KDC public key specified by the kdcPkId field in the PA-PK-
1017 AS-REQ was used for signing. Otherwise, for path validation,
1018 these certificates SHOULD be sufficient to construct at least one
1019 certification path from the KDC certificate to one trust anchor
1020 acceptable by the client [CAPATH]. The KDC MUST be capable of
1021 including such a set of certificates if configured to do so. The
1022 certificates field MUST NOT contain "root" CA certificates.
1024 7. The recipientInfos field of the type EnvelopedData is a SET which
1025 MUST contain exactly one member of type KeyTransRecipientInfo.
1026 The encryptedKey of this member contains the temporary key which
1027 is encrypted using the client's public key.
1029 8. The unprotectedAttrs or originatorInfo fields of the type
1030 EnvelopedData MAY be present.
1032 3.2.4 Receipt of KDC Reply
1034 Upon receipt of the KDC's reply, the client proceeds as follows. If
1035 the PA-PK-AS-REP contains the dhSignedData field, the client derives
1036 the AS reply key using the same procedure used by the KDC as defined
1037 in Section 3.2.3.1. Otherwise, the message contains the encKeyPack
1038 field, and the client decrypts and extracts the temporary key in the
1039 encryptedKey field of the member KeyTransRecipientInfo, and then uses
1040 that as the AS reply key.
1042 In either case, the client MUST verify the signature in the
1043 SignedData according to [RFC3852]. The KDC's X.509 certificate MUST
1044 be validated according to [RFC3280]. In addition, unless the client
1045 can otherwise verify that the public key used to verify the KDC's
1046 signature is bound to the KDC of the target realm, the KDC's X.509
1047 certificate MUST contain a Subject Alternative Name extension
1048 [RFC3280] carrying an AnotherName whose type-id is id-pksan (as
1049 defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
1050 matches the name of the TGS of the target realm (as defined in
1051 Section 7.3 of [CLAR]).
1053 Based on local policy, the client MAY require that the KDC
1054 certificate contains the EKU KeyPurposeId [RFC3280] id-pkkdcekuoid:
1056 id-pkkdcekuoid OBJECT IDENTIFIER ::=
1057 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
1058 pkinit(3) pkkdcekuoid(5) }
1059 -- Signing KDC responses.
1060 -- Key usage bits that MUST be consistent:
1064 Tung & Zhu Expires November 24, 2005 [Page 19]
1065 \f
1066 Internet-Draft PKINIT May 2005
1069 -- digitalSignature.
1071 If all applicable checks are satisfied, the client then decrypts the
1072 enc-part field of the KDC-REP in the AS-REP using the AS reply key,
1073 and then proceeds as described in [CLAR].
1075 Implementation note: CAs issuing KDC certificates SHOULD place all
1076 "short" and "fully-qualified" Kerberos realm names of the KDC (one
1077 per GeneralName [RFC3280]) into the KDC certificate to allow maximum
1078 flexibility.
1080 3.3 Interoperability Requirements
1082 The client MUST be capable of sending a set of certificates
1083 sufficient to allow the KDC to construct a certification path for the
1084 client's certificate, if the correct set of certificates is provided
1085 through configuration or policy.
1087 If the client sends all the X.509 certificates on a certification
1088 path to a trust anchor acceptable by the KDC, and the KDC can not
1089 verify the client's public key otherwise, the KDC MUST be able to
1090 process path validation for the client's certificate based on the
1091 certificates in the request.
1093 The KDC MUST be capable of sending a set of certificates sufficient
1094 to allow the client to construct a certification path for the KDC's
1095 certificate, if the correct set of certificates is provided through
1096 configuration or policy.
1098 If the KDC sends all the X.509 certificates on a certification path
1099 to a trust anchor acceptable by the client, and the client can not
1100 verify the KDC's public key otherwise, the client MUST be able to
1101 process path validation for the KDC's certificate based on the
1102 certificates in the reply.
1104 3.4 KDC Indication of PKINIT Support
1106 If pre-authentication is required, but was not present in the
1107 request, per [CLAR] an error message with the code
1108 KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
1109 stored in the e-data field of the KRB-ERROR message to specify which
1110 pre-authentication mechanisms are acceptable. The KDC can then
1111 indicate the support of PKINIT by including an empty element whose
1112 padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
1114 Otherwise if it is required by the KDC's local policy that the client
1115 must be pre-authenticated using the pre-authentication mechanism
1116 specified in this document, but no PKINIT pre-authentication was
1120 Tung & Zhu Expires November 24, 2005 [Page 20]
1121 \f
1122 Internet-Draft PKINIT May 2005
1125 present in the request, an error message with the code
1126 KDC_ERR_PREAUTH_FAILED SHOULD be returned.
1128 KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
1129 the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
1130 STRING), and clients MUST ignore this and any other value. Future
1131 extensions to this protocol may specify other data to send instead of
1132 an empty OCTET STRING.
1134 4. Security Considerations
1136 PKINIT raises certain security considerations beyond those that can
1137 be regulated strictly in protocol definitions. We will address them
1138 in this section.
1140 PKINIT extends the cross-realm model to the public-key
1141 infrastructure. Users of PKINIT must understand security policies
1142 and procedures appropriate to the use of Public Key Infrastructures
1143 [RFC3280].
1145 Standard Kerberos allows the possibility of interactions between
1146 cryptosystems of varying strengths; this document adds interactions
1147 with public-key cryptosystems to Kerberos. Some administrative
1148 policies may allow the use of relatively weak public keys. Using
1149 such keys to wrap data encrypted under stronger conventional
1150 cryptosystems may be inappropriate.
1152 PKINIT requires keys for symmetric cryptosystems to be generated.
1153 Some such systems contain "weak" keys. For recommendations regarding
1154 these weak keys, see [CLAR].
1156 PKINIT allows the use of the same RSA key pair for encryption and
1157 signing when doing RSA encryption based key delivery. This is not
1158 recommended usage of RSA keys [RFC3447], by using DH based key
1159 delivery this is avoided.
1161 Care should be taken in how certificates are chosen for the purposes
1162 of authentication using PKINIT. Some local policies may require that
1163 key escrow be used for certain certificate types. Deployers of
1164 PKINIT should be aware of the implications of using certificates that
1165 have escrowed keys for the purposes of authentication. Because
1166 signing only certificates are normally not escrowed, by using DH
1167 based key delivery this is avoided.
1169 PKINIT does not provide for a "return routability" test to prevent
1170 attackers from mounting a denial-of-service attack on the KDC by
1171 causing it to perform unnecessary and expensive public-key
1172 operations. Strictly speaking, this is also true of standard
1176 Tung & Zhu Expires November 24, 2005 [Page 21]
1177 \f
1178 Internet-Draft PKINIT May 2005
1181 Kerberos, although the potential cost is not as great, because
1182 standard Kerberos does not make use of public-key cryptography. By
1183 using DH based key delivery and reusing DH keys, the necessary crypto
1184 processing cost per request can be minimized.
1186 The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
1187 permit empty SEQUENCEs to be encoded. Such empty sequences may only
1188 be used if the KDC itself vouches for the user's certificate.
1190 5. Acknowledgements
1192 The following people have made significant contributions to this
1193 draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist
1194 Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle,
1195 Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik
1196 Jaganathan, Chaskiel M Grundman and Stefan Santesson.
1198 Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and
1199 Jonathan Trostle who wrote earlier versions of this document.
1201 The authors are indebted to the Kerberos working group chair Jeffrey
1202 Hutzelman who kept track of various issues and was enormously helpful
1203 during the creation of this document.
1205 Some of the ideas on which this document is based arose during
1206 discussions over several years between members of the SAAG, the IETF
1207 CAT working group, and the PSRG, regarding integration of Kerberos
1208 and SPX. Some ideas have also been drawn from the DASS system.
1209 These changes are by no means endorsed by these groups. This is an
1210 attempt to revive some of the goals of those groups, and this
1211 document approaches those goals primarily from the Kerberos
1212 perspective.
1214 Lastly, comments from groups working on similar ideas in DCE have
1215 been invaluable.
1217 6. IANA Considerations
1219 This document has no actions for IANA.
1221 7. References
1223 7.1 Normative References
1225 [CLAR] RFC-Editor: To be replaced by RFC number for draft-ietf-
1226 krb-wg-kerberos-clarifications. Work in Progress.
1231 Tung & Zhu Expires November 24, 2005 [Page 22]
1232 \f
1233 Internet-Draft PKINIT May 2005
1236 [IEEE1363]
1237 IEEE, "Standard Specifications for Public Key
1238 Cryptography", IEEE 1363, 2000.
1240 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1241 Requirement Levels", BCP 14, RFC 2119, March 1997.
1243 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
1244 RFC 2412, November 1998.
1246 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
1247 RFC 2631, June 1999.
1249 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
1250 Identifiers for the Internet X.509 Public Key
1251 Infrastructure Certificate and Certificate Revocation List
1252 (CRL) Profile", RFC 3279, April 2002.
1254 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
1255 X.509 Public Key Infrastructure Certificate and
1256 Certificate Revocation List (CRL) Profile", RFC 3280,
1257 April 2002.
1259 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
1260 Algorithms", RFC 3370, August 2002.
1262 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
1263 Standards (PKCS) #1: RSA Cryptography Specifications
1264 Version 2.1", RFC 3447, February 2003.
1266 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
1267 Diffie-Hellman groups for Internet Key Exchange (IKE)",
1268 RFC 3526, May 2003.
1270 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES)
1271 Encryption Algorithm in Cryptographic Message Syntax
1272 (CMS)", RFC 3565, July 2003.
1274 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
1275 Public Keys Used For Exchanging Symmetric Keys", BCP 86,
1276 RFC 3766, April 2004.
1278 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
1279 RFC 3852, July 2004.
1281 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
1282 Kerberos 5", RFC 3961, February 2005.
1287 Tung & Zhu Expires November 24, 2005 [Page 23]
1288 \f
1289 Internet-Draft PKINIT May 2005
1292 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES)
1293 Encryption for Kerberos 5", RFC 3962, February 2005.
1295 [X.509-97] ITU-T. Recommendation X.509: The Directory - Authentication
1296 Framework. 1997.
1298 [X690] ASN.1 encoding rules: Specification of Basic Encoding
1299 Rules (BER), Canonical Encoding Rules (CER) and
1300 Distinguished Encoding Rules (DER), ITU-T Recommendation
1301 X.690 (1997) | ISO/IEC International Standard
1302 8825-1:1998.
1304 7.2 Informative References
1306 [CAPATH] RFC-Editor: To be replaced by RFC number for draft-ietf-
1307 pkix-certpathbuild. Work in Progress.
1309 [LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
1310 Sizes", Journal of Cryptology 14 (2001) 255-293.
1312 [ODL99] Odlyzko, A., "Discrete logarithms: The past and the
1313 future, Designs, Codes, and Cryptography (1999)".
1316 Authors' Addresses
1318 Brian Tung
1319 USC Information Sciences Institute
1320 4676 Admiralty Way Suite 1001, Marina del Rey CA
1321 Marina del Rey, CA 90292
1322 US
1324 Email: brian@isi.edu
1327 Larry Zhu
1328 Microsoft Corporation
1329 One Microsoft Way
1330 Redmond, WA 98052
1331 US
1333 Email: lzhu@microsoft.com
1335 Appendix A. PKINIT ASN.1 Module
1339 Tung & Zhu Expires November 24, 2005 [Page 24]
1340 \f
1341 Internet-Draft PKINIT May 2005
1344 KerberosV5-PK-INIT-SPEC {
1345 iso(1) identified-organization(3) dod(6) internet(1)
1346 security(5) kerberosV5(2) modules(4) pkinit(5)
1347 } DEFINITIONS EXPLICIT TAGS ::= BEGIN
1349 IMPORTS
1350 SubjectPublicKeyInfo, AlgorithmIdentifier
1351 FROM PKIX1Explicit88 { iso (1)
1352 identified-organization (3) dod (6) internet (1)
1353 security (5) mechanisms (5) pkix (7) id-mod (0)
1354 id-pkix1-explicit (18) }
1355 -- As defined in RFC 3280.
1357 DomainParameters, EcpkParameters
1358 FROM PKIX1Algorithms88 { iso(1)
1359 identified-organization(3) dod(6)
1360 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
1361 id-mod-pkix1-algorithms(17) }
1362 -- As defined in RFC 3279.
1364 KerberosTime, TYPED-DATA, PrincipalName, Realm, EncryptionKey
1365 FROM KerberosV5Spec2 { iso(1) identified-organization(3)
1366 dod(6) internet(1) security(5) kerberosV5(2)
1367 modules(4) krb5spec2(2) } ;
1369 id-pkinit OBJECT IDENTIFIER ::=
1370 { iso (1) org (3) dod (6) internet (1) security (5)
1371 kerberosv5 (2) pkinit (3) }
1373 id-pkauthdata OBJECT IDENTIFIER ::= { id-pkinit 1 }
1374 id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 }
1375 id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 }
1376 id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 }
1377 id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 }
1379 pa-pk-as-req INTEGER ::= 16
1380 pa-pk-as-rep INTEGER ::= 17
1382 ad-initial-verified-cas INTEGER ::= 9
1384 td-trusted-certifiers INTEGER ::= 104
1385 td-invalid-certificates INTEGER ::= 105
1386 td-dh-parameters INTEGER ::= 109
1388 PA-PK-AS-REQ ::= SEQUENCE {
1389 signedAuthPack [0] IMPLICIT OCTET STRING,
1390 -- Contains a CMS type ContentInfo encoded
1391 -- according to [RFC3852].
1395 Tung & Zhu Expires November 24, 2005 [Page 25]
1396 \f
1397 Internet-Draft PKINIT May 2005
1400 -- The contentType field of the type ContentInfo
1401 -- is id-signedData (1.2.840.113549.1.7.2),
1402 -- and the content field is a SignedData.
1403 -- The eContentType field for the type SignedData is
1404 -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
1405 -- eContent field contains the DER encoding of the
1406 -- type AuthPack.
1407 -- AuthPack is defined below.
1408 trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,
1409 -- A list of CAs, trusted by the client, that can
1410 -- be used to certify the KDC.
1411 -- Each TrustedCA identifies a CA or a CA
1412 -- certificate (thereby its public key).
1413 -- The information contained in the
1414 -- trustedCertifiers SHOULD be used by the KDC as
1415 -- hints to guide its selection of an appropriate
1416 -- certificate chain to return to the client.
1417 kdcPkId [2] IMPLICIT OCTET STRING
1418 OPTIONAL,
1419 -- Contains a CMS type SignerIdentifier encoded
1420 -- according to [RFC3852].
1421 -- Identifies, if present, a particular KDC
1422 -- public key that the client already has.
1423 ...
1424 }
1426 DHNonce ::= OCTET STRING
1428 TrustedCA ::= SEQUENCE {
1429 caName [0] IMPLICIT OCTET STRING,
1430 -- Contains a PKIX type Name encoded according to
1431 -- [RFC3280].
1432 -- Identifies a CA by the CA's distinguished subject
1433 -- name.
1434 certificateSerialNumber [1] INTEGER OPTIONAL,
1435 -- Specifies the CA certificate's serial number.
1436 -- The defintion of the certificate serial number
1437 -- is taken from X.509 [X.509-97].
1438 subjectKeyIdentifier [2] OCTET STRING OPTIONAL,
1439 -- Identifies the CA's public key by a key
1440 -- identifier. When an X.509 certificate is
1441 -- referenced, this key identifier matches the X.509
1442 -- subjectKeyIdentifier extension value. When other
1443 -- certificate formats are referenced, the documents
1444 -- that specify the certificate format and their use
1445 -- with the CMS must include details on matching the
1446 -- key identifier to the appropriate certificate
1447 -- field.
1451 Tung & Zhu Expires November 24, 2005 [Page 26]
1452 \f
1453 Internet-Draft PKINIT May 2005
1456 ...
1457 }
1460 AuthPack ::= SEQUENCE {
1461 pkAuthenticator [0] PKAuthenticator,
1462 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
1463 -- Type SubjectPublicKeyInfo is defined in
1464 -- [RFC3280].
1465 -- Specifies Diffie-Hellman domain parameters
1466 -- and the client's public key value [IEEE1363].
1467 -- The DH public key value is encoded as a BIT
1468 -- STRING, as specified in Section 2.3.3 of
1469 -- [RFC3279].
1470 -- This field is present only if the client wishes
1471 -- to use the Diffie-Hellman key agreement method.
1472 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
1473 OPTIONAL,
1474 -- Type AlgorithmIdentifier is defined in
1475 -- [RFC3280].
1476 -- List of CMS encryption types supported by the
1477 -- client in order of (decreasing) preference.
1478 clientDHNonce [3] DHNonce OPTIONAL,
1479 -- Present only if the client indicates that it
1480 -- wishes to reuse DH keys or to allow the KDC to
1481 -- do so.
1482 ...
1483 }
1485 PKAuthenticator ::= SEQUENCE {
1486 cusec [0] INTEGER (0..999999),
1487 ctime [1] KerberosTime,
1488 -- cusec and ctime are used as in [CLAR], for replay
1489 -- prevention.
1490 nonce [2] INTEGER (0..4294967295),
1491 -- Chosen randomly; This nonce does not need to
1492 -- match with the nonce in the KDC-REQ-BODY.
1493 paChecksum [3] OCTET STRING,
1494 -- Contains the SHA1 checksum, performed over
1495 -- KDC-REQ-BODY.
1496 ...
1497 }
1499 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TrustedCA
1500 -- Identifies a list of CAs trusted by the KDC.
1501 -- Each TrustedCA identifies a CA or a CA
1502 -- certificate (thereby its public key).
1507 Tung & Zhu Expires November 24, 2005 [Page 27]
1508 \f
1509 Internet-Draft PKINIT May 2005
1512 TD-INVALID-CERTIFICATES ::= SEQUENCE OF OCTET STRING
1513 -- Each OCTET STRING contains a CMS type
1514 -- IssuerAndSerialNumber encoded according to
1515 -- [RFC3852].
1516 -- Each IssuerAndSerialNumber identifies a
1517 -- certificate (sent by the client) with an invalid
1518 -- signature.
1520 KRB5PrincipalName ::= SEQUENCE {
1521 realm [0] Realm,
1522 principalName [1] PrincipalName
1523 }
1525 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF TrustedCA
1526 -- Identifies the certification path based on which
1527 -- the client certificate was validated.
1528 -- Each TrustedCA identifies a CA or a CA
1529 -- certificate (thereby its public key).
1531 PA-PK-AS-REP ::= CHOICE {
1532 dhInfo [0] DHRepInfo,
1533 -- Selected when Diffie-Hellman key exchange is
1534 -- used.
1535 encKeyPack [1] IMPLICIT OCTET STRING,
1536 -- Selected when public key encryption is used.
1537 -- Contains a CMS type ContentInfo encoded
1538 -- according to [RFC3852].
1539 -- The contentType field of the type ContentInfo is
1540 -- id-envelopedData (1.2.840.113549.1.7.3).
1541 -- The content field is an EnvelopedData.
1542 -- The contentType field for the type EnvelopedData
1543 -- is id-signedData (1.2.840.113549.1.7.2).
1544 -- The eContentType field for the inner type
1545 -- SignedData (when unencrypted) is id-pkrkeydata
1546 -- (1.2.840.113549.1.7.3) and the eContent field
1547 -- contains the DER encoding of the type
1548 -- ReplyKeyPack.
1549 -- ReplyKeyPack is defined below.
1550 ...
1551 }
1553 DHRepInfo ::= SEQUENCE {
1554 dhSignedData [0] IMPLICIT OCTET STRING,
1555 -- Contains a CMS type ContentInfo encoded according
1556 -- to [RFC3852].
1557 -- The contentType field of the type ContentInfo is
1558 -- id-signedData (1.2.840.113549.1.7.2), and the
1559 -- content field is a SignedData.
1563 Tung & Zhu Expires November 24, 2005 [Page 28]
1564 \f
1565 Internet-Draft PKINIT May 2005
1568 -- The eContentType field for the type SignedData is
1569 -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
1570 -- eContent field contains the DER encoding of the
1571 -- type KDCDHKeyInfo.
1572 -- KDCDHKeyInfo is defined below.
1573 serverDHNonce [1] DHNonce OPTIONAL
1574 -- Present if and only if dhKeyExpiration is
1575 -- present.
1576 }
1578 KDCDHKeyInfo ::= SEQUENCE {
1579 subjectPublicKey [0] BIT STRING,
1580 -- KDC's DH public key.
1581 -- The DH public key value is encoded as a BIT
1582 -- STRING, as specified in Section 2.3.3 of
1583 -- [RFC3279].
1584 nonce [1] INTEGER (0..4294967295),
1585 -- Contains the nonce in the PKAuthenticator of the
1586 -- request if DH keys are NOT reused,
1587 -- 0 otherwise.
1588 dhKeyExpiration [2] KerberosTime OPTIONAL,
1589 -- Expiration time for KDC's key pair,
1590 -- present if and only if DH keys are reused. If
1591 -- this field is omitted then the serverDHNonce
1592 -- field MUST also be omitted.
1593 ...
1594 }
1596 ReplyKeyPack ::= SEQUENCE {
1597 replyKey [0] EncryptionKey,
1598 -- Contains the session key used to encrypt the
1599 -- enc-part field in the AS-REP.
1600 nonce [1] INTEGER (0..4294967295),
1601 -- Contains the nonce in the PKAuthenticator of the
1602 -- request.
1603 ...
1604 }
1606 TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
1607 -- Each AlgorithmIdentifier specifies a set of
1608 -- Diffie-Hellman domain parameters [IEEE1363].
1609 -- This list is in decreasing preference order.
1610 END
1619 Tung & Zhu Expires November 24, 2005 [Page 29]
1620 \f
1621 Internet-Draft PKINIT May 2005
1624 Intellectual Property Statement
1626 The IETF takes no position regarding the validity or scope of any
1627 Intellectual Property Rights or other rights that might be claimed to
1628 pertain to the implementation or use of the technology described in
1629 this document or the extent to which any license under such rights
1630 might or might not be available; nor does it represent that it has
1631 made any independent effort to identify any such rights. Information
1632 on the procedures with respect to rights in RFC documents can be
1633 found in BCP 78 and BCP 79.
1635 Copies of IPR disclosures made to the IETF Secretariat and any
1636 assurances of licenses to be made available, or the result of an
1637 attempt made to obtain a general license or permission for the use of
1638 such proprietary rights by implementers or users of this
1639 specification can be obtained from the IETF on-line IPR repository at
1640 http://www.ietf.org/ipr.
1642 The IETF invites any interested party to bring to its attention any
1643 copyrights, patents or patent applications, or other proprietary
1644 rights that may cover technology that may be required to implement
1645 this standard. Please address the information to the IETF at
1646 ietf-ipr@ietf.org.
1649 Disclaimer of Validity
1651 This document and the information contained herein are provided on an
1652 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1653 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1654 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1655 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1656 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1657 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1660 Copyright Statement
1662 Copyright (C) The Internet Society (2005). This document is subject
1663 to the rights, licenses and restrictions contained in BCP 78, and
1664 except as set forth therein, the authors retain all their rights.
1667 Acknowledgment
1669 Funding for the RFC Editor function is currently provided by the
1670 Internet Society.
1675 Tung & Zhu Expires November 24, 2005 [Page 30]
1676 \f