| blob | cb13ed0bb124ad01a252b11796239fb5fdba3420 |
3 NETWORK WORKING GROUP B. Tung
4 Internet-Draft USC Information Sciences Institute
5 Expires: August 22, 2005 L. Zhu
6 Microsoft Corporation
7 February 18, 2005
10 Public Key Cryptography for Initial Authentication in Kerberos
11 draft-ietf-cat-kerberos-pk-init-25
13 Status of this Memo
15 This document is an Internet-Draft and is subject to all provisions
16 of Section 3 of RFC 3667. By submitting this Internet-Draft, each
17 author represents that any applicable patent or other IPR claims of
18 which he or she is aware have been or will be disclosed, and any of
19 which he or she become aware will be disclosed, in accordance with
20 RFC 3668.
22 Internet-Drafts are working documents of the Internet Engineering
23 Task Force (IETF), its areas, and its working groups. Note that
24 other groups may also distribute working documents as
25 Internet-Drafts.
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet-Drafts as reference
30 material or to cite them other than as "work in progress."
32 The list of current Internet-Drafts can be accessed at
33 http://www.ietf.org/ietf/1id-abstracts.txt.
35 The list of Internet-Draft Shadow Directories can be accessed at
36 http://www.ietf.org/shadow.html.
38 This Internet-Draft will expire on August 22, 2005.
40 Copyright Notice
42 Copyright (C) The Internet Society (2005).
44 Abstract
46 This document describes protocol extensions (hereafter called PKINIT)
47 to the Kerberos protocol specification. These extensions provide a
48 method for integrating public key cryptography into the initial
49 authentication exchange, by using asymmetric-key signature and/or
50 encryption algorithms in pre-authentication data fields.
54 Tung & Zhu Expires August 22, 2005 [Page 1]
55 \f
56 Internet-Draft PKINIT February 2005
59 Table of Contents
61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
62 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
63 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
64 3.1 Definitions, Requirements, and Constants . . . . . . . . . 4
65 3.1.1 Required Algorithms . . . . . . . . . . . . . . . . . 4
66 3.1.2 Defined Message and Encryption Types . . . . . . . . . 5
67 3.1.3 Algorithm Identifiers . . . . . . . . . . . . . . . . 6
68 3.2 PKINIT Pre-authentication Syntax and Use . . . . . . . . . 6
69 3.2.1 Generation of Client Request . . . . . . . . . . . . . 6
70 3.2.2 Receipt of Client Request . . . . . . . . . . . . . . 10
71 3.2.3 Generation of KDC Reply . . . . . . . . . . . . . . . 13
72 3.2.4 Receipt of KDC Reply . . . . . . . . . . . . . . . . . 19
73 3.3 Interoperability Requirements . . . . . . . . . . . . . . 20
74 3.4 KDC Indication of PKINIT Support . . . . . . . . . . . . . 20
75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21
76 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
79 7.1 Normative References . . . . . . . . . . . . . . . . . . . 23
80 7.2 Informative References . . . . . . . . . . . . . . . . . . 24
81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
82 A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 25
83 Intellectual Property and Copyright Statements . . . . . . . . 30
110 Tung & Zhu Expires August 22, 2005 [Page 2]
111 \f
112 Internet-Draft PKINIT February 2005
115 1. Introduction
117 A client typically authenticates itself to a service in Kerberos
118 using three distinct though related exchanges. First, the client
119 requests a ticket-granting ticket (TGT) from the Kerberos
120 authentication server (AS). Then, it uses the TGT to request a
121 service ticket from the Kerberos ticket-granting server (TGS).
122 Usually, the AS and TGS are integrated in a single device known as a
123 Kerberos Key Distribution Center, or KDC. (In this document, both
124 the AS and the TGS are referred to as the KDC.) Finally, the client
125 uses the service ticket to authenticate itself to the service.
127 The advantage afforded by the TGT is that the client exposes his
128 long-term secrets only once. The TGT and its associated session key
129 can then be used for any subsequent service ticket requests. One
130 result of this is that all further authentication is independent of
131 the method by which the initial authentication was performed.
132 Consequently, initial authentication provides a convenient place to
133 integrate public-key cryptography into Kerberos authentication.
135 As defined in [CLAR], Kerberos authentication exchanges use
136 symmetric-key cryptography, in part for performance. One
137 disadvantage of using symmetric-key cryptography is that the keys
138 must be shared, so that before a client can authenticate itself, he
139 must already be registered with the KDC.
141 Conversely, public-key cryptography (in conjunction with an
142 established Public Key Infrastructure) permits authentication without
143 prior registration with a KDC. Adding it to Kerberos allows the
144 widespread use of Kerberized applications by clients without
145 requiring them to register first with a KDC--a requirement that has
146 no inherent security benefit.
148 As noted above, a convenient and efficient place to introduce
149 public-key cryptography into Kerberos is in the initial
150 authentication exchange. This document describes the methods and
151 data formats for integrating public-key cryptography into Kerberos
152 initial authentication.
154 2. Conventions Used in This Document
156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
158 document are to be interpreted as described in [RFC2119].
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 KDC
162 AS reply key.
166 Tung & Zhu Expires August 22, 2005 [Page 3]
167 \f
168 Internet-Draft PKINIT February 2005
171 3. Extensions
173 This section describes extensions to [CLAR] for supporting the use of
174 public-key cryptography in the initial request for a ticket.
176 Briefly, this document defines the following extensions to [CLAR]:
178 1. The client indicates the use of public-key authentication by
179 including a special preauthenticator in the initial request. This
180 preauthenticator contains the client's public-key data and a
181 signature.
183 2. The KDC tests the client's request against its authentication
184 policy and trusted Certification Authorities (CAs).
186 3. If the request passes the verification tests, the KDC replies as
187 usual, but the reply is encrypted using either:
189 a. a key generated through a Diffie-Hellman (DH) key exchange
190 [RFC2631][IEEE1363] with the client, signed using the KDC's
191 signature key; or
193 b. a symmetric encryption key, signed using the KDC's signature
194 key and encrypted using the client's public key.
196 Any keying material required by the client to obtain the
197 encryption key for decrypting the KDC reply is returned in a
198 pre-authentication field accompanying the usual reply.
200 4. The client validates the KDC's signature, obtains the encryption
201 key, decrypts the reply, and then proceeds as usual.
203 Section 3.1 of this document enumerates the required algorithms and
204 necessary extension message types. Section 3.2 describes the
205 extension messages in greater detail.
207 3.1 Definitions, Requirements, and Constants
209 3.1.1 Required Algorithms
211 All PKINIT implementations MUST support the following algorithms:
213 o KDC AS reply key enctype: AES256-CTS-HMAC-SHA1-96 etype [RFC3961].
215 o Signature algorithm: sha-1WithRSAEncryption [RFC3279].
217 o KDC AS reply key delivery method: Diffie-Hellman key exchange
218 [RFC2631].
222 Tung & Zhu Expires August 22, 2005 [Page 4]
223 \f
226 3.1.2 Defined Message and Encryption Types
228 PKINIT makes use of the following new pre-authentication types:
230 PA_PK_AS_REQ 16
231 PA_PK_AS_REP 17
233 PKINIT also makes use of the following new authorization data type:
235 AD_INITIAL_VERIFIED_CAS 9
237 PKINIT introduces the following new error codes:
239 KDC_ERR_CLIENT_NOT_TRUSTED 62
240 KDC_ERR_INVALID_SIG 64
241 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65
242 KDC_ERR_CANT_VERIFY_CERTIFICATE 70
243 KDC_ERR_INVALID_CERTIFICATE 71
244 KDC_ERR_REVOKED_CERTIFICATE 72
245 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
246 KDC_ERR_CLIENT_NAME_MISMATCH 75
247 KDC_ERR_INCONSISTENT_KEY_PURPOSE 76
249 PKINIT uses the following typed data types for errors:
251 TD_TRUSTED_CERTIFIERS 104
252 TD_INVLID_CERTIFICATES 105
253 TD_DH_PARAMETERS 109
255 PKINIT defines the following encryption types, for use in the AS-REQ
256 message to indicate acceptance of the corresponding algorithms that
257 can used by Cryptographic Message Syntax (CMS) [RFC3852] messages in
258 the reply:
260 dsaWithSHA1-CmsOID 9
261 md5WithRSAEncryption-CmsOID 10
262 sha1WithRSAEncryption-CmsOID 11
263 rc2CBC-EnvOID 12
264 rsaEncryption-EnvOID (PKCS1 v1.5) 13
265 rsaES-OAEP-EnvOID (PKCS1 v2.0) 14
266 des-ede3-cbc-EnvOID 15
268 The ASN.1 module for all structures defined in this document (plus
269 IMPORT statements for all imported structures) is given in
270 Appendix A.
272 All structures defined in or imported into this document MUST be
273 encoded using Distinguished Encoding Rules (DER) [X690] (unless
274 otherwise noted). All data structures carried in OCTET STRINGs must
278 Tung & Zhu Expires August 22, 2005 [Page 5]
279 \f
280 Internet-Draft PKINIT February 2005
283 be encoded according to the rules specified in corresponding
284 specifications.
286 Interoperability note: Some implementations may not be able to decode
287 wrapped CMS objects encoded with BER but not DER; specifically, they
288 may not be able to decode infinite length encodings. To maximize
289 interoperability, implementers SHOULD encode CMS objects used in
290 PKINIT with DER.
292 3.1.3 Algorithm Identifiers
294 PKINIT does not define, but does make use of, the following algorithm
295 identifiers.
297 PKINIT uses the following algorithm identifiers for Diffie-Hellman
298 key agreement [RFC3279]:
300 dhpublicnumber (Diffie-Hellman modulo a prime p [RFC2631])
301 id-ecPublicKey (Elliptic Curve Diffie-Hellman [IEEE1363])
303 PKINIT uses the following signature algorithm identifiers [RFC3279]:
305 sha-1WithRSAEncryption (RSA with SHA1)
306 md5WithRSAEncryption (RSA with MD5)
307 id-dsa-with-sha1 (DSA with SHA1)
309 PKINIT uses the following encryption algorithm identifiers [RFC3447]
310 for encrypting the temporary key with a public key:
312 rsaEncryption (PKCS1 v1.5)
313 id-RSAES-OAEP (PKCS1 v2.0)
315 PKINIT uses the following algorithm identifiers [RFC3370][RFC3565]
316 for encrypting the KDC AS reply key with the temporary key:
318 des-ede3-cbc (three-key 3DES, CBC mode)
319 rc2-cbc (RC2, CBC mode)
320 id-aes256-CBC (AES-256, CBC mode)
323 3.2 PKINIT Pre-authentication Syntax and Use
325 This section defines the syntax and use of the various
326 pre-authentication fields employed by PKINIT.
328 3.2.1 Generation of Client Request
330 The initial authentication request (AS-REQ) is sent as per [CLAR]; in
334 Tung & Zhu Expires August 22, 2005 [Page 6]
335 \f
336 Internet-Draft PKINIT February 2005
339 addition, a pre-authentication data element, whose padata-type is
340 PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
341 type PA-PK-AS-REQ, is included.
343 PA-PK-AS-REQ ::= SEQUENCE {
344 signedAuthPack [0] IMPLICIT OCTET STRING,
345 -- Contains a CMS type ContentInfo encoded
346 -- according to [RFC3852].
347 -- The contentType field of the type ContentInfo
348 -- is id-signedData (1.2.840.113549.1.7.2),
349 -- and the content field is a SignedData.
350 -- The eContentType field for the type SignedData is
351 -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
352 -- eContent field contains the DER encoding of the
353 -- type AuthPack.
354 -- AuthPack is defined below.
355 trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,
356 -- A list of CAs, trusted by the client, that can
357 -- be used as the trust anchor to validate the KDC's
358 -- signature.
359 -- Each TrustedCA identifies a CA or a CA
360 -- certificate (thereby its public key).
361 kdcPkId [2] IMPLICIT OCTET STRING
362 OPTIONAL,
363 -- Contains a CMS type SignerIdentifier encoded
364 -- according to [RFC3852].
365 -- Identifies, if present, a particular KDC
366 -- public key that the client already has.
367 ...
368 }
370 DHNonce ::= OCTET STRING
372 TrustedCA ::= SEQUENCE {
373 caName [0] IMPLICIT OCTET STRING,
374 -- Contains a PKIX type Name encoded according to
375 -- [RFC3280].
376 -- Identifies a CA by the CA's distinguished subject
377 -- name.
378 certificateSerialNumber [1] INTEGER OPTIONAL,
379 -- Specifies the CA certificate's serial number.
380 -- The defintion of the certificate serial number
381 -- is taken from X.509 [X.509-97].
382 subjectKeyIdentifier [2] OCTET STRING OPTIONAL,
383 -- Identifies the CA's public key by a key
384 -- identifier. When an X.509 certificate is
385 -- referenced, this key identifier matches the X.509
386 -- subjectKeyIdentifier extension value. When other
390 Tung & Zhu Expires August 22, 2005 [Page 7]
391 \f
392 Internet-Draft PKINIT February 2005
395 -- certificate formats are referenced, the documents
396 -- that specify the certificate format and their use
397 -- with the CMS must include details on matching the
398 -- key identifier to the appropriate certificate
399 -- field.
400 ...
401 }
403 AuthPack ::= SEQUENCE {
404 pkAuthenticator [0] PKAuthenticator,
405 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
406 -- Type SubjectPublicKeyInfo is defined in
407 -- [RFC3280].
408 -- Specifies Diffie-Hellman domain parameters
409 -- and the client's public key value [IEEE1363].
410 -- The public key value (the subjectPublicKey field
411 -- of the type SubjectPublicKeyInfo) MUST be encoded
412 -- according to [RFC3279].
413 -- Present only if the client wishes to use the
414 -- Diffie-Hellman key agreement method.
415 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
416 OPTIONAL,
417 -- Type AlgorithmIdentifier is defined in
418 -- [RFC3280].
419 -- List of CMS encryption types supported by the
420 -- client in order of (decreasing) preference.
421 clientDHNonce [3] DHNonce OPTIONAL,
422 -- Present only if the client indicates that it
423 -- wishes to reuse DH keys or to allow the KDC to
424 -- do so (see Section 3.2.3.1).
425 ...
426 }
428 PKAuthenticator ::= SEQUENCE {
429 cusec [0] INTEGER (0..999999),
430 ctime [1] KerberosTime,
431 -- cusec and ctime are used as in [CLAR], for replay
432 -- prevention.
433 nonce [2] INTEGER (0..4294967295),
434 -- Chosen randomly; This nonce does not need to
435 -- match with the nonce in the KDC-REQ-BODY.
436 paChecksum [3] OCTET STRING,
437 -- Contains the SHA1 checksum, performed over
438 -- KDC-REQ-BODY.
439 ...
440 }
442 The ContentInfo [RFC3852] structure for the signedAuthPack field is
446 Tung & Zhu Expires August 22, 2005 [Page 8]
447 \f
448 Internet-Draft PKINIT February 2005
451 filled out as follows:
453 1. The contentType field of the type ContentInfo is id-signedData
454 (as defined in [RFC3852]), and the content field is a SignedData
455 (as defined in [RFC3852]).
457 2. The eContentType field for the type SignedData is id-pkauthdata:
458 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
459 pkinit(3) pkauthdata(1) }.
461 3. The eContent field for the type SignedData contains the DER
462 encoding of the type AuthPack.
464 4. The signerInfos field of the type SignedData contains a single
465 signerInfo, which contains the signature over the type AuthPack.
467 5. The certificates field of the type SignedData contains
468 certificates intended to facilitate certification path
469 construction, so that the KDC can verify the signature over the
470 type AuthPack. For path validation, these certificates SHOULD be
471 sufficient to construct at least one certification path from the
472 client certificate to one trust anchor acceptable by the KDC
473 [CAPATH]. The certificates field MUST NOT contain "root" CA
474 certificates.
476 6. The client's Diffie-Hellman public value (clientPublicValue) is
477 included if and only if the client wishes to use the
478 Diffie-Hellman key agreement method. The Diffie-Hellman domain
479 parameters for the client's public key are specified in the
480 algorithm field of the type SubjectPublicKeyInfo
481 [IEEE1363][RFC3279] and the client's Diffie-Hellman public key
482 value is mapped to a subjectPublicKey (a BIT STRING) according to
483 [RFC3279]. When using the Diffie-Hellman key agreement method,
484 implementations MUST support Oakley 1024-bit MODP well-known
485 group 2 [RFC2412] and SHOULD support Oakley 2048-bit MODP
486 well-known group 14 and Oakley 4096-bit MODP well-known group 16
487 [RFC3526].
489 The Diffie-Hellman field size should be chosen so as to provide
490 sufficient cryptographic security. The following table, based on
491 [LENSTRA], gives approximate comparable key sizes for symmetric-
492 and asymmetric-key cryptosystems based on the best-known
493 algorithms for attacking them.
502 Tung & Zhu Expires August 22, 2005 [Page 9]
503 \f
504 Internet-Draft PKINIT February 2005
507 Symmetric | ECC | DH/DSA/RSA
508 -------------+---------+------------
509 80 | 163 | 1024
510 112 | 233 | 2048
511 128 | 283 | 3072
512 192 | 409 | 7680
513 256 | 571 | 15360
515 Table 1: Comparable key sizes (in bits)
517 When Diffie-Hellma modulo a prime p is used, the exponents should
518 have at least twice as many bits as the symmetric keys that will
519 be derived from them [ODL99].
521 7. The client may wish to reuse DH keys or to allow the KDC to do so
522 (see Section 3.2.3.1). If so, then the client includes the
523 clientDHNonce field. This nonce string needs to be as long as
524 the longest key length of the symmetric key types that the client
525 supports. This nonce MUST be chosen randomly.
528 3.2.2 Receipt of Client Request
530 Upon receiving the client's request, the KDC validates it. This
531 section describes the steps that the KDC MUST (unless otherwise
532 noted) take in validating the request.
534 The KDC verifies the client's signature in the signedAuthPack field
535 according to [RFC3852].
537 If, while validating the client's X.509 certificate [RFC3280], the
538 KDC cannot build a certification path to validate the client's
539 certificate, it sends back a KRB-ERROR [CLAR] message with the code
540 KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for this
541 error message is a TYPED-DATA (as defined in [CLAR]) that contains an
542 element whose data-type is TD_TRUSTED_CERTIFIERS, and whose
543 data-value contains the DER encoding of the type
544 TD-TRUSTED-CERTIFIERS:
546 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TrustedCA
547 -- Identifies a list of CAs trusted by the KDC.
548 -- Each TrustedCA identifies a CA or a CA
549 -- certificate (thereby its public key).
551 Upon receiving this error message, the client SHOULD retry only if it
552 has a different set of certificates (from those of the previous
553 requests) that form a certification path (or a partial path) from one
554 of the trust anchors selected by the KDC to its own certificate.
558 Tung & Zhu Expires August 22, 2005 [Page 10]
559 \f
560 Internet-Draft PKINIT February 2005
563 If, while processing the certification path, the KDC determines that
564 the signature on one of the certificates in the signedAuthPack field
565 is invalid, it returns a KRB-ERROR [CLAR] message with the code
566 KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data for this error
567 message is a TYPED-DATA that contains an element whose data-type is
568 TD_INVALID_CERTIFICATES, and whose data-value contains the DER
569 encoding of the type TD-INVALID-CERTIFICATES:
571 TD-INVALID-CERTIFICATES ::= SEQUENCE OF OCTET STRING
572 -- Each OCTET STRING contains a CMS type
573 -- IssuerAndSerialNumber encoded according to
574 -- [RFC3852].
575 -- Each IssuerAndSerialNumber indentifies a
576 -- certificate (sent by the client) with an invalid
577 -- signature.
579 If more than one X.509 certificate signature is invalid, the KDC MAY
580 send one TYPED-DATA element per invalid signature.
582 Based on local policy, the KDC may also check whether any X.509
583 certificates in the certification path validating the client's
584 certificate have been revoked. If any of them have been revoked, the
585 KDC MUST return an error message with the code
586 KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
587 revocation status but is unable to do so, it SHOULD return an error
588 message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN. The
589 certificate or certificates affected are identified exactly as for
590 the error code KDC_ERR_INVALID_CERTIFICATE (see above).
592 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.
606 2. Otherwise, if the client's X.509 certificate contains a Subject
607 Alternative Name (SAN) extension [RFC3280] with a
608 KRB5PrincipalName (defined below) in the otherName field, it binds
609 the client's X.509 certificate to that name.
614 Tung & Zhu Expires August 22, 2005 [Page 11]
615 \f
616 Internet-Draft PKINIT February 2005
619 The otherName field (of type AnotherName) in the SAN extension
620 MUST contain KRB5PrincipalName as defined below.
622 The type-id field of the type AnotherName is id-pksan:
624 id-pksan OBJECT IDENTIFIER ::=
625 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
626 x509-sanan (2) }
628 The value field of the type AnotherName is the DER encoding of the
629 following ASN.1 type:
631 KRB5PrincipalName ::= SEQUENCE {
632 realm [0] Realm,
633 principalName [1] PrincipalName
634 }
636 If the KDC does not have its own binding and there is no
637 KRB5PrincipalName name present in the client's X.509 certificate, and
638 if the Kerberos name in the request does not match the
639 KRB5PrincipalName in the client's X.509 certificate (including the
640 realm name), the KDC MUST return an error message with the code
641 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for
642 this error message.
644 The KDC MAY require the presence of an Extended Key Usage (EKU)
645 KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the
646 client's X.509 certificate:
648 id-pkekuoid OBJECT IDENTIFIER ::=
649 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
650 pkinit(3) pkekuoid(4) }
651 -- PKINIT client authentication.
652 -- Key usage bits that MUST be consistent:
653 -- digitalSignature;
654 -- Key usage bits that MAY be consistent:
655 -- nonRepudiation, and (keyEncipherment or keyAgreement).
657 If this EKU is required but is missing, the KDC MUST return an error
658 message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE. There is no
659 accompanying e-data for this error message. KDCs implementing this
660 requirement SHOULD also accept the EKU KeyPurposeId id-ms-sc-logon
661 (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there are a
662 large number of X.509 client certificates deployed for use with
663 PKINIT which have this EKU.
665 If for any other reasons, the client's public key is not accepted,
666 the KDC MUST return an error message with the code
670 Tung & Zhu Expires August 22, 2005 [Page 12]
671 \f
672 Internet-Draft PKINIT February 2005
675 KDC_ERR_CLIENT_NOT_TRUSTED.
677 The KDC MUST check the timestamp to ensure that the request is not a
678 replay, and that the time skew falls within acceptable limits. The
679 recommendations for clock skew times in [CLAR] apply here. If the
680 check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
681 KRB_AP_ERR_SKEW, respectively.
683 If the clientPublicValue is filled in, indicating that the client
684 wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
685 check to see if the key parameters satisfy its policy. If they do
686 not, it MUST return an error message with the code
687 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The accompanying e-data is a
688 TYPED-DATA that contains an element whose data-type is
689 TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
690 the type TD-DH-PARAMETERS:
692 TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
693 -- Each AlgorithmIdentifier specifies a set of
694 -- Diffie-Hellman domain parameters [IEEE1363].
695 -- This list is in decreasing preference order.
697 TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
698 that the KDC supports in decreasing preference order, from which the
699 client SHOULD pick one to retry the request.
701 If the client included a kdcPkId field in the PA-PK-AS-REQ and the
702 KDC does not possess the corresponding key, the KDC MUST ignore the
703 kdcPkId field as if the client did not include one.
705 If the client included a trustedCertifiers field, and the KDC does
706 not possesses the private key for any one of the listed certifiers,
707 the KDC MUST ignore the trustedCertifiers field as if the client did
708 not include any.
710 If there is a supportedCMSTypes field in the AuthPack, the KDC must
711 check to see if it supports any of the listed types. If it supports
712 more than one of the types, the KDC SHOULD use the one listed first.
713 If it does not support any of them, it MUST return an error message
714 with the code KDC_ERR_ETYPE_NOSUPP [CLAR].
716 3.2.3 Generation of KDC Reply
718 Assuming that the client's request has been properly validated, the
719 KDC proceeds as per [CLAR], except as follows.
721 The KDC MUST set the initial flag and include an authorization data
722 element of ad-type [CLAR] AD_INITIAL_VERIFIED_CAS in the issued
726 Tung & Zhu Expires August 22, 2005 [Page 13]
727 \f
728 Internet-Draft PKINIT February 2005
731 ticket. The ad-data [CLAR] field contains the DER encoding of the
732 type AD-INITIAL-VERIFIED-CAS:
734 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF TrustedCA
735 -- Identifies the certification path based on which
736 -- the client certificate was validated.
737 -- Each TrustedCA identifies a CA or a CA
738 -- certificate (thereby its public key).
740 The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
741 containers if the list of CAs satisfies the AS' realm's local policy
742 (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
743 [CLAR]). Furthermore, any TGS MUST copy such authorization data from
744 tickets used in a PA-TGS-REQ [CLAR] of the TGS-REQ to the resulting
745 ticket, and it can wrap or unwrap the data into or out-of the
746 AD-IF-RELEVANT container, depends on if the list of CAs satisfies the
747 TGS' realm's local policy.
749 Application servers that understand this authorization data type
750 SHOULD apply local policy to determine whether a given ticket bearing
751 such a type *not* contained within an AD-IF-RELEVANT container is
752 acceptable. (This corresponds to the AP server checking the
753 transited field when the TRANSITED-POLICY-CHECKED flag has not been
754 set [CLAR].) If such a data type is contained within an
755 AD-IF-RELEVANT container, AP servers MAY apply local policy to
756 determine whether the authorization data is acceptable.
758 The content of the AS-REP is otherwise unchanged from [CLAR]. The
759 KDC encrypts the reply as usual, but not with the client's long-term
760 key. Instead, it encrypts it with either a shared key derived from a
761 Diffie-Hellman exchange, or a generated encryption key. The contents
762 of the PA-PK-AS-REP indicate which key delivery method is used:
764 PA-PK-AS-REP ::= CHOICE {
765 dhInfo [0] DHRepInfo,
766 -- Selected when Diffie-Hellman key exchange is
767 -- used.
768 encKeyPack [1] IMPLICIT OCTET STRING,
769 -- Selected when public key encryption is used.
770 -- Contains a CMS type ContentInfo encoded
771 -- according to [RFC3852].
772 -- The contentType field of the type ContentInfo is
773 -- id-envelopedData (1.2.840.113549.1.7.3).
774 -- The content field is an EnvelopedData.
775 -- The contentType field for the type EnvelopedData
776 -- is id-signedData (1.2.840.113549.1.7.2).
777 -- The eContentType field for the inner type
778 -- SignedData (when unencrypted) is id-pkrkeydata
782 Tung & Zhu Expires August 22, 2005 [Page 14]
783 \f
784 Internet-Draft PKINIT February 2005
787 -- (1.2.840.113549.1.7.3) and the eContent field
788 -- contains the DER encoding of the type
789 -- ReplyKeyPack.
790 -- ReplyKeyPack is defined in Section 3.2.3.2.
791 ...
792 }
794 DHRepInfo ::= SEQUENCE {
795 dhSignedData [0] IMPLICIT OCTET STRING,
796 -- Contains a CMS type ContentInfo encoded according
797 -- to [RFC3852].
798 -- The contentType field of the type ContentInfo is
799 -- id-signedData (1.2.840.113549.1.7.2), and the
800 -- content field is a SignedData.
801 -- The eContentType field for the type SignedData is
802 -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
803 -- eContent field contains the DER encoding of the
804 -- type KDCDHKeyInfo.
805 -- KDCDHKeyInfo is defined below.
806 serverDHNonce [1] DHNonce OPTIONAL
807 -- Present if and only if dhKeyExpiration is
808 -- present in the KDCDHKeyInfo.
809 }
811 KDCDHKeyInfo ::= SEQUENCE {
812 subjectPublicKey [0] BIT STRING,
813 -- KDC's DH public key.
814 -- The DH pubic key value is mapped to a BIT STRING
815 -- according to [RFC3279].
816 nonce [1] INTEGER (0..4294967295),
817 -- Contains the nonce in the PKAuthenticator of the
818 -- request if DH keys are NOT reused,
819 -- 0 otherwise.
820 dhKeyExpiration [2] KerberosTime OPTIONAL,
821 -- Expiration time for KDC's key pair,
822 -- present if and only if DH keys are reused. If
823 -- this field is omitted then the serverDHNonce
824 -- field MUST also be omitted. See Section 3.2.3.1.
825 ...
826 }
829 3.2.3.1 Using Diffie-Hellman Key Exchange
831 In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
833 The ContentInfo [RFC3852] structure for the dhSignedData field is
834 filled in as follows:
838 Tung & Zhu Expires August 22, 2005 [Page 15]
839 \f
840 Internet-Draft PKINIT February 2005
843 1. The contentType field of the type ContentInfo is id-signedData
844 (as defined in [RFC3852]), and the content field is a SignedData
845 (as defined in [RFC3852]).
847 2. The eContentType field for the type SignedData is the OID value
848 for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
849 security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }.
851 3. The eContent field for the type SignedData contains the DER
852 encoding of the type KDCDHKeyInfo.
854 4. The signerInfos field of the type SignedData contains a single
855 signerInfo, which contains the signature over the type
856 KDCDHKeyInfo.
858 5. The certificates field of the type SignedData contains
859 certificates intended to facilitate certification path
860 construction, so that the client can verify the KDC's signature
861 over the type KDCDHKeyInfo. This field may only be left empty if
862 the KDC public key specified by the kdcPkId field in the
863 PA-PK-AS-REQ was used for signing. Otherwise, for path
864 validation, these certificates SHOULD be sufficient to construct
865 at least one certification path from the KDC certificate to one
866 trust anchor acceptable by the client [CAPATH]. The certificates
867 field MUST NOT contain "root" CA certificates.
869 6. If the client included the clientDHNonce field, then the KDC may
870 choose to reuse its DH keys (see Section 3.2.3.1). If the server
871 reuses DH keys then it MUST include an expiration time in the
872 dhKeyExperiation field. Past the point of the expiration time,
873 the signature over the type DHRepInfo is considered
874 expired/invalid. When the server reuses DH keys then it MUST
875 include a serverDHNonce at least as long as the length of keys
876 for the symmetric encryption system used to encrypt the AS reply.
877 Note that including the serverDHNonce changes how the client and
878 server calculate the key to use to encrypt the reply; see below
879 for details. The KDC SHOULD NOT reuse DH keys unless the
880 clientDHNonce field is present in the request.
882 The KDC AS reply key is derived as follows:
884 1. Both the KDC and the client calculate the shared secret value as
885 follows:
887 a) When Diffie-Hellman modulo a prime p ([RFC2631]) is used, let
888 DHSharedSecret be the shared secret value.
894 Tung & Zhu Expires August 22, 2005 [Page 16]
895 \f
896 Internet-Draft PKINIT February 2005
899 b) When Elliptic Curve Diffie-Hellman (ECDH) (with each party
900 contributing one key pair) [IEEE1363] is used, let
901 DHSharedSecret be the x-coordinate of the shared secret value
902 (an elliptic curve point).
904 DHSharedSecret is first padded with leading zeros such that the
905 size of DHSharedSecret in octets is the same as that of the
906 modulus, then represented as a string of octets in big-endian
907 order.
909 Implementation note: Both the client and the KDC can cache the
910 triple (ya, yb, DHSharedSecret), where ya is the client's public
911 key and yb is the KDC's public key. If both ya and yb are the
912 same in a later exchange, the cached DHSharedSecret can be used.
914 2. Let K be the key-generation seed length [RFC3961] of the KDC AS
915 reply key whose enctype is selected according to [CLAR].
917 3. Define the function octetstring2key() as follows:
919 octetstring2key(x) == random-to-key(K-truncate(
920 SHA1(0x00 | x) |
921 SHA1(0x01 | x) |
922 SHA1(0x02 | x) |
923 ...
924 ))
926 where x is an octet string; | is the concatenation operator; 0x00,
927 0x01, 0x02, etc., are each represented as a single octet;
928 random-to-key() is an operation that generates a protocol key from
929 a bitstring of length K; and K-truncate truncates its input to the
930 first K bits. Both K and random-to-key() are as defined in the
931 kcrypto profile [RFC3961] for the enctype of the KDC AS reply key.
933 4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
934 the serverDHNonce; otherwise, let both n_c and n_k be empty octet
935 strings.
937 5. The KDC AS reply key k is:
939 k = octetstring2key(DHSharedSecret | n_c | n_k)
942 3.2.3.2 Using Public Key Encryption
944 In this case, the PA-PK-AS-REP contains a ContentInfo structure
945 wrapped in an OCTET STRING. The KDC AS reply key is encrypted in the
946 encKeyPack field, which contains data of type ReplyKeyPack:
950 Tung & Zhu Expires August 22, 2005 [Page 17]
951 \f
952 Internet-Draft PKINIT February 2005
955 ReplyKeyPack ::= SEQUENCE {
956 replyKey [0] EncryptionKey,
957 -- Contains the session key used to encrypt the
958 -- enc-part field in the AS-REP.
959 nonce [1] INTEGER (0..4294967295),
960 -- Contains the nonce in the PKAuthenticator of the
961 -- request.
962 ...
963 }
965 The ContentInfo [RFC3852] structure for the encKeyPack field is
966 filled in as follows:
968 1. The contentType field of the type ContentInfo is id-envelopedData
969 (as defined in [RFC3852]), and the content field is an
970 EnvelopedData (as defined in [RFC3852]).
972 2. The contentType field for the type EnvelopedData is
973 id-signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
974 pkcs (1) pkcs7 (7) signedData (2) }.
976 3. The eContentType field for the inner type SignedData (when
977 decrypted from the encryptedContent field for the type
978 EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6)
979 internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }.
981 4. The eContent field for the inner type SignedData contains the DER
982 encoding of the type ReplyKeyPack.
984 5. The signerInfos field of the inner type SignedData contains a
985 single signerInfo, which contains the signature over the type
986 ReplyKeyPack.
988 6. The certificates field of the inner type SignedData contains
989 certificates intended to facilitate certification path
990 construction, so that the client can verify the KDC's signature
991 over the type ReplyKeyPack. This field may only be left empty if
992 the KDC public key specified by the kdcPkId field in the
993 PA-PK-AS-REQ was used for signing. Otherwise, for path
994 validation, these certificates SHOULD be sufficient to construct
995 at least one certification path from the KDC certificate to one
996 trust anchor acceptable by the client [CAPATH]. The certificates
997 field MUST NOT contain "root" CA certificates.
999 7. The recipientInfos field of the type EnvelopedData is a SET which
1000 MUST contain exactly one member of type KeyTransRecipientInfo.
1001 The encryptedKey of this member contains the temporary key which
1002 is encrypted using the client's public key.
1006 Tung & Zhu Expires August 22, 2005 [Page 18]
1007 \f
1009 8. The unprotectedAttrs or originatorInfo fields of the type
1010 EnvelopedData MAY be present.
1012 3.2.4 Receipt of KDC Reply
1014 Upon receipt of the KDC's reply, the client proceeds as follows. If
1015 the PA-PK-AS-REP contains the dhSignedData field, the client derives
1016 the KDC AS reply key using the same procedure used by the KDC as
1017 defined in Section 3.2.3.1. Otherwise, the message contains the
1018 encKeyPack field, and the client decrypts and extracts the temporary
1019 key in the encryptedKey field of the member KeyTransRecipientInfo,
1020 and then uses that as the KDC AS reply key.
1022 In either case, the client MUST verify the signature in the
1023 SignedData according to [RFC3852]. Unless the client can otherwise
1024 prove that the public key used to verify the KDC's signature is bound
1025 to the target KDC, the KDC's X.509 certificate MUST satisfy at least
1026 one of the following two requirements:
1028 1. The certificate contains a Subject Alternative Name (SAN)
1029 extension [RFC3280] carrying a dNSName and that name value
1030 matches the following name format:
1032 _Service._Proto.Realm
1034 Where the Service name is the string literal "kerberos", the
1035 Proto can be "udp" or "tcp", and the Realm is the domain style
1036 Kerberos realm name [CLAR] of the target KDC. This name format
1037 is identical to the owner label format used in the DNS SRV
1038 records for specifying the KDC location as described in [CLAR].
1039 For example, the X.509 certificate for the KDC of the Kerberos
1040 realm "EXAMPLE.COM" would contain a dNSName value of
1041 "_kerberos._tcp.EXAMPLE.COM" or "_kerberos._udp.EXAMPLE.COM".
1043 2. The certificate contains the EKU KeyPurposeId [RFC3280]
1044 id-pkkdcekuoid (defined below) and an SAN extension [RFC3280]
1045 carrying an AnotherName whose type-id is id-pksan (as defined in
1046 Section 3.2.2) and whose value contains a KRB5PrincipalName name,
1047 and the realm name of that KRB5PrincipalName matches the realm
1048 name of the target KDC.
1050 id-pkkdcekuoid OBJECT IDENTIFIER ::=
1051 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
1052 pkinit(3) pkkdcekuoid(5) }
1053 -- Signing KDC responses.
1054 -- Key usage bits that MUST be consistent:
1055 -- digitalSignature.
1057 If no SAN id-pksan extension is present (but the id-pkkdcekuoid
1058 EKU is) in the KDC's X.509 certificate, and the client has a
1062 Tung & Zhu Expires August 22, 2005 [Page 19]
1063 \f
1064 Internet-Draft PKINIT February 2005
1067 priori knowledge of the KDC's hostname (or IP address), the
1068 client SHOULD accept the KDC's X.509 certificate if that
1069 certificate contains an SAN extension carrying a dNSName and the
1070 dNSName value matches the hostname (or the IP address) of the KDC
1071 with which the client believes it is communicating.
1073 Matching rules used for the dNSName value are specified in [RFC3280].
1075 If all applicable checks are satisfied, the client then decrypts the
1076 enc-part field of the KDC-REP in the AS-REP using the KDC AS reply
1077 key, and then proceeds as described in [CLAR].
1079 Implementation note: CAs issuing KDC certificates SHOULD place all
1080 "short" and "fully-qualified" Kerberos realm names of the KDC (one
1081 per SAN extension) into the KDC certificate to allow maximum
1082 flexibility.
1084 3.3 Interoperability Requirements
1086 The client MUST be capable of sending a set of certificates
1087 sufficient to allow the KDC to construct a certification path for the
1088 client's certificate, if the correct set of certificates is provided
1089 through configuration or policy.
1091 If the client sends all the X.509 certificates on a certification
1092 path to a trust anchor acceptable by the KDC, and the KDC can not
1093 verify the client's public key otherwise, the KDC MUST be able to
1094 process path validation for the client's certificate based on the
1095 certificates in the request.
1097 The KDC MUST be capable of sending a set of certificates sufficient
1098 to allow the client to construct a certification path for the KDC's
1099 certificate, if the correct set of certificates is provided through
1100 configuration or policy.
1102 If the KDC sends all the X.509 certificates on a certification path
1103 to a trust anchor acceptable by the client, and the client can not
1104 verify the KDC's public key otherwise, the client MUST be able to
1105 process path validation for the KDC's certificate based on the
1106 certificates in the reply.
1108 3.4 KDC Indication of PKINIT Support
1110 If pre-authentication is required, but was not present in the
1111 request, per [CLAR] an error message with the code
1112 KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
1113 stored in the e-data field of the KRB-ERROR message to specify which
1114 pre-authentication mechanisms are acceptable. The KDC can then
1118 Tung & Zhu Expires August 22, 2005 [Page 20]
1119 \f
1120 Internet-Draft PKINIT February 2005
1123 indicate the support of PKINIT by including an empty element whose
1124 padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
1126 Otherwise if it is required by the KDC's local policy that the client
1127 must be pre-authenticated using the pre-authentication mechanism
1128 specified in this document, but no PKINIT pre-authentication was
1129 present in the request, an error message with the code
1130 KDC_ERR_PREAUTH_FAILED SHOULD be returned.
1132 KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
1133 the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
1134 STRING), and clients MUST ignore this and any other value. Future
1135 extensions to this protocol may specify other data to send instead of
1136 an empty OCTET STRING.
1138 4. Security Considerations
1140 PKINIT raises certain security considerations beyond those that can
1141 be regulated strictly in protocol definitions. We will address them
1142 in this section.
1144 PKINIT extends the cross-realm model to the public-key
1145 infrastructure. Users of PKINIT must understand security policies
1146 and procedures appropriate to the use of Public Key Infrastructures
1147 [RFC3280].
1149 Standard Kerberos allows the possibility of interactions between
1150 cryptosystems of varying strengths; this document adds interactions
1151 with public-key cryptosystems to Kerberos. Some administrative
1152 policies may allow the use of relatively weak public keys. Using
1153 such keys to wrap data encrypted under stronger conventional
1154 cryptosystems may be inappropriate.
1156 PKINIT requires keys for symmetric cryptosystems to be generated.
1157 Some such systems contain "weak" keys. For recommendations regarding
1158 these weak keys, see [CLAR].
1160 PKINIT allows the use of the same RSA key pair for encryption and
1161 signing when doing RSA encryption based key delivery. This is not
1162 recommended usage of RSA keys [RFC3447], by using DH based key
1163 delivery this is avoided.
1165 Care should be taken in how certificates are chosen for the purposes
1166 of authentication using PKINIT. Some local policies may require that
1167 key escrow be used for certain certificate types. Deployers of
1168 PKINIT should be aware of the implications of using certificates that
1169 have escrowed keys for the purposes of authentication. Because
1170 signing only certificates are normally not escrowed, by using DH
1174 Tung & Zhu Expires August 22, 2005 [Page 21]
1175 \f
1176 Internet-Draft PKINIT February 2005
1179 based key delivery this is avoided.
1181 PKINIT does not provide for a "return routability" test to prevent
1182 attackers from mounting a denial-of-service attack on the KDC by
1183 causing it to perform unnecessary and expensive public-key
1184 operations. Strictly speaking, this is also true of standard
1185 Kerberos, although the potential cost is not as great, because
1186 standard Kerberos does not make use of public-key cryptography. By
1187 using DH based key delivery and reusing DH keys, the necessary crypto
1188 processing cost per request can be minimized.
1190 The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
1191 permit empty SEQUENCEs to be encoded. Such empty sequences may only
1192 be used if the KDC itself vouches for the user's certificate.
1194 5. Acknowledgements
1196 The following people have made significant contributions to this
1197 draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist
1198 Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle,
1199 Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik Jaganathan
1200 and Chaskiel M Grundman.
1202 Special thanks to Clifford Neuman, Matthew Hur and Sasha Medvinsky
1203 who wrote earlier versions of this document.
1205 The authors are indebt to the Kerberos working group chair Jeffrey
1206 Hutzelman who kept track of various issues and was enormously helpful
1207 during the creation of this document.
1209 Some of the ideas on which this document is based arose during
1210 discussions over several years between members of the SAAG, the IETF
1211 CAT working group, and the PSRG, regarding integration of Kerberos
1212 and SPX. Some ideas have also been drawn from the DASS system.
1213 These changes are by no means endorsed by these groups. This is an
1214 attempt to revive some of the goals of those groups, and this
1215 document approaches those goals primarily from the Kerberos
1216 perspective.
1218 Lastly, comments from groups working on similar ideas in DCE have
1219 been invaluable.
1221 6. IANA Considerations
1223 This document has no actions for IANA.
1230 Tung & Zhu Expires August 22, 2005 [Page 22]
1231 \f
1232 Internet-Draft PKINIT February 2005
1235 7. References
1237 7.1 Normative References
1239 [CLAR] RFC-Editor: To be replaced by RFC number for draft-ietf-
1240 krb-wg-kerberos-clarifications. Work in Progress.
1242 [IEEE1363]
1243 IEEE, "Standard Specifications for Public Key
1244 Cryptography", IEEE 1363, 2000.
1246 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1247 Requirement Levels", BCP 14, RFC 2119, March 1997.
1249 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
1250 RFC 2412, November 1998.
1252 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
1253 RFC 2631, June 1999.
1255 [RFC3279] Bassham, L., Polk, W. and R. Housley, "Algorithms and
1256 Identifiers for the Internet X.509 Public Key
1257 Infrastructure Certificate and Certificate Revocation List
1258 (CRL) Profile", RFC 3279, April 2002.
1260 [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
1261 X.509 Public Key Infrastructure Certificate and
1262 Certificate Revocation List (CRL) Profile", RFC 3280,
1263 April 2002.
1265 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
1266 Algorithms", RFC 3370, August 2002.
1268 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
1269 Standards (PKCS) #1: RSA Cryptography Specifications
1270 Version 2.1", RFC 3447, February 2003.
1272 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
1273 Diffie-Hellman groups for Internet Key Exchange (IKE)",
1274 RFC 3526, May 2003.
1276 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES)
1277 Encryption Algorithm in Cryptographic Message Syntax
1278 (CMS)", RFC 3565, July 2003.
1280 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
1281 RFC 3852, July 2004.
1285 Tung & Zhu Expires August 22, 2005 [Page 23]
1286 \f
1287 Internet-Draft PKINIT February 2005
1290 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
1291 Kerberos 5", RFC 3961, February 2005.
1293 [X.509-97] ITU-T. Recommendation X.509: The Directory - Authentication
1294 Framework. 1997.
1296 [X690] ASN.1 encoding rules: Specification of Basic Encoding
1297 Rules (BER), Canonical Encoding Rules (CER) and
1298 Distinguished Encoding Rules (DER), ITU-T Recommendation
1299 X.690 (1997) | ISO/IEC International Standard
1300 8825-1:1998.
1302 7.2 Informative References
1304 [CAPATH] RFC-Editor: To be replaced by RFC number for draft-ietf-
1305 pkix-certpathbuild. Work in Progress.
1307 [LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
1308 Sizes", Journal of Cryptology 14 (2001) 255-293.
1310 [ODL99] Odlyzko, A., "Discrete logarithms: The past and the
1311 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 August 22, 2005 [Page 24]
1337 \f
1338 Internet-Draft PKINIT February 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 August 22, 2005 [Page 25]
1393 \f
1394 Internet-Draft PKINIT February 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 as the trust anchor to validate the KDC's
1408 -- signature.
1409 -- Each TrustedCA identifies a CA or a CA
1410 -- certificate (thereby its public key).
1411 kdcPkId [2] IMPLICIT OCTET STRING
1412 OPTIONAL,
1413 -- Contains a CMS type SignerIdentifier encoded
1414 -- according to [RFC3852].
1415 -- Identifies, if present, a particular KDC
1416 -- public key that the client already has.
1417 ...
1418 }
1420 DHNonce ::= OCTET STRING
1422 TrustedCA ::= SEQUENCE {
1423 caName [0] IMPLICIT OCTET STRING,
1424 -- Contains a PKIX type Name encoded according to
1425 -- [RFC3280].
1426 -- Identifies a CA by the CA's distinguished subject
1427 -- name.
1428 certificateSerialNumber [1] INTEGER OPTIONAL,
1429 -- Specifies the CA certificate's serial number.
1430 -- The defintion of the certificate serial number
1431 -- is taken from X.509 [X.509-97].
1432 subjectKeyIdentifier [2] OCTET STRING OPTIONAL,
1433 -- Identifies the CA's public key by a key
1434 -- identifier. When an X.509 certificate is
1435 -- referenced, this key identifier matches the X.509
1436 -- subjectKeyIdentifier extension value. When other
1437 -- certificate formats are referenced, the documents
1438 -- that specify the certificate format and their use
1439 -- with the CMS must include details on matching the
1440 -- key identifier to the appropriate certificate
1441 -- field.
1442 ...
1443 }
1448 Tung & Zhu Expires August 22, 2005 [Page 26]
1449 \f
1450 Internet-Draft PKINIT February 2005
1453 AuthPack ::= SEQUENCE {
1454 pkAuthenticator [0] PKAuthenticator,
1455 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
1456 -- Type SubjectPublicKeyInfo is defined in
1457 -- [RFC3280].
1458 -- Specifies Diffie-Hellman domain parameters
1459 -- and the client's public key value [IEEE1363].
1460 -- The public key value (the subjectPublicKey field
1461 -- of the type SubjectPublicKeyInfo) MUST be encoded
1462 -- according to [RFC3279].
1463 -- Present only if the client wishes to use the
1464 -- Diffie-Hellman key agreement method.
1465 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
1466 OPTIONAL,
1467 -- Type AlgorithmIdentifier is defined in
1468 -- [RFC3280].
1469 -- List of CMS encryption types supported by the
1470 -- client in order of (decreasing) preference.
1471 clientDHNonce [3] DHNonce OPTIONAL,
1472 -- Present only if the client indicates that it
1473 -- wishes to reuse DH keys or to allow the KDC to
1474 -- do so.
1475 ...
1476 }
1478 PKAuthenticator ::= SEQUENCE {
1479 cusec [0] INTEGER (0..999999),
1480 ctime [1] KerberosTime,
1481 -- cusec and ctime are used as in [CLAR], for replay
1482 -- prevention.
1483 nonce [2] INTEGER (0..4294967295),
1484 -- Chosen randomly; This nonce does not need to
1485 -- match with the nonce in the KDC-REQ-BODY.
1486 paChecksum [3] OCTET STRING,
1487 -- Contains the SHA1 checksum, performed over
1488 -- KDC-REQ-BODY.
1489 ...
1490 }
1492 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TrustedCA
1493 -- Identifies a list of CAs trusted by the KDC.
1494 -- Each TrustedCA identifies a CA or a CA
1495 -- certificate (thereby its public key).
1497 TD-INVALID-CERTIFICATES ::= SEQUENCE OF OCTET STRING
1498 -- Each OCTET STRING contains a CMS type
1499 -- IssuerAndSerialNumber encoded according to
1500 -- [RFC3852].
1504 Tung & Zhu Expires August 22, 2005 [Page 27]
1505 \f
1506 Internet-Draft PKINIT February 2005
1509 -- Each IssuerAndSerialNumber indentifies a
1510 -- certificate (sent by the client) with an invalid
1511 -- signature.
1513 KRB5PrincipalName ::= SEQUENCE {
1514 realm [0] Realm,
1515 principalName [1] PrincipalName
1516 }
1518 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF TrustedCA
1519 -- Identifies the certification path based on which
1520 -- the client certificate was validated.
1521 -- Each TrustedCA identifies a CA or a CA
1522 -- certificate (thereby its public key).
1524 PA-PK-AS-REP ::= CHOICE {
1525 dhInfo [0] DHRepInfo,
1526 -- Selected when Diffie-Hellman key exchange is
1527 -- used.
1528 encKeyPack [1] IMPLICIT OCTET STRING,
1529 -- Selected when public key encryption is used.
1530 -- Contains a CMS type ContentInfo encoded
1531 -- according to [RFC3852].
1532 -- The contentType field of the type ContentInfo is
1533 -- id-envelopedData (1.2.840.113549.1.7.3).
1534 -- The content field is an EnvelopedData.
1535 -- The contentType field for the type EnvelopedData
1536 -- is id-signedData (1.2.840.113549.1.7.2).
1537 -- The eContentType field for the inner type
1538 -- SignedData (when unencrypted) is id-pkrkeydata
1539 -- (1.2.840.113549.1.7.3) and the eContent field
1540 -- contains the DER encoding of the type
1541 -- ReplyKeyPack.
1542 -- ReplyKeyPack is defined below.
1543 ...
1544 }
1546 DHRepInfo ::= SEQUENCE {
1547 dhSignedData [0] IMPLICIT OCTET STRING,
1548 -- Contains a CMS type ContentInfo encoded according
1549 -- to [RFC3852].
1550 -- The contentType field of the type ContentInfo is
1551 -- id-signedData (1.2.840.113549.1.7.2), and the
1552 -- content field is a SignedData.
1553 -- The eContentType field for the type SignedData is
1554 -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
1555 -- eContent field contains the DER encoding of the
1556 -- type KDCDHKeyInfo.
1560 Tung & Zhu Expires August 22, 2005 [Page 28]
1561 \f
1562 Internet-Draft PKINIT February 2005
1565 -- KDCDHKeyInfo is defined below.
1566 serverDHNonce [1] DHNonce OPTIONAL
1567 -- Present if and only if dhKeyExpiration is
1568 -- present.
1569 }
1571 KDCDHKeyInfo ::= SEQUENCE {
1572 subjectPublicKey [0] BIT STRING,
1573 -- KDC's DH public key.
1574 -- The DH pubic key value is mapped to a BIT STRING
1575 -- according to [RFC3279].
1576 nonce [1] INTEGER (0..4294967295),
1577 -- Contains the nonce in the PKAuthenticator of the
1578 -- request if DH keys are NOT reused,
1579 -- 0 otherwise.
1580 dhKeyExpiration [2] KerberosTime OPTIONAL,
1581 -- Expiration time for KDC's key pair,
1582 -- present if and only if DH keys are reused. If
1583 -- this field is omitted then the serverDHNonce
1584 -- field MUST also be omitted.
1585 ...
1586 }
1588 ReplyKeyPack ::= SEQUENCE {
1589 replyKey [0] EncryptionKey,
1590 -- Contains the session key used to encrypt the
1591 -- enc-part field in the AS-REP.
1592 nonce [1] INTEGER (0..4294967295),
1593 -- Contains the nonce in the PKAuthenticator of the
1594 -- request.
1595 ...
1596 }
1598 TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
1599 -- Each AlgorithmIdentifier specifies a set of
1600 -- Diffie-Hellman domain parameters [IEEE1363].
1601 -- This list is in decreasing preference order.
1602 END
1616 Tung & Zhu Expires August 22, 2005 [Page 29]
1617 \f
1618 Internet-Draft PKINIT February 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 August 22, 2005 [Page 30]
1673 \f