| blob | 2aed744ce1c18fc78d1422d48e43960475ee33af |
4 NETWORK WORKING GROUP B. Tung
5 Internet-Draft USC Information Sciences Institute
6 Expires: August 11, 2005 L. Zhu
7 Microsoft Corporation
8 February 7, 2005
11 Public Key Cryptography for Initial Authentication in Kerberos
12 draft-ietf-cat-kerberos-pk-init
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. By submitting this Internet-Draft, each
18 author represents that any applicable patent or other IPR claims of
19 which he or she is aware have been or will be disclosed, and any of
20 which he or she become aware will be disclosed, in accordance with
21 RFC 3668.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF), its areas, and its working groups. Note that
25 other groups may also distribute working documents as
26 Internet-Drafts.
28 Internet-Drafts are draft documents valid for a maximum of six months
29 and may be updated, replaced, or obsoleted by other documents at any
30 time. It is inappropriate to use Internet-Drafts as reference
31 material or to cite them other than as "work in progress."
33 The list of current Internet-Drafts can be accessed at
34 http://www.ietf.org/ietf/1id-abstracts.txt.
36 The list of Internet-Draft Shadow Directories can be accessed at
37 http://www.ietf.org/shadow.html.
39 This Internet-Draft will expire on August 11, 2005.
41 Copyright Notice
43 Copyright (C) The Internet Society (2005).
45 Abstract
47 This document describes protocol extensions (hereafter called PKINIT)
48 to the Kerberos protocol specification. These extensions provide a
49 method for integrating public key cryptography into the initial
50 authentication exchange, by using asymmetric-key signature and/or
51 encryption algorithms in pre-authentication data fields.
55 Tung & Zhu Expires August 11, 2005 [Page 1]
56 \f
57 Internet-Draft PKINIT February 2005
60 Table of Contents
62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
63 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
64 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
65 3.1 Definitions, Requirements, and Constants . . . . . . . . . 4
66 3.1.1 Required Algorithms . . . . . . . . . . . . . . . . . 4
67 3.1.2 Defined Message and Encryption Types . . . . . . . . . 5
68 3.1.3 Algorithm Identifiers . . . . . . . . . . . . . . . . 6
69 3.2 PKINIT Pre-authentication Syntax and Use . . . . . . . . . 6
70 3.2.1 Generation of Client Request . . . . . . . . . . . . . 6
71 3.2.2 Receipt of Client Request . . . . . . . . . . . . . . 10
72 3.2.3 Generation of KDC Reply . . . . . . . . . . . . . . . 13
73 3.2.4 Receipt of KDC Reply . . . . . . . . . . . . . . . . . 18
74 3.3 KDC Indication of PKINIT Support . . . . . . . . . . . . . 20
75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 20
76 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
79 7.1 Normative References . . . . . . . . . . . . . . . . . . . 22
80 7.2 Informative References . . . . . . . . . . . . . . . . . . 23
81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
82 A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 24
83 Intellectual Property and Copyright Statements . . . . . . . . 29
111 Tung & Zhu Expires August 11, 2005 [Page 2]
112 \f
113 Internet-Draft PKINIT February 2005
116 1. Introduction
118 A client typically authenticates itself to a service in Kerberos
119 using three distinct though related exchanges. First, the client
120 requests a ticket-granting ticket (TGT) from the Kerberos
121 authentication server (AS). Then, it uses the TGT to request a
122 service ticket from the Kerberos ticket-granting server (TGS).
123 Usually, the AS and TGS are integrated in a single device known as a
124 Kerberos Key Distribution Center, or KDC. (In this document, we will
125 refer to both the AS and the TGS as the KDC.) Finally, the client
126 uses 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
150 public-key cryptography into Kerberos is in the initial
151 authentication exchange. This document describes the methods and
152 data formats for integrating public-key cryptography into Kerberos
153 initial 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].
167 Tung & Zhu Expires August 11, 2005 [Page 3]
168 \f
169 Internet-Draft PKINIT February 2005
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
199 pre-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: AES256-CTS-HMAC-SHA1-96 etype [KCRYPTO].
216 o Signature algorithm: sha-1WithRSAEncryption [RFC3279].
218 o KDC AS reply key delivery method: Diffie-Hellman key exchange
219 [RFC2631].
223 Tung & Zhu Expires August 11, 2005 [Page 4]
224 \f
227 3.1.2 Defined Message and Encryption Types
229 PKINIT makes use of the following new pre-authentication types:
231 PA_PK_AS_REQ 16
232 PA_PK_AS_REP 17
234 PKINIT also makes use of the following new authorization data type:
236 AD_INITIAL_VERIFIED_CAS 9
238 PKINIT introduces the following new error codes:
240 KDC_ERR_CLIENT_NOT_TRUSTED 62
241 KDC_ERR_INVALID_SIG 64
242 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65
243 KDC_ERR_CANT_VERIFY_CERTIFICATE 70
244 KDC_ERR_INVALID_CERTIFICATE 71
245 KDC_ERR_REVOKED_CERTIFICATE 72
246 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
247 KDC_ERR_CLIENT_NAME_MISMATCH 75
248 KDC_ERR_INCONSISTENT_KEY_PURPOSE 76
250 PKINIT uses the following typed data types for errors:
252 TD_TRUSTED_CERTIFIERS 104
253 TD_INVLID_CERTIFICATES 105
254 TD_DH_PARAMETERS 109
256 PKINIT defines the following encryption types, for use in the AS-REQ
257 message to indicate acceptance of the corresponding algorithms that
258 can used by Cryptographic Message Syntax (CMS) [RFC3852] messages in
259 the reply:
261 dsaWithSHA1-CmsOID 9
262 md5WithRSAEncryption-CmsOID 10
263 sha1WithRSAEncryption-CmsOID 11
264 rc2CBC-EnvOID 12
265 rsaEncryption-EnvOID (PKCS1 v1.5) 13
266 rsaES-OAEP-EnvOID (PKCS1 v2.0) 14
267 des-ede3-cbc-EnvOID 15
269 The ASN.1 module for all structures defined in this document (plus
270 IMPORT statements for all imported structures) is given in
271 Appendix A.
273 All structures defined in or imported into this document MUST be
274 encoded using Distinguished Encoding Rules (DER) [X690] (unless
275 otherwise noted). All data structures carried in OCTET STRINGs must
279 Tung & Zhu Expires August 11, 2005 [Page 5]
280 \f
281 Internet-Draft PKINIT February 2005
284 be encoded according to the rules specified in corresponding
285 specifications.
287 Interoperability note: Some implementations may not be able to decode
288 wrapped CMS objects encoded with BER but not DER; specifically, they
289 may not be able to decode infinite length encodings. To maximize
290 interoperability, implementers SHOULD encode CMS objects used in
291 PKINIT with DER.
293 3.1.3 Algorithm Identifiers
295 PKINIT does not define, but does make use of, the following algorithm
296 identifiers.
298 PKINIT uses the following algorithm identifiers for Diffie-Hellman
299 key agreement [RFC3279]:
301 dhpublicnumber (Diffie-Hellman modulo a prime p [RFC2631])
302 id-ecPublicKey (Elliptic Curve Diffie-Hellman [IEEE1363])
304 PKINIT uses the following signature algorithm identifiers [RFC3279]:
306 sha-1WithRSAEncryption (RSA with SHA1)
307 md5WithRSAEncryption (RSA with MD5)
308 id-dsa-with-sha1 (DSA with SHA1)
310 PKINIT uses the following encryption algorithm identifiers [RFC3447]
311 for encrypting the temporary key with a public key:
313 rsaEncryption (PKCS1 v1.5)
314 id-RSAES-OAEP (PKCS1 v2.0)
316 PKINIT uses the following algorithm identifiers [RFC3370][RFC3565]
317 for encrypting the reply key with the temporary key:
319 des-ede3-cbc (three-key 3DES, CBC mode)
320 rc2-cbc (RC2, CBC mode)
321 id-aes256-CBC (AES-256, CBC mode)
324 3.2 PKINIT Pre-authentication Syntax and Use
326 This section defines the syntax and use of the various
327 pre-authentication fields employed by PKINIT.
329 3.2.1 Generation of Client Request
331 The initial authentication request (AS-REQ) is sent as per [CLAR]; in
335 Tung & Zhu Expires August 11, 2005 [Page 6]
336 \f
337 Internet-Draft PKINIT February 2005
340 addition, a pre-authentication data element, whose padata-type is
341 PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
342 type PA-PK-AS-REQ, is included.
344 PA-PK-AS-REQ ::= SEQUENCE {
345 signedAuthPack [0] IMPLICIT OCTET STRING,
346 -- Contains a CMS type ContentInfo encoded
347 -- according to [RFC3852].
348 -- The contentType field of the type ContentInfo
349 -- is id-signedData (1.2.840.113549.1.7.2),
350 -- and the content field is a SignedData.
351 -- The eContentType field for the type SignedData is
352 -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
353 -- eContent field contains the DER encoding of the
354 -- type AuthPack.
355 -- AuthPack is defined below.
356 trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,
357 -- A list of CAs, trusted by the client, that can
358 -- be used as the trust anchor to validate the KDC's
359 -- signature.
360 -- Each TrustedCA identifies a CA or a CA
361 -- certificate (thereby its public key).
362 kdcPkId [2] IMPLICIT OCTET STRING
363 OPTIONAL,
364 -- Contains a CMS type SignerIdentifier encoded
365 -- according to [RFC3852].
366 -- Identifies, if present, a particular KDC
367 -- public key that the client already has.
368 ...
369 }
371 DHNonce ::= OCTET STRING
373 TrustedCA ::= CHOICE {
374 caName [1] IMPLICIT OCTET STRING,
375 -- Contains a PKIX type Name encoded according to
376 -- [RFC3280].
377 -- Identifies a CA.
378 -- Prefer the sid field below if that is available.
379 sid [2] IMPLICIT OCTET STRING,
380 -- Contains a CMS type SignerIdentifier encoded
381 -- according to [RFC3852].
382 -- Identifies the trusted CA's certificate (and
383 -- thereby the public key).
384 ...
385 }
387 AuthPack ::= SEQUENCE {
391 Tung & Zhu Expires August 11, 2005 [Page 7]
392 \f
393 Internet-Draft PKINIT February 2005
396 pkAuthenticator [0] PKAuthenticator,
397 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
398 -- Defined in [RFC3280].
399 -- The pubic key value (the subjectPublicKey field
400 -- of the type SubjectPublicKeyInfo) MUST be encoded
401 -- according to [RFC3279].
402 -- Present only if the client wishes to use the
403 -- Diffie-Hellman key agreement method.
404 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
405 OPTIONAL,
406 -- List of CMS encryption types supported by
407 -- client in order of (decreasing) preference.
408 clientDHNonce [3] DHNonce OPTIONAL,
409 -- Present only if the client indicates that it
410 -- wishes to reuse DH keys or to allow the KDC to
411 -- do so (see Section 3.2.3.1).
412 ...
413 }
415 PKAuthenticator ::= SEQUENCE {
416 cusec [0] INTEGER (0..999999),
417 ctime [1] KerberosTime,
418 -- cusec and ctime are used as in [CLAR], for replay
419 -- prevention.
420 nonce [2] INTEGER (0..4294967295),
421 -- Chosen randomly; This nonce does not need to
422 -- match with the nonce in the KDC-REQ-BODY.
423 paChecksum [3] OCTET STRING,
424 -- Contains the SHA1 checksum, performed over
425 -- KDC-REQ-BODY.
426 ...
427 }
429 The ContentInfo [RFC3852] structure for the signedAuthPack field is
430 filled out as follows:
432 1. The contentType field of the type ContentInfo is id-signedData
433 (as defined in [RFC3852]), and the content field is a SignedData
434 (as defined in [RFC3852]).
436 2. The eContentType field for the type SignedData is id-pkauthdata:
437 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
438 pkinit(3) pkauthdata(1) }.
440 3. The eContent field for the type SignedData contains the DER
441 encoding of the type AuthPack.
447 Tung & Zhu Expires August 11, 2005 [Page 8]
448 \f
449 Internet-Draft PKINIT February 2005
452 4. The signerInfos field of the type SignedData contains a single
453 signerInfo, which contains the signature over the type AuthPack.
455 5. The certificates field of the type SignedData contains
456 certificates intended to facilitate certification path
457 construction, so that the KDC can verify the signature over the
458 type AuthPack. For path validation, these certificates SHOULD be
459 sufficient to construct at least one certification path from the
460 client certificate to one trust anchor acceptable by the KDC
461 [CAPATH]. If the client sends all the X.509 certificates on a
462 certification path to a trust anchor acceptable by the KDC and
463 the KDC can not verify the client's public key otherwise, the KDC
464 MUST process path validation for the client's X.509 certificate
465 based on the certificates in the request. The certificates field
466 MUST NOT contain "root" CA certificates.
468 6. The client's Diffie-Hellman public value (clientPublicValue) is
469 included if and only if the client wishes to use the
470 Diffie-Hellman key agreement method. For the Diffie-Hellman key
471 agreement method, implementations MUST support Oakley 1024-bit
472 MODP well-known group 2 [RFC2412] and SHOULD support Oakley
473 2048-bit MODP well-known group 14 and Oakley 4096-bit MODP
474 well-known group 16 [RFC3526].
476 The Diffie-Hellman field size should be chosen so as to provide
477 sufficient cryptographic security. The following table, based on
478 [LENSTRA], gives approximate comparable key sizes for symmetric-
479 and asymmetric-key cryptosystems based on the best-known
480 algorithms for attacking them.
482 Symmetric | ECC | DH/DSA/RSA
483 -------------+---------+------------
484 80 | 163 | 1024
485 112 | 233 | 2048
486 128 | 283 | 3072
487 192 | 409 | 7680
488 256 | 571 | 15360
490 Table 1: Comparable key sizes (in bits)
492 When Diffie-Hellma modulo a prime p is used, the exponents should
493 have at least twice as many bits as the symmetric keys that will
494 be derived from them [ODL99].
496 7. The client may wish to reuse DH keys or to allow the KDC to do so
497 (see Section 3.2.3.1). If so, then the client includes the
498 clientDHNonce field. This nonce string needs to be as long as
499 the longest key length of the symmetric key types that the client
503 Tung & Zhu Expires August 11, 2005 [Page 9]
504 \f
505 Internet-Draft PKINIT February 2005
508 supports. This nonce MUST be chosen randomly.
511 3.2.2 Receipt of Client Request
513 Upon receiving the client's request, the KDC validates it. This
514 section describes the steps that the KDC MUST (unless otherwise
515 noted) take in validating the request.
517 The KDC verifies the client's signature in the signedAuthPack field
518 according to [RFC3852].
520 If, while validating the client's X.509 certificate [RFC3280], the
521 KDC cannot build a certification path to validate the client's
522 certificate, it sends back a KRB-ERROR [CLAR] message with the code
523 KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for this
524 error message is a TYPED-DATA (as defined in [CLAR]) that contains an
525 element whose data-type is TD_TRUSTED_CERTIFIERS, and whose
526 data-value contains the DER encoding of the type
527 TD-TRUSTED-CERTIFIERS:
529 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TrustedCA
530 -- Identifies a list of CAs trusted by the KDC.
531 -- Each TrustedCA identifies a CA or a CA
532 -- certificate (thereby its public key).
534 Upon receiving this error message, the client SHOULD retry only if it
535 has a different set of certificates (from those of the previous
536 requests) that form a certification path (or a partial path) from one
537 of the trust anchors selected by the KDC to its own certificate.
539 If, while processing the certification path, the KDC determines that
540 the signature on one of the certificates in the signedAuthPack field
541 is invalid, it returns a KRB-ERROR [CLAR] message with the code
542 KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data for this error
543 message is a TYPED-DATA that contains an element whose data-type is
544 TD_INVALID_CERTIFICATES, and whose data-value contains the DER
545 encoding of the type TD-INVALID-CERTIFICATES:
547 TD-INVALID-CERTIFICATES ::= SEQUENCE OF OCTET STRING
548 -- Each OCTET STRING contains a CMS type
549 -- IssuerAndSerialNumber encoded according to
550 -- [RFC3852].
551 -- Each IssuerAndSerialNumber indentifies a
552 -- certificate (sent by the client) with an invalid
553 -- signature.
555 If more than one X.509 certificate signature is invalid, the KDC MAY
559 Tung & Zhu Expires August 11, 2005 [Page 10]
560 \f
561 Internet-Draft PKINIT February 2005
564 send one TYPED-DATA element per invalid signature.
566 Based on local policy, the KDC may also check whether any X.509
567 certificates in the certification path validating the client's
568 certificate have been revoked. If any of them have been revoked, the
569 KDC MUST return an error message with the code
570 KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
571 revocation status but is unable to do so, it SHOULD return an error
572 message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN. The
573 certificate or certificates affected are identified exactly as for
574 the error code KDC_ERR_INVALID_CERTIFICATE (see above).
576 The client's public key is then used to verify the signature. If the
577 signature fails to verify, the KDC MUST return an error message with
578 the code KDC_ERR_INVALID_SIG. There is no accompanying e-data for
579 this error message.
581 In addition to validating the client's signature, the KDC MUST also
582 check that the client's public key used to verify the client's
583 signature is bound to the client's principal name as specified in the
584 AS-REQ as follows:
586 1. If the KDC has its own binding between either the client's
587 signature-verification public key or the client's certificate and
588 the client's Kerberos principal name, it uses that binding.
590 2. Otherwise, if the client's X.509 certificate contains a
591 SubjectAltName extension with a KRB5PrincipalName (defined below)
592 in the otherName field, it binds the client's X.509 certificate to
593 that name.
595 The otherName field (of type AnotherName) in the SubjectAltName
596 extension MUST contain KRB5PrincipalName as defined below.
598 The type-id field of the type AnotherName is id-pksan:
600 id-pksan OBJECT IDENTIFIER ::=
601 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
602 x509-sanan (2) }
604 The value field of the type AnotherName is the DER encoding of the
605 following ASN.1 type:
607 KRB5PrincipalName ::= SEQUENCE {
608 realm [0] Realm,
609 principalName [1] PrincipalName
610 }
615 Tung & Zhu Expires August 11, 2005 [Page 11]
616 \f
617 Internet-Draft PKINIT February 2005
620 If the KDC does not have its own binding and there is no
621 KRB5PrincipalName name present in the client's X.509 certificate, and
622 if the Kerberos name in the request does not match the
623 KRB5PrincipalName in the client's X.509 certificate (including the
624 realm name), the KDC MUST return an error message with the code
625 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for
626 this error message.
628 The KDC MAY require the presence of an Extended Key Usage (EKU)
629 KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the
630 client's X.509 certificate:
632 id-pkekuoid OBJECT IDENTIFIER ::=
633 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
634 pkinit(3) pkekuoid(4) }
635 -- PKINIT client authentication.
636 -- Key usage bits that MUST be consistent:
637 -- digitalSignature;
638 -- Key usage bits that MAY be consistent:
639 -- nonRepudiation, and (keyEncipherment or keyAgreement).
641 If this EKU is required but is missing, the KDC MUST return an error
642 message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE. There is no
643 accompanying e-data for this error message. KDCs implementing this
644 requirement SHOULD also accept the EKU KeyPurposeId id-ms-sc-logon
645 (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there are a
646 large number of X.509 client certificates deployed for use with
647 PKINIT which have this EKU.
649 If for any other reasons, the client's public key is not accepted,
650 the KDC MUST return an error message with the code
651 KDC_ERR_CLIENT_NOT_TRUSTED.
653 The KDC MUST check the timestamp to ensure that the request is not a
654 replay, and that the time skew falls within acceptable limits. The
655 recommendations for clock skew times in [CLAR] apply here. If the
656 check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
657 KRB_AP_ERR_SKEW, respectively.
659 If the clientPublicValue is filled in, indicating that the client
660 wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
661 check to see if the key parameters satisfy its policy. If they do
662 not, it MUST return an error message with the code
663 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The accompanying e-data is a
664 TYPED-DATA that contains an element whose data-type is
665 TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
666 the type TD-DH-PARAMETERS:
671 Tung & Zhu Expires August 11, 2005 [Page 12]
672 \f
673 Internet-Draft PKINIT February 2005
676 TD-DH-PARAMETERS ::= SEQUENCE OF DHDomainParameters
677 -- Contains a list of Diffie-Hellman domain
678 -- parameters in decreasing preference order.
680 DHDomainParameters ::= CHOICE {
681 modp [0] DomainParameters,
682 -- Type DomainParameters is defined in [RFC3279].
683 ec [1] EcpkParameters,
684 -- Type EcpkParameters is defined in [RFC3279].
685 ...
686 }
688 TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
689 that the KDC supports in decreasing preference order, from which the
690 client SHOULD pick one to retry the request.
692 If the client included a kdcPkId field in the PA-PK-AS-REQ and the
693 KDC does not have the corresponding key, the KDC MUST ignore the
694 kdcPkId field as if the client did not include one.
696 If the client included a trustedCertifiers field, and the KDC does
697 not possesses the private key for any one of the listed certifiers,
698 the KDC MUST ignore the trustedCertifiers field as if the client did
699 not include one.
701 If there is a supportedCMSTypes field in the AuthPack, the KDC must
702 check to see if it supports any of the listed types. If it supports
703 more than one of the types, the KDC SHOULD use the one listed first.
704 If it does not support any of them, it MUST return an error message
705 with the code KDC_ERR_ETYPE_NOSUPP [CLAR].
707 3.2.3 Generation of KDC Reply
709 Assuming that the client's request has been properly validated, the
710 KDC proceeds as per [CLAR], except as follows.
712 The KDC MUST set the initial flag and include an authorization data
713 element of ad-type [CLAR] AD_INITIAL_VERIFIED_CAS in the issued
714 ticket. The ad-data [CLAR] field contains the DER encoding of the
715 type AD-INITIAL-VERIFIED-CAS:
717 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF TrustedCA
718 -- Identifies the certification path based on which
719 -- the client certificate was validated.
720 -- Each TrustedCA identifies a CA or a CA
721 -- certificate (thereby its public key).
723 The KDC MUST wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
727 Tung & Zhu Expires August 11, 2005 [Page 13]
728 \f
729 Internet-Draft PKINIT February 2005
732 containers. Furthermore, any TGS MUST copy such authorization data
733 from tickets used in a PA-TGS-REQ [CLAR] of the TGS-REQ to the
734 resulting ticket. Upon receipt of a service ticket carrying the
735 AD-INITIAL-VERIFIED-CAS data, application servers MAY apply local
736 policy to determine whether the authorization data is acceptable.
738 The content of the AS-REP is otherwise unchanged from [CLAR]. The
739 KDC encrypts the reply as usual, but not with the client's long-term
740 key. Instead, it encrypts it with either a shared key derived from a
741 Diffie-Hellman exchange, or a generated encryption key. The contents
742 of the PA-PK-AS-REP indicate which key delivery method is used:
744 PA-PK-AS-REP ::= CHOICE {
745 dhInfo [0] DHRepInfo,
746 -- Selected when Diffie-Hellman key exchange is
747 -- used.
748 encKeyPack [1] IMPLICIT OCTET STRING,
749 -- Selected when public key encryption is used.
750 -- Contains a CMS type ContentInfo encoded
751 -- according to [RFC3852].
752 -- The contentType field of the type ContentInfo is
753 -- id-envelopedData (1.2.840.113549.1.7.3).
754 -- The content field is an EnvelopedData.
755 -- The contentType field for the type EnvelopedData
756 -- is id-signedData (1.2.840.113549.1.7.2).
757 -- The eContentType field for the inner type
758 -- SignedData (when unencrypted) is id-pkrkeydata
759 -- (1.2.840.113549.1.7.3) and the eContent field
760 -- contains the DER encoding of the type
761 -- ReplyKeyPack.
762 -- ReplyKeyPack is defined in Section 3.2.3.2.
763 ...
764 }
766 DHRepInfo ::= SEQUENCE {
767 dhSignedData [0] IMPLICIT OCTET STRING,
768 -- Contains a CMS type ContentInfo encoded according
769 -- to [RFC3852].
770 -- The contentType field of the type ContentInfo is
771 -- id-signedData (1.2.840.113549.1.7.2), and the
772 -- content field is a SignedData.
773 -- The eContentType field for the type SignedData is
774 -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
775 -- eContent field contains the DER encoding of the
776 -- type KDCDHKeyInfo.
777 -- KDCDHKeyInfo is defined below.
778 serverDHNonce [1] DHNonce OPTIONAL
779 -- Present if and only if dhKeyExpiration is
783 Tung & Zhu Expires August 11, 2005 [Page 14]
784 \f
785 Internet-Draft PKINIT February 2005
788 -- present in the KDCDHKeyInfo.
789 }
791 KDCDHKeyInfo ::= SEQUENCE {
792 subjectPublicKey [0] BIT STRING,
793 -- KDC's DH public key.
794 -- The DH pubic key value is mapped to a BIT STRING
795 -- according to [RFC3279].
796 nonce [1] INTEGER (0..4294967295),
797 -- Contains the nonce in the PKAuthenticator of the
798 -- request if DH keys are NOT reused,
799 -- 0 otherwise.
800 dhKeyExpiration [2] KerberosTime OPTIONAL,
801 -- Expiration time for KDC's key pair,
802 -- present if and only if DH keys are reused. If
803 -- this field is omitted then the serverDHNonce
804 -- field MUST also be omitted. See Section 3.2.3.1.
805 ...
806 }
809 3.2.3.1 Using Diffie-Hellman Key Exchange
811 In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
813 The ContentInfo [RFC3852] structure for the dhSignedData field is
814 filled in as follows:
816 1. The contentType field of the type ContentInfo is id-signedData
817 (as defined in [RFC3852]), and the content field is a SignedData
818 (as defined in [RFC3852]).
820 2. The eContentType field for the type SignedData is the OID value
821 for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
822 security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }.
824 3. The eContent field for the type SignedData contains the DER
825 encoding of the type KDCDHKeyInfo.
827 4. The signerInfos field of the type SignedData contains a single
828 signerInfo, which contains the signature over the type
829 KDCDHKeyInfo.
831 5. The certificates field of the type SignedData contains
832 certificates intended to facilitate certification path
833 construction, so that the client can verify the KDC's signature
834 over the type KDCDHKeyInfo. This field may only be left empty if
835 the KDC public key specified by the kdcPkId field in the
839 Tung & Zhu Expires August 11, 2005 [Page 15]
840 \f
841 Internet-Draft PKINIT February 2005
844 PA-PK-AS-REQ was used for signing. Otherwise, for path
845 validation, these certificates SHOULD be sufficient to construct
846 at least one certification path from the KDC certificate to one
847 trust anchor acceptable by the client [CAPATH]. If the KDC sends
848 all the X.509 certificates on a certification path to a trust
849 anchor acceptable by the client and the client can not verify the
850 KDC's public key otherwise, the client MUST process path
851 validation for the KDC's X.509 certificate based on the
852 certificates in the reply. The certificates field MUST NOT
853 contain "root" CA certificates.
855 6. If the client included the clientDHNonce field, then the KDC may
856 choose to reuse its DH keys (see Section 3.2.3.1). If the server
857 reuses DH keys then it MUST include an expiration time in the
858 dhKeyExperiation field. Past the point of the expiration time,
859 the signature over the type DHRepInfo is considered
860 expired/invalid. When the server reuses DH keys then it MUST
861 include a serverDHNonce at least as long as the length of keys
862 for the symmetric encryption system used to encrypt the AS reply.
863 Note that including the serverDHNonce changes how the client and
864 server calculate the key to use to encrypt the reply; see below
865 for details. The KDC SHOULD NOT reuse DH keys unless the
866 clientDHNonce field is present in the request.
868 The reply key for use to decrypt the KDC reply [CLAR] is derived as
869 follows:
871 1. Both the KDC and the client calculate the shared secret value as
872 follows:
874 a) When Diffie-Hellman modulo a prime p ([RFC2631]) is used, let
875 DHSharedSecret be the shared secret value.
877 b) When Elliptic Curve Diffie-Hellman (ECDH) (with each party
878 contributing one key pair) [IEEE1363] is used, let
879 DHSharedSecret be the x-coordinate of the shared secret value
880 (an elliptic curve point).
882 DHSharedSecret is first padded with leading zeros such that the
883 size of DHSharedSecret in octets is the same as that of the
884 modulus, then represented as a string of octets in big-endian
885 order.
887 Implementation note: Both the client and the KDC can cache the
888 triple (ya, yb, DHSharedSecret), where ya is the client's public
889 key and yb is the KDC's public key. If both ya and yb are the
890 same in a later exchange, the cached DHSharedSecret can be used.
895 Tung & Zhu Expires August 11, 2005 [Page 16]
896 \f
897 Internet-Draft PKINIT February 2005
900 2. Let K be the key-generation seed length [KCRYPTO] of the reply
901 key whose enctype is selected according to [CLAR].
903 3. Define the function octetstring2key() as follows:
905 octetstring2key(x) == random-to-key(K-truncate(
906 SHA1(0x00 | x) |
907 SHA1(0x01 | x) |
908 SHA1(0x02 | x) |
909 ...
910 ))
912 where x is an octet string; | is the concatenation operator; 0x00,
913 0x01, 0x02, etc., are each represented as a single octet;
914 random-to-key() is an operation that generates a protocol key from
915 a bitstring of length K; and K-truncate truncates its input to the
916 first K bits. Both K and random-to-key() are as defined in the
917 kcrypto profile [KCRYPTO] for the enctype of the reply key.
919 4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
920 the serverDHNonce; otherwise, let both n_c and n_k be empty octet
921 strings.
923 5. The reply key k is:
925 k = octetstring2key(DHSharedSecret | n_c | n_k)
928 3.2.3.2 Using Public Key Encryption
930 In this case, the PA-PK-AS-REP contains a ContentInfo structure
931 wrapped in an OCTET STRING. The reply key for use to decrypt the KDC
932 reply [CLAR] is encrypted in the encKeyPack field, which contains
933 data of type ReplyKeyPack:
935 ReplyKeyPack ::= SEQUENCE {
936 replyKey [0] EncryptionKey,
937 -- Contains the session key used to encrypt the
938 -- enc-part field in the AS-REP.
939 nonce [1] INTEGER (0..4294967295),
940 -- Contains the nonce in the PKAuthenticator of the
941 -- request.
942 ...
943 }
945 The ContentInfo [RFC3852] structure for the encKeyPack field is
946 filled in as follows:
951 Tung & Zhu Expires August 11, 2005 [Page 17]
952 \f
953 Internet-Draft PKINIT February 2005
956 1. The contentType field of the type ContentInfo is id-envelopedData
957 (as defined in [RFC3852]), and the content field is an
958 EnvelopedData (as defined in [RFC3852]).
960 2. The contentType field for the type EnvelopedData is
961 id-signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
962 pkcs (1) pkcs7 (7) signedData (2) }.
964 3. The eContentType field for the inner type SignedData (when
965 decrypted from the encryptedContent field for the type
966 EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6)
967 internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }.
969 4. The eContent field for the inner type SignedData contains the DER
970 encoding of the type ReplyKeyPack.
972 5. The signerInfos field of the inner type SignedData contains a
973 single signerInfo, which contains the signature over the type
974 ReplyKeyPack.
976 6. The certificates field of the inner type SignedData contains
977 certificates intended to facilitate certification path
978 construction, so that the client can verify the KDC's signature
979 over the type ReplyKeyPack. This field may only be left empty if
980 the KDC public key specified by the kdcPkId field in the
981 PA-PK-AS-REQ was used for signing. Otherwise, for path
982 validation, these certificates SHOULD be sufficient to construct
983 at least one certification path from the KDC certificate to one
984 trust anchor acceptable by the client [CAPATH]. If the KDC sends
985 all the X.509 certificates on a certification path to a trust
986 anchor acceptable by the client and the client can not verify the
987 KDC's public key otherwise, the client MUST process path
988 validation for the KDC's X.509 certificate based on the
989 certificates in the reply. The certificates field MUST NOT
990 contain "root" CA certificates.
992 7. The recipientInfos field of the type EnvelopedData is a SET which
993 MUST contain exactly one member of type KeyTransRecipientInfo.
994 The encryptedKey of this member contains the temporary key which
995 is encrypted using the client's public key.
997 8. The unprotectedAttrs or originatorInfo fields of the type
998 EnvelopedData MAY be present.
1000 3.2.4 Receipt of KDC Reply
1002 Upon receipt of the KDC's reply, the client proceeds as follows. If
1003 the PA-PK-AS-REP contains the dhSignedData field, the client derives
1007 Tung & Zhu Expires August 11, 2005 [Page 18]
1008 \f
1009 Internet-Draft PKINIT February 2005
1012 the reply key using the same procedure used by the KDC as defined in
1013 Section 3.2.3.1. Otherwise, the message contains the encKeyPack
1014 field, and the client decrypts and extracts the temporary key in the
1015 encryptedKey field of the member KeyTransRecipientInfo, and then uses
1016 that as the reply key.
1018 In either case, the client MUST verify the signature in the
1019 SignedData according to [RFC3852]. Unless the client can otherwise
1020 prove that the public key used to verify the KDC's signature is bound
1021 to the target KDC, it MUST verify the responder's identity as
1022 follows:
1024 1. The KDC's X.509 certificate MUST contain the EKU KeyPurposeId
1025 [RFC3280] id-pkkdcekuoid:
1027 id-pkkdcekuoid OBJECT IDENTIFIER ::=
1028 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
1029 pkinit(3) pkkdcekuoid(5) }
1030 -- Signing KDC responses.
1031 -- Key usage bits that MUST be consistent:
1032 -- digitalSignature.
1034 2. The KDC's X.509 certificate MUST contain a Subject Alternative
1035 Name (SAN) extension [RFC3280] carrying an AnotherName whose
1036 type-id is id-pksan (as defined in Section 3.2.2) and whose value
1037 contains a KRB5PrincipalName name, and the realm name of that
1038 KRB5PrincipalName matches the realm name of the target KDC. If no
1039 such SAN extension is present in the KDC's certificate, the client
1040 SHOULD accept the KDC's certificate as meeting this requirement if
1041 the KDC's X.509 certificate contains an SAN extension carrying a
1042 dNSName and that name value matches the domain style realm name
1043 [CLAR] of the target KDC. The KDC's certificate SHOULD also be
1044 accepted if it contains an SAN extension carrying a dNSName or an
1045 iPAddress (if the KDC is specified by an IP address instead of a
1046 name) and that name value matches the hostname or the IP address
1047 of the KDC with which the client believes it is communicating. If
1048 the KDC's hostname or IP address is used to match the dNSName
1049 value, it MUST have been obtained securely. Matching rules used
1050 for the dNSName value are specified in [RFC3280].
1052 Implementation note: CAs issuing KDC certificates SHOULD place all
1053 "short" and "fully-qualified" realm names of the KDC (one per SAN
1054 id-pksan extension) into the KDC certificate to allow maximum
1055 flexibility.
1057 If all applicable checks are satisfied, the client then decrypts the
1058 enc-part of the KDC-REP in the AS-REP with the reply key, and then
1059 proceeds as described in [CLAR].
1063 Tung & Zhu Expires August 11, 2005 [Page 19]
1064 \f
1065 Internet-Draft PKINIT February 2005
1068 3.3 KDC Indication of PKINIT Support
1070 If pre-authentication is required, but was not present in the
1071 request, per [CLAR] an error message with the code
1072 KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
1073 stored in the e-data field of the KRB-ERROR message to specify which
1074 pre-authentication mechanisms are acceptable. The KDC can then
1075 indicate the support of PKINIT by including an element whose
1076 padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
1078 Otherwise if it is required by the KDC's local policy that the client
1079 must be pre-authenticated using the pre-authentication mechanism
1080 specified in this document, but no PKINIT pre-authentication was
1081 present in the request, an error message with the code
1082 KDC_ERR_PREAUTH_FAILED SHOULD be returned.
1084 KDCs MUST leave the padata-value of PA_PK_AS_REQ entry in the
1085 KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
1086 STRING), and clients MUST ignore this and any other value. Future
1087 extensions to this protocol may specify other data to send instead of
1088 an empty OCTET STRING.
1090 4. Security Considerations
1092 PKINIT raises certain security considerations beyond those that can
1093 be regulated strictly in protocol definitions. We will address them
1094 in this section.
1096 Users of PKINIT must understand security policies and procedures
1097 appropriate to the use of Public Key Infrastructures [RFC3280].
1099 Standard Kerberos allows the possibility of interactions between
1100 cryptosystems of varying strengths; this document adds interactions
1101 with public-key cryptosystems to Kerberos. Some administrative
1102 policies may allow the use of relatively weak public keys. Using
1103 such keys to wrap data encrypted under stronger conventional
1104 cryptosystems may be inappropriate.
1106 PKINIT requires keys for symmetric cryptosystems to be generated.
1107 Some such systems contain "weak" keys. For recommendations regarding
1108 these weak keys, see [CLAR].
1110 PKINIT allows the use of the same RSA key pair for encryption and
1111 signing when doing RSA encryption based key delivery. This is not
1112 recommended usage of RSA keys [RFC3447], by using DH based key
1113 delivery this is avoided.
1115 Care should be taken in how certificates are chosen for the purposes
1119 Tung & Zhu Expires August 11, 2005 [Page 20]
1120 \f
1121 Internet-Draft PKINIT February 2005
1124 of authentication using PKINIT. Some local policies may require that
1125 key escrow be used for certain certificate types. Deployers of
1126 PKINIT should be aware of the implications of using certificates that
1127 have escrowed keys for the purposes of authentication. Because
1128 signing only certificates are normally not escrowed, by using DH
1129 based key delivery this is avoided.
1131 PKINIT does not provide for a "return routability" test to prevent
1132 attackers from mounting a denial-of-service attack on the KDC by
1133 causing it to perform unnecessary and expensive public-key
1134 operations. Strictly speaking, this is also true of standard
1135 Kerberos, although the potential cost is not as great, because
1136 standard Kerberos does not make use of public-key cryptography. By
1137 using DH based key delivery and reusing DH keys, the necessary crypto
1138 processing cost per request can be minimized.
1140 The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
1141 permit empty SEQUENCEs to be encoded. Such empty sequences may only
1142 be used if the KDC itself vouches for the user's certificate.
1144 5. Acknowledgements
1146 The following people have made significant contributions to this
1147 draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist
1148 Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle,
1149 Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon and Karthik
1150 Jaganathan.
1152 Special thanks to Clifford Neuman, Matthew Hur and Sasha Medvinsky
1153 who wrote earlier versions of this document.
1155 The authors are indebt to the Kerberos working group chair Jeffrey
1156 Hutzelman who kept track of various issues and was enormously helpful
1157 during the creation of this document.
1159 Some of the ideas on which this document is based arose during
1160 discussions over several years between members of the SAAG, the IETF
1161 CAT working group, and the PSRG, regarding integration of Kerberos
1162 and SPX. Some ideas have also been drawn from the DASS system.
1163 These changes are by no means endorsed by these groups. This is an
1164 attempt to revive some of the goals of those groups, and this
1165 document approaches those goals primarily from the Kerberos
1166 perspective.
1168 Lastly, comments from groups working on similar ideas in DCE have
1169 been invaluable.
1175 Tung & Zhu Expires August 11, 2005 [Page 21]
1176 \f
1177 Internet-Draft PKINIT February 2005
1180 6. IANA Considerations
1182 This document has no actions for IANA.
1184 7. References
1186 7.1 Normative References
1188 [CLAR] RFC-Editor: To be replaced by RFC number for draft-ietf-
1189 krb-wg-kerberos-clarifications. Work in Progress.
1191 [IEEE1363]
1192 IEEE, "Standard Specifications for Public Key
1193 Cryptography", IEEE 1363, 2000.
1195 [KCRYPTO] RFC-Editor: To be replaced by RFC number for draft-ietf-
1196 krb-wg-crypto. Work in Progress.
1198 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1199 Requirement Levels", BCP 14, RFC 2119, March 1997.
1201 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
1202 RFC 2412, November 1998.
1204 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
1205 RFC 2631, June 1999.
1207 [RFC3279] Bassham, L., Polk, W. and R. Housley, "Algorithms and
1208 Identifiers for the Internet X.509 Public Key
1209 Infrastructure Certificate and Certificate Revocation List
1210 (CRL) Profile", RFC 3279, April 2002.
1212 [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
1213 X.509 Public Key Infrastructure Certificate and
1214 Certificate Revocation List (CRL) Profile", RFC 3280,
1215 April 2002.
1217 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
1218 Algorithms", RFC 3370, August 2002.
1220 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
1221 Standards (PKCS) #1: RSA Cryptography Specifications
1222 Version 2.1", RFC 3447, February 2003.
1224 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
1225 Diffie-Hellman groups for Internet Key Exchange (IKE)",
1226 RFC 3526, May 2003.
1230 Tung & Zhu Expires August 11, 2005 [Page 22]
1231 \f
1232 Internet-Draft PKINIT February 2005
1235 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES)
1236 Encryption Algorithm in Cryptographic Message Syntax
1237 (CMS)", RFC 3565, July 2003.
1239 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
1240 RFC 3852, July 2004.
1242 [X690] ASN.1 encoding rules: Specification of Basic Encoding
1243 Rules (BER), Canonical Encoding Rules (CER) and
1244 Distinguished Encoding Rules (DER), ITU-T Recommendation
1245 X.690 (1997) | ISO/IEC International Standard
1246 8825-1:1998.
1248 7.2 Informative References
1250 [CAPATH] RFC-Editor: To be replaced by RFC number for draft-ietf-
1251 pkix-certpathbuild. Work in Progress.
1253 [LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
1254 Sizes", Journal of Cryptology 14 (2001) 255-293.
1256 [ODL99] Odlyzko, A., "Discrete logarithms: The past and the
1257 future, Designs, Codes, and Cryptography (1999)".
1260 Authors' Addresses
1262 Brian Tung
1263 USC Information Sciences Institute
1264 4676 Admiralty Way Suite 1001, Marina del Rey CA
1265 Marina del Rey, CA 90292
1266 US
1268 Email: brian@isi.edu
1271 Larry Zhu
1272 Microsoft Corporation
1273 One Microsoft Way
1274 Redmond, WA 98052
1275 US
1277 Email: lzhu@microsoft.com
1279 Appendix A. PKINIT ASN.1 Module
1283 Tung & Zhu Expires August 11, 2005 [Page 23]
1284 \f
1285 Internet-Draft PKINIT February 2005
1288 KerberosV5-PK-INIT-SPEC {
1289 iso(1) identified-organization(3) dod(6) internet(1)
1290 security(5) kerberosV5(2) modules(4) pkinit(5)
1291 } DEFINITIONS EXPLICIT TAGS ::= BEGIN
1293 IMPORTS
1294 SubjectPublicKeyInfo, AlgorithmIdentifier
1295 FROM PKIX1Explicit88 { iso (1)
1296 identified-organization (3) dod (6) internet (1)
1297 security (5) mechanisms (5) pkix (7) id-mod (0)
1298 id-pkix1-explicit (18) }
1299 -- As defined in RFC 3280.
1301 DomainParameters, EcpkParameters
1302 FROM PKIX1Algorithms88 { iso(1)
1303 identified-organization(3) dod(6)
1304 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
1305 id-mod-pkix1-algorithms(17) }
1306 -- As defined in RFC 3279.
1308 KerberosTime, TYPED-DATA, PrincipalName, Realm, EncryptionKey
1309 FROM KerberosV5Spec2 { iso(1) identified-organization(3)
1310 dod(6) internet(1) security(5) kerberosV5(2)
1311 modules(4) krb5spec2(2) } ;
1313 id-pkinit OBJECT IDENTIFIER ::=
1314 { iso (1) org (3) dod (6) internet (1) security (5)
1315 kerberosv5 (2) pkinit (3) }
1317 id-pkauthdata OBJECT IDENTIFIER ::= { id-pkinit 1 }
1318 id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 }
1319 id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 }
1320 id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 }
1321 id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 }
1323 pa-pk-as-req INTEGER ::= 16
1324 pa-pk-as-rep INTEGER ::= 17
1326 ad-initial-verified-cas INTEGER ::= 9
1328 td-trusted-certifiers INTEGER ::= 104
1329 td-invalid-certificates INTEGER ::= 105
1330 td-dh-parameters INTEGER ::= 109
1332 PA-PK-AS-REQ ::= SEQUENCE {
1333 signedAuthPack [0] IMPLICIT OCTET STRING,
1334 -- Contains a CMS type ContentInfo encoded
1335 -- according to [RFC3852].
1339 Tung & Zhu Expires August 11, 2005 [Page 24]
1340 \f
1341 Internet-Draft PKINIT February 2005
1344 -- The contentType field of the type ContentInfo
1345 -- is id-signedData (1.2.840.113549.1.7.2),
1346 -- and the content field is a SignedData.
1347 -- The eContentType field for the type SignedData is
1348 -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
1349 -- eContent field contains the DER encoding of the
1350 -- type AuthPack.
1351 -- AuthPack is defined below.
1352 trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,
1353 -- A list of CAs, trusted by the client, that can
1354 -- be used as the trust anchor to validate the KDC's
1355 -- signature.
1356 -- Each TrustedCA identifies a CA or a CA
1357 -- certificate (thereby its public key).
1358 kdcPkId [2] IMPLICIT OCTET STRING
1359 OPTIONAL,
1360 -- Contains a CMS type SignerIdentifier encoded
1361 -- according to [RFC3852].
1362 -- Identifies, if present, a particular KDC
1363 -- public key that the client already has.
1364 ...
1365 }
1367 DHNonce ::= OCTET STRING
1369 TrustedCA ::= CHOICE {
1370 caName [1] IMPLICIT OCTET STRING,
1371 -- Contains a PKIX type Name encoded according to
1372 -- [RFC3280].
1373 -- Identifies a CA.
1374 -- Prefer the sid field below if that is available.
1375 sid [2] IMPLICIT OCTET STRING,
1376 -- Contains a CMS type SignerIdentifier encoded
1377 -- according to [RFC3852].
1378 -- Identifies the trusted CA's certificate (and
1379 -- thereby the public key).
1380 ...
1381 }
1383 AuthPack ::= SEQUENCE {
1384 pkAuthenticator [0] PKAuthenticator,
1385 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
1386 -- Defined in [RFC3280].
1387 -- The pubic key value (the subjectPublicKey field
1388 -- of the type SubjectPublicKeyInfo) MUST be encoded
1389 -- according to [RFC3279].
1390 -- Present only if the client wishes to use the
1391 -- Diffie-Hellman key agreement method.
1395 Tung & Zhu Expires August 11, 2005 [Page 25]
1396 \f
1397 Internet-Draft PKINIT February 2005
1400 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
1401 OPTIONAL,
1402 -- List of CMS encryption types supported by
1403 -- client in order of (decreasing) preference.
1404 clientDHNonce [3] DHNonce OPTIONAL,
1405 -- Present only if the client indicates that it
1406 -- wishes to reuse DH keys or to allow the KDC to
1407 -- do so.
1408 ...
1409 }
1411 PKAuthenticator ::= SEQUENCE {
1412 cusec [0] INTEGER (0..999999),
1413 ctime [1] KerberosTime,
1414 -- cusec and ctime are used as in [CLAR], for replay
1415 -- prevention.
1416 nonce [2] INTEGER (0..4294967295),
1417 -- Chosen randomly; This nonce does not need to
1418 -- match with the nonce in the KDC-REQ-BODY.
1419 paChecksum [3] OCTET STRING,
1420 -- Contains the SHA1 checksum, performed over
1421 -- KDC-REQ-BODY.
1422 ...
1423 }
1425 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TrustedCA
1426 -- Identifies a list of CAs trusted by the KDC.
1427 -- Each TrustedCA identifies a CA or a CA
1428 -- certificate (thereby its public key).
1430 TD-INVALID-CERTIFICATES ::= SEQUENCE OF OCTET STRING
1431 -- Each OCTET STRING contains a CMS type
1432 -- IssuerAndSerialNumber encoded according to
1433 -- [RFC3852].
1434 -- Each IssuerAndSerialNumber indentifies a
1435 -- certificate (sent by the client) with an invalid
1436 -- signature.
1438 KRB5PrincipalName ::= SEQUENCE {
1439 realm [0] Realm,
1440 principalName [1] PrincipalName
1441 }
1443 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF TrustedCA
1444 -- Identifies the certification path based on which
1445 -- the client certificate was validated.
1446 -- Each TrustedCA identifies a CA or a CA
1447 -- certificate (thereby its public key).
1451 Tung & Zhu Expires August 11, 2005 [Page 26]
1452 \f
1453 Internet-Draft PKINIT February 2005
1456 PA-PK-AS-REP ::= CHOICE {
1457 dhInfo [0] DHRepInfo,
1458 -- Selected when Diffie-Hellman key exchange is
1459 -- used.
1460 encKeyPack [1] IMPLICIT OCTET STRING,
1461 -- Selected when public key encryption is used.
1462 -- Contains a CMS type ContentInfo encoded
1463 -- according to [RFC3852].
1464 -- The contentType field of the type ContentInfo is
1465 -- id-envelopedData (1.2.840.113549.1.7.3).
1466 -- The content field is an EnvelopedData.
1467 -- The contentType field for the type EnvelopedData
1468 -- is id-signedData (1.2.840.113549.1.7.2).
1469 -- The eContentType field for the inner type
1470 -- SignedData (when unencrypted) is id-pkrkeydata
1471 -- (1.2.840.113549.1.7.3) and the eContent field
1472 -- contains the DER encoding of the type
1473 -- ReplyKeyPack.
1474 -- ReplyKeyPack is defined below.
1475 ...
1476 }
1478 DHRepInfo ::= SEQUENCE {
1479 dhSignedData [0] IMPLICIT OCTET STRING,
1480 -- Contains a CMS type ContentInfo encoded according
1481 -- to [RFC3852].
1482 -- The contentType field of the type ContentInfo is
1483 -- id-signedData (1.2.840.113549.1.7.2), and the
1484 -- content field is a SignedData.
1485 -- The eContentType field for the type SignedData is
1486 -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
1487 -- eContent field contains the DER encoding of the
1488 -- type KDCDHKeyInfo.
1489 -- KDCDHKeyInfo is defined below.
1490 serverDHNonce [1] DHNonce OPTIONAL
1491 -- Present if and only if dhKeyExpiration is
1492 -- present.
1493 }
1495 KDCDHKeyInfo ::= SEQUENCE {
1496 subjectPublicKey [0] BIT STRING,
1497 -- KDC's DH public key.
1498 -- The DH pubic key value is mapped to a BIT STRING
1499 -- according to [RFC3279].
1500 nonce [1] INTEGER (0..4294967295),
1501 -- Contains the nonce in the PKAuthenticator of the
1502 -- request if DH keys are NOT reused,
1503 -- 0 otherwise.
1507 Tung & Zhu Expires August 11, 2005 [Page 27]
1508 \f
1509 Internet-Draft PKINIT February 2005
1512 dhKeyExpiration [2] KerberosTime OPTIONAL,
1513 -- Expiration time for KDC's key pair,
1514 -- present if and only if DH keys are reused. If
1515 -- this field is omitted then the serverDHNonce
1516 -- field MUST also be omitted.
1517 ...
1518 }
1520 ReplyKeyPack ::= SEQUENCE {
1521 replyKey [0] EncryptionKey,
1522 -- Contains the session key used to encrypt the
1523 -- enc-part field in the AS-REP.
1524 nonce [1] INTEGER (0..4294967295),
1525 -- Contains the nonce in the PKAuthenticator of the
1526 -- request.
1527 ...
1528 }
1530 TD-DH-PARAMETERS ::= SEQUENCE OF DHDomainParameters
1531 -- Contains a list of Diffie-Hellman domain
1532 -- parameters in decreasing preference order.
1534 DHDomainParameters ::= CHOICE {
1535 modp [0] DomainParameters,
1536 -- Type DomainParameters is defined in [RFC3279].
1537 ec [1] EcpkParameters,
1538 -- Type EcpkParameters is defined in [RFC3279].
1539 ...
1540 }
1541 END
1563 Tung & Zhu Expires August 11, 2005 [Page 28]
1564 \f
1565 Internet-Draft PKINIT February 2005
1568 Intellectual Property Statement
1570 The IETF takes no position regarding the validity or scope of any
1571 Intellectual Property Rights or other rights that might be claimed to
1572 pertain to the implementation or use of the technology described in
1573 this document or the extent to which any license under such rights
1574 might or might not be available; nor does it represent that it has
1575 made any independent effort to identify any such rights. Information
1576 on the procedures with respect to rights in RFC documents can be
1577 found in BCP 78 and BCP 79.
1579 Copies of IPR disclosures made to the IETF Secretariat and any
1580 assurances of licenses to be made available, or the result of an
1581 attempt made to obtain a general license or permission for the use of
1582 such proprietary rights by implementers or users of this
1583 specification can be obtained from the IETF on-line IPR repository at
1584 http://www.ietf.org/ipr.
1586 The IETF invites any interested party to bring to its attention any
1587 copyrights, patents or patent applications, or other proprietary
1588 rights that may cover technology that may be required to implement
1589 this standard. Please address the information to the IETF at
1590 ietf-ipr@ietf.org.
1593 Disclaimer of Validity
1595 This document and the information contained herein are provided on an
1596 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1597 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1598 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1599 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1600 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1601 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1604 Copyright Statement
1606 Copyright (C) The Internet Society (2005). This document is subject
1607 to the rights, licenses and restrictions contained in BCP 78, and
1608 except as set forth therein, the authors retain all their rights.
1611 Acknowledgment
1613 Funding for the RFC Editor function is currently provided by the
1614 Internet Society.
1619 Tung & Zhu Expires August 11, 2005 [Page 29]
1620 \f