| blob | 0493302602e11a90724fa5c3d558e1d9bd597f3b |
1 NETWORK WORKING GROUP B. Tung
2 Internet-Draft USC Information Sciences Institute
3 Expires: November 24, 2005 L. Zhu
4 Microsoft Corporation
5 May 23, 2005
8 Public Key Cryptography for Initial Authentication in Kerberos
9 draft-ietf-cat-kerberos-pk-init
11 Status of this Memo
13 This document is an Internet-Draft and is subject to all provisions
14 of Section 3 of RFC 3667.
16 By submitting this Internet-Draft, each author represents that any
17 applicable patent or other IPR claims of which he or she is aware
18 have been or will be disclosed, and any of which he or she becomes
19 aware will be disclosed, in accordance with Section 6 of BCP 79.
21 Internet-Drafts are working documents of the Internet Engineering
22 Task Force (IETF), its areas, and its working groups. Note that
23 other groups may also distribute working documents as Internet-
24 Drafts.
26 Internet-Drafts are draft documents valid for a maximum of six months
27 and may be updated, replaced, or obsoleted by other documents at any
28 time. It is inappropriate to use Internet-Drafts as reference
29 material or to cite them other than as "work in progress."
31 The list of current Internet-Drafts can be accessed at
32 http://www.ietf.org/ietf/1id-abstracts.txt.
34 The list of Internet-Draft Shadow Directories can be accessed at
35 http://www.ietf.org/shadow.html.
37 This Internet-Draft will expire on November 24, 2005.
39 Copyright Notice
41 Copyright (C) The Internet Society (2005).
43 Abstract
45 This document describes protocol extensions (hereafter called PKINIT)
46 to the Kerberos protocol specification. These extensions provide a
47 method for integrating public key cryptography into the initial
48 authentication exchange, by using asymmetric-key signature and/or
49 encryption algorithms in pre-authentication data fields.
53 Tung & Zhu Expires November 24, 2005 [Page 1]
54 \f
55 Internet-Draft PKINIT May 2005
58 Table of Contents
60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
61 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
62 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
63 3.1 Definitions, Requirements, and Constants . . . . . . . . . 4
64 3.1.1 Required Algorithms . . . . . . . . . . . . . . . . . 4
65 3.1.2 Defined Message and Encryption Types . . . . . . . . . 5
66 3.1.3 Algorithm Identifiers . . . . . . . . . . . . . . . . 6
67 3.2 PKINIT Pre-authentication Syntax and Use . . . . . . . . . 7
68 3.2.1 Generation of Client Request . . . . . . . . . . . . . 7
69 3.2.2 Receipt of Client Request . . . . . . . . . . . . . . 10
70 3.2.3 Generation of KDC Reply . . . . . . . . . . . . . . . 13
71 3.2.4 Receipt of KDC Reply . . . . . . . . . . . . . . . . . 19
72 3.3 Interoperability Requirements . . . . . . . . . . . . . . 20
73 3.4 KDC Indication of PKINIT Support . . . . . . . . . . . . . 20
74 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21
75 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
78 7.1 Normative References . . . . . . . . . . . . . . . . . . . 22
79 7.2 Informative References . . . . . . . . . . . . . . . . . . 24
80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
81 A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 25
82 Intellectual Property and Copyright Statements . . . . . . . . 30
109 Tung & Zhu Expires November 24, 2005 [Page 2]
110 \f
111 Internet-Draft PKINIT May 2005
114 1. Introduction
116 A client typically authenticates itself to a service in Kerberos
117 using three distinct though related exchanges. First, the client
118 requests a ticket-granting ticket (TGT) from the Kerberos
119 authentication server (AS). Then, it uses the TGT to request a
120 service ticket from the Kerberos ticket-granting server (TGS).
121 Usually, the AS and TGS are integrated in a single device known as a
122 Kerberos Key Distribution Center, or KDC. Finally, the client uses
123 the service ticket to authenticate itself to the service.
125 The advantage afforded by the TGT is that the client exposes his
126 long-term secrets only once. The TGT and its associated session key
127 can then be used for any subsequent service ticket requests. One
128 result of this is that all further authentication is independent of
129 the method by which the initial authentication was performed.
130 Consequently, initial authentication provides a convenient place to
131 integrate public-key cryptography into Kerberos authentication.
133 As defined in [CLAR], Kerberos authentication exchanges use
134 symmetric-key cryptography, in part for performance. One
135 disadvantage of using symmetric-key cryptography is that the keys
136 must be shared, so that before a client can authenticate itself, he
137 must already be registered with the KDC.
139 Conversely, public-key cryptography (in conjunction with an
140 established Public Key Infrastructure) permits authentication without
141 prior registration with a KDC. Adding it to Kerberos allows the
142 widespread use of Kerberized applications by clients without
143 requiring them to register first with a KDC--a requirement that has
144 no inherent security benefit.
146 As noted above, a convenient and efficient place to introduce public-
147 key cryptography into Kerberos is in the initial authentication
148 exchange. This document describes the methods and data formats for
149 integrating public-key cryptography into Kerberos initial
150 authentication.
152 2. Conventions Used in This Document
154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
156 document are to be interpreted as described in [RFC2119].
158 Both the AS and the TGS are referred to as the KDC.
160 In this document, the encryption key used to encrypt the enc-part
161 field of the KDC-REP in the AS-REP [CLAR] is referred to as the AS
165 Tung & Zhu Expires November 24, 2005 [Page 3]
166 \f
167 Internet-Draft PKINIT May 2005
170 reply key.
172 3. Extensions
174 This section describes extensions to [CLAR] for supporting the use of
175 public-key cryptography in the initial request for a ticket.
177 Briefly, this document defines the following extensions to [CLAR]:
179 1. The client indicates the use of public-key authentication by
180 including a special preauthenticator in the initial request. This
181 preauthenticator contains the client's public-key data and a
182 signature.
184 2. The KDC tests the client's request against its authentication
185 policy and trusted Certification Authorities (CAs).
187 3. If the request passes the verification tests, the KDC replies as
188 usual, but the reply is encrypted using either:
190 a. a key generated through a Diffie-Hellman (DH) key exchange
191 [RFC2631] [IEEE1363] with the client, signed using the KDC's
192 signature key; or
194 b. a symmetric encryption key, signed using the KDC's signature
195 key and encrypted using the client's public key.
197 Any keying material required by the client to obtain the
198 encryption key for decrypting the KDC reply is returned in a pre-
199 authentication field accompanying the usual reply.
201 4. The client validates the KDC's signature, obtains the encryption
202 key, decrypts the reply, and then proceeds as usual.
204 Section 3.1 of this document enumerates the required algorithms and
205 necessary extension message types. Section 3.2 describes the
206 extension messages in greater detail.
208 3.1 Definitions, Requirements, and Constants
210 3.1.1 Required Algorithms
212 All PKINIT implementations MUST support the following algorithms:
214 o AS reply key enctype: AES256-CTS-HMAC-SHA1-96 etype [RFC3962].
221 Tung & Zhu Expires November 24, 2005 [Page 4]
222 \f
223 Internet-Draft PKINIT May 2005
226 o Signature algorithm: sha-1WithRSAEncryption [RFC3279].
228 o AS reply key delivery method: Diffie-Hellman key exchange
229 [RFC2631].
232 3.1.2 Defined Message and Encryption Types
234 PKINIT makes use of the following new pre-authentication types:
236 PA_PK_AS_REQ 16
237 PA_PK_AS_REP 17
239 PKINIT also makes use of the following new authorization data type:
241 AD_INITIAL_VERIFIED_CAS 9
243 PKINIT introduces the following new error codes:
245 KDC_ERR_CLIENT_NOT_TRUSTED 62
246 KDC_ERR_INVALID_SIG 64
247 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65
248 KDC_ERR_CANT_VERIFY_CERTIFICATE 70
249 KDC_ERR_INVALID_CERTIFICATE 71
250 KDC_ERR_REVOKED_CERTIFICATE 72
251 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
252 KDC_ERR_CLIENT_NAME_MISMATCH 75
253 KDC_ERR_INCONSISTENT_KEY_PURPOSE 76
255 PKINIT uses the following typed data types for errors:
257 TD_TRUSTED_CERTIFIERS 104
258 TD_INVALID_CERTIFICATES 105
259 TD_DH_PARAMETERS 109
261 PKINIT defines the following encryption types, for use in the AS-REQ
262 message to indicate acceptance of the corresponding algorithms that
263 can used by Cryptographic Message Syntax (CMS) [RFC3852] messages in
264 the reply:
266 dsaWithSHA1-CmsOID 9
267 md5WithRSAEncryption-CmsOID 10
268 sha1WithRSAEncryption-CmsOID 11
269 rc2CBC-EnvOID 12
270 rsaEncryption-EnvOID (PKCS1 v1.5) 13
271 rsaES-OAEP-EnvOID (PKCS1 v2.0) 14
272 des-ede3-cbc-EnvOID 15
277 Tung & Zhu Expires November 24, 2005 [Page 5]
278 \f
279 Internet-Draft PKINIT May 2005
282 The ASN.1 module for all structures defined in this document (plus
283 IMPORT statements for all imported structures) is given in
284 Appendix A.
286 All structures defined in or imported into this document MUST be
287 encoded using Distinguished Encoding Rules (DER) [X690] (unless
288 otherwise noted). All data structures carried in OCTET STRINGs must
289 be encoded according to the rules specified in corresponding
290 specifications.
292 Interoperability note: Some implementations may not be able to decode
293 wrapped CMS objects encoded with BER but not DER; specifically, they
294 may not be able to decode infinite length encodings. To maximize
295 interoperability, implementers SHOULD encode CMS objects used in
296 PKINIT with DER.
298 3.1.3 Algorithm Identifiers
300 PKINIT does not define, but does make use of, the following algorithm
301 identifiers.
303 PKINIT uses the following algorithm identifiers for Diffie-Hellman
304 key agreement [RFC3279]:
306 dhpublicnumber (Modular Exponential Diffie-Hellman [RFC2631])
307 id-ecPublicKey (Elliptic Curve Diffie-Hellman [IEEE1363])
309 PKINIT uses the following signature algorithm identifiers [RFC3279]:
311 sha-1WithRSAEncryption (RSA with SHA1)
312 md5WithRSAEncryption (RSA with MD5)
313 id-dsa-with-sha1 (DSA with SHA1)
315 PKINIT uses the following encryption algorithm identifiers [RFC3447]
316 for encrypting the temporary key with a public key:
318 rsaEncryption (PKCS1 v1.5)
319 id-RSAES-OAEP (PKCS1 v2.0)
321 PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565]
322 for encrypting the AS reply key with the temporary key:
324 des-ede3-cbc (three-key 3DES, CBC mode)
325 rc2-cbc (RC2, CBC mode)
326 id-aes256-CBC (AES-256, CBC mode)
333 Tung & Zhu Expires November 24, 2005 [Page 6]
334 \f
335 Internet-Draft PKINIT May 2005
338 3.2 PKINIT Pre-authentication Syntax and Use
340 This section defines the syntax and use of the various pre-
341 authentication fields employed by PKINIT.
343 3.2.1 Generation of Client Request
345 The initial authentication request (AS-REQ) is sent as per [CLAR]; in
346 addition, a pre-authentication data element, whose padata-type is
347 PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
348 type PA-PK-AS-REQ, is included.
350 PA-PK-AS-REQ ::= SEQUENCE {
351 signedAuthPack [0] IMPLICIT OCTET STRING,
352 -- Contains a CMS type ContentInfo encoded
353 -- according to [RFC3852].
354 -- The contentType field of the type ContentInfo
355 -- is id-signedData (1.2.840.113549.1.7.2),
356 -- and the content field is a SignedData.
357 -- The eContentType field for the type SignedData is
358 -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
359 -- eContent field contains the DER encoding of the
360 -- type AuthPack.
361 -- AuthPack is defined below.
362 trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,
363 -- A list of CAs, trusted by the client, that can
364 -- be used to certify the KDC.
365 -- Each TrustedCA identifies a CA or a CA
366 -- certificate (thereby its public key).
367 -- The information contained in the
368 -- trustedCertifiers SHOULD be used by the KDC as
369 -- hints to guide its selection of an appropriate
370 -- certificate chain to return to the client.
371 kdcPkId [2] IMPLICIT OCTET STRING
372 OPTIONAL,
373 -- Contains a CMS type SignerIdentifier encoded
374 -- according to [RFC3852].
375 -- Identifies, if present, a particular KDC
376 -- public key that the client already has.
377 ...
378 }
380 DHNonce ::= OCTET STRING
382 TrustedCA ::= SEQUENCE {
383 caName [0] IMPLICIT OCTET STRING,
384 -- Contains a PKIX type Name encoded according to
385 -- [RFC3280].
389 Tung & Zhu Expires November 24, 2005 [Page 7]
390 \f
391 Internet-Draft PKINIT May 2005
394 -- Identifies a CA by the CA's distinguished subject
395 -- name.
396 certificateSerialNumber [1] INTEGER OPTIONAL,
397 -- Specifies the CA certificate's serial number.
398 -- The defintion of the certificate serial number
399 -- is taken from X.509 [X.509-97].
400 subjectKeyIdentifier [2] OCTET STRING OPTIONAL,
401 -- Identifies the CA's public key by a key
402 -- identifier. When an X.509 certificate is
403 -- referenced, this key identifier matches the X.509
404 -- subjectKeyIdentifier extension value. When other
405 -- certificate formats are referenced, the documents
406 -- that specify the certificate format and their use
407 -- with the CMS must include details on matching the
408 -- key identifier to the appropriate certificate
409 -- field.
410 ...
411 }
413 AuthPack ::= SEQUENCE {
414 pkAuthenticator [0] PKAuthenticator,
415 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
416 -- Type SubjectPublicKeyInfo is defined in
417 -- [RFC3280].
418 -- Specifies Diffie-Hellman domain parameters
419 -- and the client's public key value [IEEE1363].
420 -- The DH public key value is encoded as a BIT
421 -- STRING, as specified in Section 2.3.3 of
422 -- [RFC3279].
423 -- This field is present only if the client wishes
424 -- to use the Diffie-Hellman key agreement method.
425 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
426 OPTIONAL,
427 -- Type AlgorithmIdentifier is defined in
428 -- [RFC3280].
429 -- List of CMS encryption types supported by the
430 -- client in order of (decreasing) preference.
431 clientDHNonce [3] DHNonce OPTIONAL,
432 -- Present only if the client indicates that it
433 -- wishes to reuse DH keys or to allow the KDC to
434 -- do so (see Section 3.2.3.1).
435 ...
436 }
438 PKAuthenticator ::= SEQUENCE {
439 cusec [0] INTEGER (0..999999),
440 ctime [1] KerberosTime,
441 -- cusec and ctime are used as in [CLAR], for replay
445 Tung & Zhu Expires November 24, 2005 [Page 8]
446 \f
447 Internet-Draft PKINIT May 2005
450 -- prevention.
451 nonce [2] INTEGER (0..4294967295),
452 -- Chosen randomly; This nonce does not need to
453 -- match with the nonce in the KDC-REQ-BODY.
454 paChecksum [3] OCTET STRING,
455 -- Contains the SHA1 checksum, performed over
456 -- KDC-REQ-BODY.
457 ...
458 }
460 The ContentInfo [RFC3852] structure for the signedAuthPack field is
461 filled out as follows:
463 1. The contentType field of the type ContentInfo is id-signedData
464 (as defined in [RFC3852]), and the content field is a SignedData
465 (as defined in [RFC3852]).
467 2. The eContentType field for the type SignedData is id-pkauthdata:
468 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
469 pkinit(3) pkauthdata(1) }.
471 3. The eContent field for the type SignedData contains the DER
472 encoding of the type AuthPack.
474 4. The signerInfos field of the type SignedData contains a single
475 signerInfo, which contains the signature over the type AuthPack.
477 5. The certificates field of the type SignedData contains
478 certificates intended to facilitate certification path
479 construction, so that the KDC can verify the signature over the
480 type AuthPack. For path validation, these certificates SHOULD be
481 sufficient to construct at least one certification path from the
482 client certificate to one trust anchor acceptable by the KDC
483 [CAPATH]. The client MUST be capable of including such a set of
484 certificates if configured to do so. The certificates field MUST
485 NOT contain "root" CA certificates.
487 6. The client's Diffie-Hellman public value (clientPublicValue) is
488 included if and only if the client wishes to use the Diffie-
489 Hellman key agreement method. The Diffie-Hellman domain
490 parameters [IEEE1363] for the client's public key are specified
491 in the algorithm field of the type SubjectPublicKeyInfo [RFC3279]
492 and the client's Diffie-Hellman public key value is mapped to a
493 subjectPublicKey (a BIT STRING) according to [RFC3279]. When
494 using the Diffie-Hellman key agreement method, implementations
495 MUST support Oakley 1024-bit Modular Exponential (MODP) well-
496 known group 2 [RFC2412] and SHOULD support Oakley 2048-bit MODP
497 well-known group 14 and Oakley 4096-bit MODP well-known group 16
501 Tung & Zhu Expires November 24, 2005 [Page 9]
502 \f
503 Internet-Draft PKINIT May 2005
506 [RFC3526].
508 The Diffie-Hellman field size should be chosen so as to provide
509 sufficient cryptographic security [RFC3766].
511 When MODP Diffie-Hellman is used, the exponents should have at
512 least twice as many bits as the symmetric keys that will be
513 derived from them [ODL99].
515 7. The client may wish to reuse DH keys or to allow the KDC to do so
516 (see Section 3.2.3.1). If so, then the client includes the
517 clientDHNonce field. This nonce string needs to be as long as
518 the longest key length of the symmetric key types that the client
519 supports. This nonce MUST be chosen randomly.
522 3.2.2 Receipt of Client Request
524 Upon receiving the client's request, the KDC validates it. This
525 section describes the steps that the KDC MUST (unless otherwise
526 noted) take in validating the request.
528 The KDC verifies the client's signature in the signedAuthPack field
529 according to [RFC3852].
531 If, while validating the client's X.509 certificate [RFC3280], the
532 KDC cannot build a certification path to validate the client's
533 certificate, it sends back a KRB-ERROR [CLAR] message with the code
534 KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for this
535 error message is a TYPED-DATA (as defined in [CLAR]) that contains an
536 element whose data-type is TD_TRUSTED_CERTIFIERS, and whose data-
537 value contains the DER encoding of the type TD-TRUSTED-CERTIFIERS:
539 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TrustedCA
540 -- Identifies a list of CAs trusted by the KDC.
541 -- Each TrustedCA identifies a CA or a CA
542 -- certificate (thereby its public key).
544 Upon receiving this error message, the client SHOULD retry only if it
545 has a different set of certificates (from those of the previous
546 requests) that form a certification path (or a partial path) from one
547 of the trust anchors acceptable by the KDC to its own certificate.
549 If, while processing the certification path, the KDC determines that
550 the signature on one of the certificates in the signedAuthPack field
551 is invalid, it returns a KRB-ERROR [CLAR] message with the code
552 KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data for this error
553 message is a TYPED-DATA that contains an element whose data-type is
557 Tung & Zhu Expires November 24, 2005 [Page 10]
558 \f
559 Internet-Draft PKINIT May 2005
562 TD_INVALID_CERTIFICATES, and whose data-value contains the DER
563 encoding of the type TD-INVALID-CERTIFICATES:
565 TD-INVALID-CERTIFICATES ::= SEQUENCE OF OCTET STRING
566 -- Each OCTET STRING contains a CMS type
567 -- IssuerAndSerialNumber encoded according to
568 -- [RFC3852].
569 -- Each IssuerAndSerialNumber identifies a
570 -- certificate (sent by the client) with an invalid
571 -- signature.
573 If more than one X.509 certificate signature is invalid, the KDC MAY
574 include one IssuerAndSerialNumber per invalid signature within the
575 TD-INVALID-CERTIFICATES.
577 The client's X.509 certificate is validated according to [RFC3280].
579 Based on local policy, the KDC may also check whether any X.509
580 certificates in the certification path validating the client's
581 certificate have been revoked. If any of them have been revoked, the
582 KDC MUST return an error message with the code
583 KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
584 revocation status but is unable to do so, it SHOULD return an error
585 message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN. The
586 certificate or certificates affected are identified exactly as for
587 the error code KDC_ERR_INVALID_CERTIFICATE (see above).
589 Note that the TD_INVALID_CERTIFICATES error data is only used to
590 identify invalid certificates sent by the client in the request.
592 The client's public key is then used to verify the signature. If the
593 signature fails to verify, the KDC MUST return an error message with
594 the code KDC_ERR_INVALID_SIG. There is no accompanying e-data for
595 this error message.
597 In addition to validating the client's signature, the KDC MUST also
598 check that the client's public key used to verify the client's
599 signature is bound to the client's principal name as specified in the
600 AS-REQ as follows:
602 1. If the KDC has its own binding between either the client's
603 signature-verification public key or the client's certificate and
604 the client's Kerberos principal name, it uses that binding.
613 Tung & Zhu Expires November 24, 2005 [Page 11]
614 \f
615 Internet-Draft PKINIT May 2005
618 2. Otherwise, if the client's X.509 certificate contains a Subject
619 Alternative Name (SAN) extension carrying a KRB5PrincipalName
620 (defined below) in the otherName field of the type GeneralName
621 [RFC3280], it binds the client's X.509 certificate to that name.
623 The type of the otherName field is AnotherName. The type-id field
624 of the type AnotherName is id-pksan:
626 id-pksan OBJECT IDENTIFIER ::=
627 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
628 x509-sanan (2) }
630 And the value field of the type AnotherName is a
631 KRB5PrincipalName.
633 KRB5PrincipalName ::= SEQUENCE {
634 realm [0] Realm,
635 principalName [1] PrincipalName
636 }
638 If the KDC does not have its own binding and there is no
639 KRB5PrincipalName name present in the client's X.509 certificate, or
640 if the Kerberos name in the request does not match the
641 KRB5PrincipalName in the client's X.509 certificate (including the
642 realm name), the KDC MUST return an error message with the code
643 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for
644 this error message.
646 The KDC MAY require the presence of an Extended Key Usage (EKU)
647 KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the
648 client's X.509 certificate:
650 id-pkekuoid OBJECT IDENTIFIER ::=
651 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
652 pkinit(3) pkekuoid(4) }
653 -- PKINIT client authentication.
654 -- Key usage bits that MUST be consistent:
655 -- digitalSignature.
657 If this EKU KeyPurposeId is required but it is not present or if the
658 client certificate is restricted not to be used for PKINIT client
659 authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
660 an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE. There
661 is no accompanying e-data for this error message. KDCs implementing
662 this requirement SHOULD also accept the EKU KeyPurposeId id-ms-sc-
663 logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there
664 are a large number of X.509 client certificates deployed for use with
665 PKINIT which have this EKU.
669 Tung & Zhu Expires November 24, 2005 [Page 12]
670 \f
671 Internet-Draft PKINIT May 2005
674 If for any other reasons, the client's public key is not accepted,
675 the KDC MUST return an error message with the code
676 KDC_ERR_CLIENT_NOT_TRUSTED.
678 The KDC MUST check the timestamp to ensure that the request is not a
679 replay, and that the time skew falls within acceptable limits. The
680 recommendations for clock skew times in [CLAR] apply here. If the
681 check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
682 KRB_AP_ERR_SKEW, respectively.
684 If the clientPublicValue is filled in, indicating that the client
685 wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
686 check to see if the key parameters satisfy its policy. If they do
687 not, it MUST return an error message with the code
688 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The accompanying e-data is a
689 TYPED-DATA that contains an element whose data-type is
690 TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
691 the type TD-DH-PARAMETERS:
693 TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
694 -- Each AlgorithmIdentifier specifies a set of
695 -- Diffie-Hellman domain parameters [IEEE1363].
696 -- This list is in decreasing preference order.
698 TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
699 that the KDC supports in decreasing preference order, from which the
700 client SHOULD pick one to retry the request.
702 If the client included a kdcPkId field in the PA-PK-AS-REQ and the
703 KDC does not possess the corresponding key, the KDC MUST ignore the
704 kdcPkId field as if the client did not include one.
706 If there is a supportedCMSTypes field in the AuthPack, the KDC must
707 check to see if it supports any of the listed types. If it supports
708 more than one of the types, the KDC SHOULD use the one listed first.
709 If it does not support any of them, it MUST return an error message
710 with the code KDC_ERR_ETYPE_NOSUPP [CLAR].
712 3.2.3 Generation of KDC Reply
714 Assuming that the client's request has been properly validated, the
715 KDC proceeds as per [CLAR], except as follows.
717 The KDC MUST set the initial flag and include an authorization data
718 element of ad-type [CLAR] AD_INITIAL_VERIFIED_CAS in the issued
719 ticket. The ad-data [CLAR] field contains the DER encoding of the
720 type AD-INITIAL-VERIFIED-CAS:
725 Tung & Zhu Expires November 24, 2005 [Page 13]
726 \f
727 Internet-Draft PKINIT May 2005
730 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF TrustedCA
731 -- Identifies the certification path based on which
732 -- the client certificate was validated.
733 -- Each TrustedCA identifies a CA or a CA
734 -- certificate (thereby its public key).
736 The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
737 containers if the list of CAs satisfies the AS' realm's local policy
738 (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
739 [CLAR]). Furthermore, any TGS MUST copy such authorization data from
740 tickets used within a PA-TGS-REQ of the TGS-REQ into the resulting
741 ticket. If the list of CAs satisfies the local KDC's realm's policy,
742 the TGS MAY wrap the data into the AD-IF-RELEVANT container,
743 otherwise it MAY unwrap the authorization data out of the AD-IF-
744 RELEVANT container.
746 Application servers that understand this authorization data type
747 SHOULD apply local policy to determine whether a given ticket bearing
748 such a type *not* contained within an AD-IF-RELEVANT container is
749 acceptable. (This corresponds to the AP server checking the
750 transited field when the TRANSITED-POLICY-CHECKED flag has not been
751 set [CLAR].) If such a data type is contained within an AD-IF-
752 RELEVANT container, AP servers MAY apply local policy to determine
753 whether the authorization data is acceptable.
755 The content of the AS-REP is otherwise unchanged from [CLAR]. The
756 KDC encrypts the reply as usual, but not with the client's long-term
757 key. Instead, it encrypts it with either a shared key derived from a
758 Diffie-Hellman exchange, or a generated encryption key. The contents
759 of the PA-PK-AS-REP indicate which key delivery method is used:
761 PA-PK-AS-REP ::= CHOICE {
762 dhInfo [0] DHRepInfo,
763 -- Selected when Diffie-Hellman key exchange is
764 -- used.
765 encKeyPack [1] IMPLICIT OCTET STRING,
766 -- Selected when public key encryption is used.
767 -- Contains a CMS type ContentInfo encoded
768 -- according to [RFC3852].
769 -- The contentType field of the type ContentInfo is
770 -- id-envelopedData (1.2.840.113549.1.7.3).
771 -- The content field is an EnvelopedData.
772 -- The contentType field for the type EnvelopedData
773 -- is id-signedData (1.2.840.113549.1.7.2).
774 -- The eContentType field for the inner type
775 -- SignedData (when unencrypted) is id-pkrkeydata
776 -- (1.2.840.113549.1.7.3) and the eContent field
777 -- contains the DER encoding of the type
781 Tung & Zhu Expires November 24, 2005 [Page 14]
782 \f
783 Internet-Draft PKINIT May 2005
786 -- ReplyKeyPack.
787 -- ReplyKeyPack is defined in Section 3.2.3.2.
788 ...
789 }
791 DHRepInfo ::= SEQUENCE {
792 dhSignedData [0] IMPLICIT OCTET STRING,
793 -- Contains a CMS type ContentInfo encoded according
794 -- to [RFC3852].
795 -- The contentType field of the type ContentInfo is
796 -- id-signedData (1.2.840.113549.1.7.2), and the
797 -- content field is a SignedData.
798 -- The eContentType field for the type SignedData is
799 -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
800 -- eContent field contains the DER encoding of the
801 -- type KDCDHKeyInfo.
802 -- KDCDHKeyInfo is defined below.
803 serverDHNonce [1] DHNonce OPTIONAL
804 -- Present if and only if dhKeyExpiration is
805 -- present in the KDCDHKeyInfo.
806 }
808 KDCDHKeyInfo ::= SEQUENCE {
809 subjectPublicKey [0] BIT STRING,
810 -- KDC's DH public key.
811 -- The DH public key value is encoded as a BIT
812 -- STRING, as specified in Section 2.3.3 of
813 -- [RFC3279].
814 nonce [1] INTEGER (0..4294967295),
815 -- Contains the nonce in the PKAuthenticator of the
816 -- request if DH keys are NOT reused,
817 -- 0 otherwise.
818 dhKeyExpiration [2] KerberosTime OPTIONAL,
819 -- Expiration time for KDC's key pair,
820 -- present if and only if DH keys are reused. If
821 -- this field is omitted then the serverDHNonce
822 -- field MUST also be omitted. See Section 3.2.3.1.
823 ...
824 }
827 3.2.3.1 Using Diffie-Hellman Key Exchange
829 In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
831 The ContentInfo [RFC3852] structure for the dhSignedData field is
832 filled in as follows:
837 Tung & Zhu Expires November 24, 2005 [Page 15]
838 \f
839 Internet-Draft PKINIT May 2005
842 1. The contentType field of the type ContentInfo is id-signedData
843 (as defined in [RFC3852]), and the content field is a SignedData
844 (as defined in [RFC3852]).
846 2. The eContentType field for the type SignedData is the OID value
847 for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
848 security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }.
850 3. The eContent field for the type SignedData contains the DER
851 encoding of the type KDCDHKeyInfo.
853 4. The signerInfos field of the type SignedData contains a single
854 signerInfo, which contains the signature over the type
855 KDCDHKeyInfo.
857 5. The certificates field of the type SignedData contains
858 certificates intended to facilitate certification path
859 construction, so that the client can verify the KDC's signature
860 over the type KDCDHKeyInfo. The information contained in the
861 trustedCertifiers in the request SHOULD be used by the KDC as
862 hints to guide its selection of an appropriate certificate chain
863 to return to the client. This field may only. be left empty if
864 the KDC public key specified by the kdcPkId field in the PA-PK-
865 AS-REQ was used for signing. Otherwise, for path validation,
866 these certificates SHOULD be sufficient to construct at least one
867 certification path from the KDC certificate to one trust anchor
868 acceptable by the client [CAPATH]. The KDC MUST be capable of
869 including such a set of certificates if configured to do so. The
870 certificates field MUST NOT contain "root" CA certificates.
872 6. If the client included the clientDHNonce field, then the KDC may
873 choose to reuse its DH keys (see Section 3.2.3.1). If the server
874 reuses DH keys then it MUST include an expiration time in the
875 dhKeyExpiration field. Past the point of the expiration time,
876 the signature over the type DHRepInfo is considered expired/
877 invalid. When the server reuses DH keys then it MUST include a
878 serverDHNonce at least as long as the length of keys for the
879 symmetric encryption system used to encrypt the AS reply. Note
880 that including the serverDHNonce changes how the client and
881 server calculate the key to use to encrypt the reply; see below
882 for details. The KDC SHOULD NOT reuse DH keys unless the
883 clientDHNonce field is present in the request.
885 The AS reply key is derived as follows:
893 Tung & Zhu Expires November 24, 2005 [Page 16]
894 \f
895 Internet-Draft PKINIT May 2005
898 1. Both the KDC and the client calculate the shared secret value as
899 follows:
901 a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
902 shared secret value. DHSharedSecret is the value ZZ as
903 described in Section 2.1.1 of [RFC2631].
905 b) When Elliptic Curve Diffie-Hellman (ECDH) (with each party
906 contributing one key pair) is used, let DHSharedSecret be the
907 x-coordinate of the shared secret value (an elliptic curve
908 point). DHSharedSecret is the output of operation ECSVDP-DH as
909 described in Section 7.2.1 of [IEEE1363].
911 DHSharedSecret is first padded with leading zeros such that the
912 size of DHSharedSecret in octets is the same as that of the
913 modulus, then represented as a string of octets in big-endian
914 order.
916 Implementation note: Both the client and the KDC can cache the
917 triple (ya, yb, DHSharedSecret), where ya is the client's public
918 key and yb is the KDC's public key. If both ya and yb are the
919 same in a later exchange, the cached DHSharedSecret can be used.
921 2. Let K be the key-generation seed length [RFC3961] of the AS reply
922 key whose enctype is selected according to [CLAR].
924 3. Define the function octetstring2key() as follows:
926 octetstring2key(x) == random-to-key(K-truncate(
927 SHA1(0x00 | x) |
928 SHA1(0x01 | x) |
929 SHA1(0x02 | x) |
930 ...
931 ))
933 where x is an octet string; | is the concatenation operator; 0x00,
934 0x01, 0x02, etc., are each represented as a single octet; random-
935 to-key() is an operation that generates a protocol key from a
936 bitstring of length K; and K-truncate truncates its input to the
937 first K bits. Both K and random-to-key() are as defined in the
938 kcrypto profile [RFC3961] for the enctype of the AS reply key.
940 4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
941 the serverDHNonce; otherwise, let both n_c and n_k be empty octet
942 strings.
949 Tung & Zhu Expires November 24, 2005 [Page 17]
950 \f
951 Internet-Draft PKINIT May 2005
954 5. The AS reply key k is:
956 k = octetstring2key(DHSharedSecret | n_c | n_k)
959 3.2.3.2 Using Public Key Encryption
961 In this case, the PA-PK-AS-REP contains a ContentInfo structure
962 wrapped in an OCTET STRING. The AS reply key is encrypted in the
963 encKeyPack field, which contains data of type ReplyKeyPack:
965 ReplyKeyPack ::= SEQUENCE {
966 replyKey [0] EncryptionKey,
967 -- Contains the session key used to encrypt the
968 -- enc-part field in the AS-REP.
969 nonce [1] INTEGER (0..4294967295),
970 -- Contains the nonce in the PKAuthenticator of the
971 -- request.
972 ...
973 }
975 The ContentInfo [RFC3852] structure for the encKeyPack field is
976 filled in as follows:
978 1. The contentType field of the type ContentInfo is id-envelopedData
979 (as defined in [RFC3852]), and the content field is an
980 EnvelopedData (as defined in [RFC3852]).
982 2. The contentType field for the type EnvelopedData is id-
983 signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
984 pkcs (1) pkcs7 (7) signedData (2) }.
986 3. The eContentType field for the inner type SignedData (when
987 decrypted from the encryptedContent field for the type
988 EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6)
989 internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }.
991 4. The eContent field for the inner type SignedData contains the DER
992 encoding of the type ReplyKeyPack.
994 5. The signerInfos field of the inner type SignedData contains a
995 single signerInfo, which contains the signature over the type
996 ReplyKeyPack.
998 6. The certificates field of the inner type SignedData contains
999 certificates intended to facilitate certification path
1000 construction, so that the client can verify the KDC's signature
1001 over the type ReplyKeyPack. The information contained in the
1005 Tung & Zhu Expires November 24, 2005 [Page 18]
1006 \f
1007 Internet-Draft PKINIT May 2005
1010 trustedCertifiers in the request SHOULD be used by the KDC as
1011 hints to guide its selection of an appropriate certificate chain
1012 to return to the client. This field may only be left empty if
1013 the KDC public key specified by the kdcPkId field in the PA-PK-
1014 AS-REQ was used for signing. Otherwise, for path validation,
1015 these certificates SHOULD be sufficient to construct at least one
1016 certification path from the KDC certificate to one trust anchor
1017 acceptable by the client [CAPATH]. The KDC MUST be capable of
1018 including such a set of certificates if configured to do so. The
1019 certificates field MUST NOT contain "root" CA certificates.
1021 7. The recipientInfos field of the type EnvelopedData is a SET which
1022 MUST contain exactly one member of type KeyTransRecipientInfo.
1023 The encryptedKey of this member contains the temporary key which
1024 is encrypted using the client's public key.
1026 8. The unprotectedAttrs or originatorInfo fields of the type
1027 EnvelopedData MAY be present.
1029 3.2.4 Receipt of KDC Reply
1031 Upon receipt of the KDC's reply, the client proceeds as follows. If
1032 the PA-PK-AS-REP contains the dhSignedData field, the client derives
1033 the AS reply key using the same procedure used by the KDC as defined
1034 in Section 3.2.3.1. Otherwise, the message contains the encKeyPack
1035 field, and the client decrypts and extracts the temporary key in the
1036 encryptedKey field of the member KeyTransRecipientInfo, and then uses
1037 that as the AS reply key.
1039 In either case, the client MUST verify the signature in the
1040 SignedData according to [RFC3852]. The KDC's X.509 certificate MUST
1041 be validated according to [RFC3280]. In addition, unless the client
1042 can otherwise verify that the public key used to verify the KDC's
1043 signature is bound to the KDC of the target realm, the KDC's X.509
1044 certificate MUST contain a Subject Alternative Name extension
1045 [RFC3280] carrying an AnotherName whose type-id is id-pksan (as
1046 defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
1047 matches the name of the TGS of the target realm (as defined in
1048 Section 7.3 of [CLAR]).
1050 Based on local policy, the client MAY require that the KDC
1051 certificate contains the EKU KeyPurposeId [RFC3280] id-pkkdcekuoid:
1053 id-pkkdcekuoid OBJECT IDENTIFIER ::=
1054 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
1055 pkinit(3) pkkdcekuoid(5) }
1056 -- Signing KDC responses.
1057 -- Key usage bits that MUST be consistent:
1061 Tung & Zhu Expires November 24, 2005 [Page 19]
1062 \f
1063 Internet-Draft PKINIT May 2005
1066 -- digitalSignature.
1068 If all applicable checks are satisfied, the client then decrypts the
1069 enc-part field of the KDC-REP in the AS-REP using the AS reply key,
1070 and then proceeds as described in [CLAR].
1072 Implementation note: CAs issuing KDC certificates SHOULD place all
1073 "short" and "fully-qualified" Kerberos realm names of the KDC (one
1074 per GeneralName [RFC3280]) into the KDC certificate to allow maximum
1075 flexibility.
1077 3.3 Interoperability Requirements
1079 The client MUST be capable of sending a set of certificates
1080 sufficient to allow the KDC to construct a certification path for the
1081 client's certificate, if the correct set of certificates is provided
1082 through configuration or policy.
1084 If the client sends all the X.509 certificates on a certification
1085 path to a trust anchor acceptable by the KDC, and the KDC can not
1086 verify the client's public key otherwise, the KDC MUST be able to
1087 process path validation for the client's certificate based on the
1088 certificates in the request.
1090 The KDC MUST be capable of sending a set of certificates sufficient
1091 to allow the client to construct a certification path for the KDC's
1092 certificate, if the correct set of certificates is provided through
1093 configuration or policy.
1095 If the KDC sends all the X.509 certificates on a certification path
1096 to a trust anchor acceptable by the client, and the client can not
1097 verify the KDC's public key otherwise, the client MUST be able to
1098 process path validation for the KDC's certificate based on the
1099 certificates in the reply.
1101 3.4 KDC Indication of PKINIT Support
1103 If pre-authentication is required, but was not present in the
1104 request, per [CLAR] an error message with the code
1105 KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
1106 stored in the e-data field of the KRB-ERROR message to specify which
1107 pre-authentication mechanisms are acceptable. The KDC can then
1108 indicate the support of PKINIT by including an empty element whose
1109 padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
1111 Otherwise if it is required by the KDC's local policy that the client
1112 must be pre-authenticated using the pre-authentication mechanism
1113 specified in this document, but no PKINIT pre-authentication was
1117 Tung & Zhu Expires November 24, 2005 [Page 20]
1118 \f
1119 Internet-Draft PKINIT May 2005
1122 present in the request, an error message with the code
1123 KDC_ERR_PREAUTH_FAILED SHOULD be returned.
1125 KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
1126 the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
1127 STRING), and clients MUST ignore this and any other value. Future
1128 extensions to this protocol may specify other data to send instead of
1129 an empty OCTET STRING.
1131 4. Security Considerations
1133 PKINIT raises certain security considerations beyond those that can
1134 be regulated strictly in protocol definitions. We will address them
1135 in this section.
1137 PKINIT extends the cross-realm model to the public-key
1138 infrastructure. Users of PKINIT must understand security policies
1139 and procedures appropriate to the use of Public Key Infrastructures
1140 [RFC3280].
1142 Standard Kerberos allows the possibility of interactions between
1143 cryptosystems of varying strengths; this document adds interactions
1144 with public-key cryptosystems to Kerberos. Some administrative
1145 policies may allow the use of relatively weak public keys. Using
1146 such keys to wrap data encrypted under stronger conventional
1147 cryptosystems may be inappropriate.
1149 PKINIT requires keys for symmetric cryptosystems to be generated.
1150 Some such systems contain "weak" keys. For recommendations regarding
1151 these weak keys, see [CLAR].
1153 PKINIT allows the use of the same RSA key pair for encryption and
1154 signing when doing RSA encryption based key delivery. This is not
1155 recommended usage of RSA keys [RFC3447], by using DH based key
1156 delivery this is avoided.
1158 Care should be taken in how certificates are chosen for the purposes
1159 of authentication using PKINIT. Some local policies may require that
1160 key escrow be used for certain certificate types. Deployers of
1161 PKINIT should be aware of the implications of using certificates that
1162 have escrowed keys for the purposes of authentication. Because
1163 signing only certificates are normally not escrowed, by using DH
1164 based key delivery this is avoided.
1166 PKINIT does not provide for a "return routability" test to prevent
1167 attackers from mounting a denial-of-service attack on the KDC by
1168 causing it to perform unnecessary and expensive public-key
1169 operations. Strictly speaking, this is also true of standard
1173 Tung & Zhu Expires November 24, 2005 [Page 21]
1174 \f
1175 Internet-Draft PKINIT May 2005
1178 Kerberos, although the potential cost is not as great, because
1179 standard Kerberos does not make use of public-key cryptography. By
1180 using DH based key delivery and reusing DH keys, the necessary crypto
1181 processing cost per request can be minimized.
1183 The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
1184 permit empty SEQUENCEs to be encoded. Such empty sequences may only
1185 be used if the KDC itself vouches for the user's certificate.
1187 5. Acknowledgements
1189 The following people have made significant contributions to this
1190 draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist
1191 Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle,
1192 Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik
1193 Jaganathan, Chaskiel M Grundman and Stefan Santesson.
1195 Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and
1196 Jonathan Trostle who wrote earlier versions of this document.
1198 The authors are indebted to the Kerberos working group chair Jeffrey
1199 Hutzelman who kept track of various issues and was enormously helpful
1200 during the creation of this document.
1202 Some of the ideas on which this document is based arose during
1203 discussions over several years between members of the SAAG, the IETF
1204 CAT working group, and the PSRG, regarding integration of Kerberos
1205 and SPX. Some ideas have also been drawn from the DASS system.
1206 These changes are by no means endorsed by these groups. This is an
1207 attempt to revive some of the goals of those groups, and this
1208 document approaches those goals primarily from the Kerberos
1209 perspective.
1211 Lastly, comments from groups working on similar ideas in DCE have
1212 been invaluable.
1214 6. IANA Considerations
1216 This document has no actions for IANA.
1218 7. References
1220 7.1 Normative References
1222 [CLAR] RFC-Editor: To be replaced by RFC number for draft-ietf-
1223 krb-wg-kerberos-clarifications. Work in Progress.
1228 Tung & Zhu Expires November 24, 2005 [Page 22]
1229 \f
1230 Internet-Draft PKINIT May 2005
1233 [IEEE1363]
1234 IEEE, "Standard Specifications for Public Key
1235 Cryptography", IEEE 1363, 2000.
1237 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1238 Requirement Levels", BCP 14, RFC 2119, March 1997.
1240 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
1241 RFC 2412, November 1998.
1243 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
1244 RFC 2631, June 1999.
1246 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
1247 Identifiers for the Internet X.509 Public Key
1248 Infrastructure Certificate and Certificate Revocation List
1249 (CRL) Profile", RFC 3279, April 2002.
1251 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
1252 X.509 Public Key Infrastructure Certificate and
1253 Certificate Revocation List (CRL) Profile", RFC 3280,
1254 April 2002.
1256 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
1257 Algorithms", RFC 3370, August 2002.
1259 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
1260 Standards (PKCS) #1: RSA Cryptography Specifications
1261 Version 2.1", RFC 3447, February 2003.
1263 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
1264 Diffie-Hellman groups for Internet Key Exchange (IKE)",
1265 RFC 3526, May 2003.
1267 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES)
1268 Encryption Algorithm in Cryptographic Message Syntax
1269 (CMS)", RFC 3565, July 2003.
1271 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
1272 Public Keys Used For Exchanging Symmetric Keys", BCP 86,
1273 RFC 3766, April 2004.
1275 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
1276 RFC 3852, July 2004.
1278 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
1279 Kerberos 5", RFC 3961, February 2005.
1284 Tung & Zhu Expires November 24, 2005 [Page 23]
1285 \f
1286 Internet-Draft PKINIT May 2005
1289 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES)
1290 Encryption for Kerberos 5", RFC 3962, February 2005.
1292 [X.509-97] ITU-T. Recommendation X.509: The Directory - Authentication
1293 Framework. 1997.
1295 [X690] ASN.1 encoding rules: Specification of Basic Encoding
1296 Rules (BER), Canonical Encoding Rules (CER) and
1297 Distinguished Encoding Rules (DER), ITU-T Recommendation
1298 X.690 (1997) | ISO/IEC International Standard
1299 8825-1:1998.
1301 7.2 Informative References
1303 [CAPATH] RFC-Editor: To be replaced by RFC number for draft-ietf-
1304 pkix-certpathbuild. Work in Progress.
1306 [LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
1307 Sizes", Journal of Cryptology 14 (2001) 255-293.
1309 [ODL99] Odlyzko, A., "Discrete logarithms: The past and the
1310 future, Designs, Codes, and Cryptography (1999)".
1313 Authors' Addresses
1315 Brian Tung
1316 USC Information Sciences Institute
1317 4676 Admiralty Way Suite 1001, Marina del Rey CA
1318 Marina del Rey, CA 90292
1319 US
1321 Email: brian@isi.edu
1324 Larry Zhu
1325 Microsoft Corporation
1326 One Microsoft Way
1327 Redmond, WA 98052
1328 US
1330 Email: lzhu@microsoft.com
1332 Appendix A. PKINIT ASN.1 Module
1336 Tung & Zhu Expires November 24, 2005 [Page 24]
1337 \f
1338 Internet-Draft PKINIT May 2005
1341 KerberosV5-PK-INIT-SPEC {
1342 iso(1) identified-organization(3) dod(6) internet(1)
1343 security(5) kerberosV5(2) modules(4) pkinit(5)
1344 } DEFINITIONS EXPLICIT TAGS ::= BEGIN
1346 IMPORTS
1347 SubjectPublicKeyInfo, AlgorithmIdentifier
1348 FROM PKIX1Explicit88 { iso (1)
1349 identified-organization (3) dod (6) internet (1)
1350 security (5) mechanisms (5) pkix (7) id-mod (0)
1351 id-pkix1-explicit (18) }
1352 -- As defined in RFC 3280.
1354 DomainParameters, EcpkParameters
1355 FROM PKIX1Algorithms88 { iso(1)
1356 identified-organization(3) dod(6)
1357 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
1358 id-mod-pkix1-algorithms(17) }
1359 -- As defined in RFC 3279.
1361 KerberosTime, TYPED-DATA, PrincipalName, Realm, EncryptionKey
1362 FROM KerberosV5Spec2 { iso(1) identified-organization(3)
1363 dod(6) internet(1) security(5) kerberosV5(2)
1364 modules(4) krb5spec2(2) } ;
1366 id-pkinit OBJECT IDENTIFIER ::=
1367 { iso (1) org (3) dod (6) internet (1) security (5)
1368 kerberosv5 (2) pkinit (3) }
1370 id-pkauthdata OBJECT IDENTIFIER ::= { id-pkinit 1 }
1371 id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 }
1372 id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 }
1373 id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 }
1374 id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 }
1376 pa-pk-as-req INTEGER ::= 16
1377 pa-pk-as-rep INTEGER ::= 17
1379 ad-initial-verified-cas INTEGER ::= 9
1381 td-trusted-certifiers INTEGER ::= 104
1382 td-invalid-certificates INTEGER ::= 105
1383 td-dh-parameters INTEGER ::= 109
1385 PA-PK-AS-REQ ::= SEQUENCE {
1386 signedAuthPack [0] IMPLICIT OCTET STRING,
1387 -- Contains a CMS type ContentInfo encoded
1388 -- according to [RFC3852].
1392 Tung & Zhu Expires November 24, 2005 [Page 25]
1393 \f
1394 Internet-Draft PKINIT May 2005
1397 -- The contentType field of the type ContentInfo
1398 -- is id-signedData (1.2.840.113549.1.7.2),
1399 -- and the content field is a SignedData.
1400 -- The eContentType field for the type SignedData is
1401 -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
1402 -- eContent field contains the DER encoding of the
1403 -- type AuthPack.
1404 -- AuthPack is defined below.
1405 trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,
1406 -- A list of CAs, trusted by the client, that can
1407 -- be used to certify the KDC.
1408 -- Each TrustedCA identifies a CA or a CA
1409 -- certificate (thereby its public key).
1410 -- The information contained in the
1411 -- trustedCertifiers SHOULD be used by the KDC as
1412 -- hints to guide its selection of an appropriate
1413 -- certificate chain to return to the client.
1414 kdcPkId [2] IMPLICIT OCTET STRING
1415 OPTIONAL,
1416 -- Contains a CMS type SignerIdentifier encoded
1417 -- according to [RFC3852].
1418 -- Identifies, if present, a particular KDC
1419 -- public key that the client already has.
1420 ...
1421 }
1423 DHNonce ::= OCTET STRING
1425 TrustedCA ::= SEQUENCE {
1426 caName [0] IMPLICIT OCTET STRING,
1427 -- Contains a PKIX type Name encoded according to
1428 -- [RFC3280].
1429 -- Identifies a CA by the CA's distinguished subject
1430 -- name.
1431 certificateSerialNumber [1] INTEGER OPTIONAL,
1432 -- Specifies the CA certificate's serial number.
1433 -- The defintion of the certificate serial number
1434 -- is taken from X.509 [X.509-97].
1435 subjectKeyIdentifier [2] OCTET STRING OPTIONAL,
1436 -- Identifies the CA's public key by a key
1437 -- identifier. When an X.509 certificate is
1438 -- referenced, this key identifier matches the X.509
1439 -- subjectKeyIdentifier extension value. When other
1440 -- certificate formats are referenced, the documents
1441 -- that specify the certificate format and their use
1442 -- with the CMS must include details on matching the
1443 -- key identifier to the appropriate certificate
1444 -- field.
1448 Tung & Zhu Expires November 24, 2005 [Page 26]
1449 \f
1450 Internet-Draft PKINIT May 2005
1453 ...
1454 }
1457 AuthPack ::= SEQUENCE {
1458 pkAuthenticator [0] PKAuthenticator,
1459 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
1460 -- Type SubjectPublicKeyInfo is defined in
1461 -- [RFC3280].
1462 -- Specifies Diffie-Hellman domain parameters
1463 -- and the client's public key value [IEEE1363].
1464 -- The DH public key value is encoded as a BIT
1465 -- STRING, as specified in Section 2.3.3 of
1466 -- [RFC3279].
1467 -- This field is present only if the client wishes
1468 -- to use the Diffie-Hellman key agreement method.
1469 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
1470 OPTIONAL,
1471 -- Type AlgorithmIdentifier is defined in
1472 -- [RFC3280].
1473 -- List of CMS encryption types supported by the
1474 -- client in order of (decreasing) preference.
1475 clientDHNonce [3] DHNonce OPTIONAL,
1476 -- Present only if the client indicates that it
1477 -- wishes to reuse DH keys or to allow the KDC to
1478 -- do so.
1479 ...
1480 }
1482 PKAuthenticator ::= SEQUENCE {
1483 cusec [0] INTEGER (0..999999),
1484 ctime [1] KerberosTime,
1485 -- cusec and ctime are used as in [CLAR], for replay
1486 -- prevention.
1487 nonce [2] INTEGER (0..4294967295),
1488 -- Chosen randomly; This nonce does not need to
1489 -- match with the nonce in the KDC-REQ-BODY.
1490 paChecksum [3] OCTET STRING,
1491 -- Contains the SHA1 checksum, performed over
1492 -- KDC-REQ-BODY.
1493 ...
1494 }
1496 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TrustedCA
1497 -- Identifies a list of CAs trusted by the KDC.
1498 -- Each TrustedCA identifies a CA or a CA
1499 -- certificate (thereby its public key).
1504 Tung & Zhu Expires November 24, 2005 [Page 27]
1505 \f
1506 Internet-Draft PKINIT May 2005
1509 TD-INVALID-CERTIFICATES ::= SEQUENCE OF OCTET STRING
1510 -- Each OCTET STRING contains a CMS type
1511 -- IssuerAndSerialNumber encoded according to
1512 -- [RFC3852].
1513 -- Each IssuerAndSerialNumber identifies a
1514 -- certificate (sent by the client) with an invalid
1515 -- signature.
1517 KRB5PrincipalName ::= SEQUENCE {
1518 realm [0] Realm,
1519 principalName [1] PrincipalName
1520 }
1522 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF TrustedCA
1523 -- Identifies the certification path based on which
1524 -- the client certificate was validated.
1525 -- Each TrustedCA identifies a CA or a CA
1526 -- certificate (thereby its public key).
1528 PA-PK-AS-REP ::= CHOICE {
1529 dhInfo [0] DHRepInfo,
1530 -- Selected when Diffie-Hellman key exchange is
1531 -- used.
1532 encKeyPack [1] IMPLICIT OCTET STRING,
1533 -- Selected when public key encryption is used.
1534 -- Contains a CMS type ContentInfo encoded
1535 -- according to [RFC3852].
1536 -- The contentType field of the type ContentInfo is
1537 -- id-envelopedData (1.2.840.113549.1.7.3).
1538 -- The content field is an EnvelopedData.
1539 -- The contentType field for the type EnvelopedData
1540 -- is id-signedData (1.2.840.113549.1.7.2).
1541 -- The eContentType field for the inner type
1542 -- SignedData (when unencrypted) is id-pkrkeydata
1543 -- (1.2.840.113549.1.7.3) and the eContent field
1544 -- contains the DER encoding of the type
1545 -- ReplyKeyPack.
1546 -- ReplyKeyPack is defined below.
1547 ...
1548 }
1550 DHRepInfo ::= SEQUENCE {
1551 dhSignedData [0] IMPLICIT OCTET STRING,
1552 -- Contains a CMS type ContentInfo encoded according
1553 -- to [RFC3852].
1554 -- The contentType field of the type ContentInfo is
1555 -- id-signedData (1.2.840.113549.1.7.2), and the
1556 -- content field is a SignedData.
1560 Tung & Zhu Expires November 24, 2005 [Page 28]
1561 \f
1562 Internet-Draft PKINIT May 2005
1565 -- The eContentType field for the type SignedData is
1566 -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
1567 -- eContent field contains the DER encoding of the
1568 -- type KDCDHKeyInfo.
1569 -- KDCDHKeyInfo is defined below.
1570 serverDHNonce [1] DHNonce OPTIONAL
1571 -- Present if and only if dhKeyExpiration is
1572 -- present.
1573 }
1575 KDCDHKeyInfo ::= SEQUENCE {
1576 subjectPublicKey [0] BIT STRING,
1577 -- KDC's DH public key.
1578 -- The DH public key value is encoded as a BIT
1579 -- STRING, as specified in Section 2.3.3 of
1580 -- [RFC3279].
1581 nonce [1] INTEGER (0..4294967295),
1582 -- Contains the nonce in the PKAuthenticator of the
1583 -- request if DH keys are NOT reused,
1584 -- 0 otherwise.
1585 dhKeyExpiration [2] KerberosTime OPTIONAL,
1586 -- Expiration time for KDC's key pair,
1587 -- present if and only if DH keys are reused. If
1588 -- this field is omitted then the serverDHNonce
1589 -- field MUST also be omitted.
1590 ...
1591 }
1593 ReplyKeyPack ::= SEQUENCE {
1594 replyKey [0] EncryptionKey,
1595 -- Contains the session key used to encrypt the
1596 -- enc-part field in the AS-REP.
1597 nonce [1] INTEGER (0..4294967295),
1598 -- Contains the nonce in the PKAuthenticator of the
1599 -- request.
1600 ...
1601 }
1603 TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
1604 -- Each AlgorithmIdentifier specifies a set of
1605 -- Diffie-Hellman domain parameters [IEEE1363].
1606 -- This list is in decreasing preference order.
1607 END
1616 Tung & Zhu Expires November 24, 2005 [Page 29]
1617 \f
1618 Internet-Draft PKINIT May 2005
1621 Intellectual Property Statement
1623 The IETF takes no position regarding the validity or scope of any
1624 Intellectual Property Rights or other rights that might be claimed to
1625 pertain to the implementation or use of the technology described in
1626 this document or the extent to which any license under such rights
1627 might or might not be available; nor does it represent that it has
1628 made any independent effort to identify any such rights. Information
1629 on the procedures with respect to rights in RFC documents can be
1630 found in BCP 78 and BCP 79.
1632 Copies of IPR disclosures made to the IETF Secretariat and any
1633 assurances of licenses to be made available, or the result of an
1634 attempt made to obtain a general license or permission for the use of
1635 such proprietary rights by implementers or users of this
1636 specification can be obtained from the IETF on-line IPR repository at
1637 http://www.ietf.org/ipr.
1639 The IETF invites any interested party to bring to its attention any
1640 copyrights, patents or patent applications, or other proprietary
1641 rights that may cover technology that may be required to implement
1642 this standard. Please address the information to the IETF at
1643 ietf-ipr@ietf.org.
1646 Disclaimer of Validity
1648 This document and the information contained herein are provided on an
1649 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1650 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1651 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1652 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1653 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1654 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1657 Copyright Statement
1659 Copyright (C) The Internet Society (2005). This document is subject
1660 to the rights, licenses and restrictions contained in BCP 78, and
1661 except as set forth therein, the authors retain all their rights.
1664 Acknowledgment
1666 Funding for the RFC Editor function is currently provided by the
1667 Internet Society.
1672 Tung & Zhu Expires November 24, 2005 [Page 30]
1673 \f