| blob | ab4aeb58c4c8750e9e6b854630b101695bb77301 |
1 NETWORK WORKING GROUP B. Tung
2 Internet-Draft USC Information Sciences Institute
3 Expires: January 20, 2006 L. Zhu
4 Microsoft Corporation
5 July 19, 2005
8 Public Key Cryptography for Initial Authentication in Kerberos
9 draft-ietf-cat-kerberos-pk-init-27
11 Status of this Memo
13 By submitting this Internet-Draft, each author represents that any
14 applicable patent or other IPR claims of which he or she is aware
15 have been or will be disclosed, and any of which he or she becomes
16 aware will be disclosed, in accordance with Section 6 of BCP 79.
18 Internet-Drafts are working documents of the Internet Engineering
19 Task Force (IETF), its areas, and its working groups. Note that
20 other groups may also distribute working documents as Internet-
21 Drafts.
23 Internet-Drafts are draft documents valid for a maximum of six months
24 and may be updated, replaced, or obsoleted by other documents at any
25 time. It is inappropriate to use Internet-Drafts as reference
26 material or to cite them other than as "work in progress."
28 The list of current Internet-Drafts can be accessed at
29 http://www.ietf.org/ietf/1id-abstracts.txt.
31 The list of Internet-Draft Shadow Directories can be accessed at
32 http://www.ietf.org/shadow.html.
34 This Internet-Draft will expire on January 20, 2006.
36 Copyright Notice
38 Copyright (C) The Internet Society (2005).
40 Abstract
42 This document describes protocol extensions (hereafter called PKINIT)
43 to the Kerberos protocol specification. These extensions provide a
44 method for integrating public key cryptography into the initial
45 authentication exchange, by using asymmetric-key signature and/or
46 encryption algorithms in pre-authentication data fields.
52 Tung & Zhu Expires January 20, 2006 [Page 1]
53 \f
54 Internet-Draft PKINIT July 2005
57 Table of Contents
59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
60 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
61 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
62 3.1 Definitions, Requirements, and Constants . . . . . . . . . 4
63 3.1.1 Required Algorithms . . . . . . . . . . . . . . . . . 4
64 3.1.2 Defined Message and Encryption Types . . . . . . . . . 5
65 3.1.3 Algorithm Identifiers . . . . . . . . . . . . . . . . 6
66 3.2 PKINIT Pre-authentication Syntax and Use . . . . . . . . . 7
67 3.2.1 Generation of Client Request . . . . . . . . . . . . . 7
68 3.2.2 Receipt of Client Request . . . . . . . . . . . . . . 10
69 3.2.3 Generation of KDC Reply . . . . . . . . . . . . . . . 14
70 3.2.4 Receipt of KDC Reply . . . . . . . . . . . . . . . . . 19
71 3.3 Interoperability Requirements . . . . . . . . . . . . . . 20
72 3.4 KDC Indication of PKINIT Support . . . . . . . . . . . . . 21
73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21
74 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
77 7.1 Normative References . . . . . . . . . . . . . . . . . . . 23
78 7.2 Informative References . . . . . . . . . . . . . . . . . . 24
79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
80 A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 25
81 Intellectual Property and Copyright Statements . . . . . . . . 31
108 Tung & Zhu Expires January 20, 2006 [Page 2]
109 \f
110 Internet-Draft PKINIT July 2005
113 1. Introduction
115 A client typically authenticates itself to a service in Kerberos
116 using three distinct though related exchanges. First, the client
117 requests a ticket-granting ticket (TGT) from the Kerberos
118 authentication server (AS). Then, it uses the TGT to request a
119 service ticket from the Kerberos ticket-granting server (TGS).
120 Usually, the AS and TGS are integrated in a single device known as a
121 Kerberos Key Distribution Center, or KDC. Finally, the client uses
122 the service ticket to authenticate itself to the service.
124 The advantage afforded by the TGT is that the client exposes his
125 long-term secrets only once. The TGT and its associated session key
126 can then be used for any subsequent service ticket requests. One
127 result of this is that all further authentication is independent of
128 the method by which the initial authentication was performed.
129 Consequently, initial authentication provides a convenient place to
130 integrate public-key cryptography into Kerberos authentication.
132 As defined in [RFC4120], Kerberos authentication exchanges use
133 symmetric-key cryptography, in part for performance. One
134 disadvantage of using symmetric-key cryptography is that the keys
135 must be shared, so that before a client can authenticate itself, he
136 must already be registered with the KDC.
138 Conversely, public-key cryptography (in conjunction with an
139 established Public Key Infrastructure) permits authentication without
140 prior registration with a KDC. Adding it to Kerberos allows the
141 widespread use of Kerberized applications by clients without
142 requiring them to register first with a KDC--a requirement that has
143 no inherent security benefit.
145 As noted above, a convenient and efficient place to introduce public-
146 key cryptography into Kerberos is in the initial authentication
147 exchange. This document describes the methods and data formats for
148 integrating public-key cryptography into Kerberos initial
149 authentication.
151 2. Conventions Used in This Document
153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
155 document are to be interpreted as described in [RFC2119].
157 Both the AS and the TGS are referred to as the KDC.
159 In this document, the encryption key used to encrypt the enc-part
160 field of the KDC-REP in the AS-REP [RFC4120] is referred to as the AS
164 Tung & Zhu Expires January 20, 2006 [Page 3]
165 \f
166 Internet-Draft PKINIT July 2005
169 reply key.
171 3. Extensions
173 This section describes extensions to [RFC4120] for supporting the use
174 of public-key cryptography in the initial request for a ticket.
176 Briefly, this document defines the following extensions to [RFC4120]:
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 pre-
198 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 AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-
214 sha1-96 [RFC3962].
220 Tung & Zhu Expires January 20, 2006 [Page 4]
221 \f
222 Internet-Draft PKINIT July 2005
225 o Signature algorithm: sha-1WithRSAEncryption [RFC3279].
227 o AS reply key delivery method: Diffie-Hellman key exchange
228 [RFC2631].
231 3.1.2 Defined Message and Encryption Types
233 PKINIT makes use of the following new pre-authentication types:
235 PA_PK_AS_REQ 16
236 PA_PK_AS_REP 17
238 PKINIT also makes use of the following new authorization data type:
240 AD_INITIAL_VERIFIED_CAS 9
242 PKINIT introduces the following new error codes:
244 KDC_ERR_CLIENT_NOT_TRUSTED 62
245 KDC_ERR_INVALID_SIG 64
246 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65
247 KDC_ERR_CANT_VERIFY_CERTIFICATE 70
248 KDC_ERR_INVALID_CERTIFICATE 71
249 KDC_ERR_REVOKED_CERTIFICATE 72
250 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
251 KDC_ERR_CLIENT_NAME_MISMATCH 75
252 KDC_ERR_INCONSISTENT_KEY_PURPOSE 76
254 PKINIT uses the following typed data types for errors:
256 TD_TRUSTED_CERTIFIERS 104
257 TD_INVALID_CERTIFICATES 105
258 TD_DH_PARAMETERS 109
260 PKINIT defines the following encryption types, for use in the AS-REQ
261 message to indicate acceptance of the corresponding algorithms that
262 can used by Cryptographic Message Syntax (CMS) [RFC3852] messages in
263 the reply:
265 dsaWithSHA1-CmsOID 9
266 md5WithRSAEncryption-CmsOID 10
267 sha1WithRSAEncryption-CmsOID 11
268 rc2CBC-EnvOID 12
269 rsaEncryption-EnvOID (PKCS1 v1.5) 13
270 rsaES-OAEP-EnvOID (PKCS1 v2.0) 14
271 des-ede3-cbc-EnvOID 15
276 Tung & Zhu Expires January 20, 2006 [Page 5]
277 \f
278 Internet-Draft PKINIT July 2005
281 The ASN.1 module for all structures defined in this document (plus
282 IMPORT statements for all imported structures) is given in
283 Appendix A.
285 All structures defined in or imported into this document MUST be
286 encoded using Distinguished Encoding Rules (DER) [X690] (unless
287 otherwise noted). All data structures carried in OCTET STRINGs must
288 be encoded according to the rules specified in corresponding
289 specifications.
291 Interoperability note: Some implementations may not be able to decode
292 wrapped CMS objects encoded with BER but not DER; specifically, they
293 may not be able to decode infinite length encodings. To maximize
294 interoperability, implementers SHOULD encode CMS objects used in
295 PKINIT with DER.
297 3.1.3 Algorithm Identifiers
299 PKINIT does not define, but does make use of, the following algorithm
300 identifiers.
302 PKINIT uses the following algorithm identifier(s) for Diffie-Hellman
303 key agreement [RFC3279]:
305 dhpublicnumber (Modular Exponential Diffie-Hellman [RFC2631])
307 PKINIT uses the following signature algorithm identifiers [RFC3279]:
309 sha-1WithRSAEncryption (RSA with SHA1)
310 md5WithRSAEncryption (RSA with MD5)
311 id-dsa-with-sha1 (DSA with SHA1)
313 PKINIT uses the following encryption algorithm identifiers [RFC3447]
314 for encrypting the temporary key with a public key:
316 rsaEncryption (PKCS1 v1.5)
317 id-RSAES-OAEP (PKCS1 v2.0)
319 PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565]
320 for encrypting the AS reply key with the temporary key:
322 des-ede3-cbc (three-key 3DES, CBC mode)
323 rc2-cbc (RC2, CBC mode)
324 id-aes256-CBC (AES-256, CBC mode)
332 Tung & Zhu Expires January 20, 2006 [Page 6]
333 \f
334 Internet-Draft PKINIT July 2005
337 3.2 PKINIT Pre-authentication Syntax and Use
339 This section defines the syntax and use of the various pre-
340 authentication fields employed by PKINIT.
342 3.2.1 Generation of Client Request
344 The initial authentication request (AS-REQ) is sent as per [RFC4120];
345 in addition, a pre-authentication data element, whose padata-type is
346 PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
347 type PA-PK-AS-REQ, is included.
349 PA-PK-AS-REQ ::= SEQUENCE {
350 signedAuthPack [0] IMPLICIT OCTET STRING,
351 -- Contains a CMS type ContentInfo encoded
352 -- according to [RFC3852].
353 -- The contentType field of the type ContentInfo
354 -- is id-signedData (1.2.840.113549.1.7.2),
355 -- and the content field is a SignedData.
356 -- The eContentType field for the type SignedData is
357 -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
358 -- eContent field contains the DER encoding of the
359 -- type AuthPack.
360 -- AuthPack is defined below.
361 trustedCertifiers [1] SEQUENCE OF
362 ExternalPrincipalIdentifier OPTIONAL,
363 -- A list of CAs, trusted by the client, that can
364 -- be used to certify the KDC.
365 -- Each ExternalPrincipalIdentifier identifies a CA
366 -- or a CA certificate (thereby its public key).
367 -- The information contained in the
368 -- trustedCertifiers SHOULD be used by the KDC as
369 -- hints to guide its selection of an appropriate
370 -- certificate chain to return to the client.
371 kdcPkId [2] IMPLICIT OCTET STRING
372 OPTIONAL,
373 -- Contains a CMS type SignerIdentifier encoded
374 -- according to [RFC3852].
375 -- Identifies, if present, a particular KDC
376 -- public key that the client already has.
377 ...
378 }
380 DHNonce ::= OCTET STRING
382 ExternalPrincipalIdentifier ::= SEQUENCE {
383 subjectName [0] IMPLICIT OCTET STRING OPTIONAL,
384 -- Contains a PKIX type Name encoded according to
388 Tung & Zhu Expires January 20, 2006 [Page 7]
389 \f
390 Internet-Draft PKINIT July 2005
393 -- [RFC3280].
394 -- Identifies the certificate subject by the
395 -- distinguished subject name.
396 -- REQUIRED when there is a distinguished subject
397 -- name present in the certificate.
398 issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL,
399 -- Contains a CMS type IssuerAndSerialNumber encoded
400 -- according to [RFC3852].
401 -- Identifies a certificate of the subject.
402 -- REQUIRED for TD-INVALID-CERTIFICATES and
403 -- TD-TRUSTED-CERTIFIERS.
404 subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL,
405 -- Identifies the subject's public key by a key
406 -- identifier. When an X.509 certificate is
407 -- referenced, this key identifier matches the X.509
408 -- subjectKeyIdentifier extension value. When other
409 -- certificate formats are referenced, the documents
410 -- that specify the certificate format and their use
411 -- with the CMS must include details on matching the
412 -- key identifier to the appropriate certificate
413 -- field.
414 -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
415 ...
416 }
418 AuthPack ::= SEQUENCE {
419 pkAuthenticator [0] PKAuthenticator,
420 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
421 -- Type SubjectPublicKeyInfo is defined in
422 -- [RFC3280].
423 -- Specifies Diffie-Hellman domain parameters
424 -- and the client's public key value [IEEE1363].
425 -- The DH public key value is encoded as a BIT
426 -- STRING, as specified in Section 2.3.3 of
427 -- [RFC3279].
428 -- This field is present only if the client wishes
429 -- to use the Diffie-Hellman key agreement method.
430 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
431 OPTIONAL,
432 -- Type AlgorithmIdentifier is defined in
433 -- [RFC3280].
434 -- List of CMS encryption types supported by the
435 -- client in order of (decreasing) preference.
436 clientDHNonce [3] DHNonce OPTIONAL,
437 -- Present only if the client indicates that it
438 -- wishes to reuse DH keys or to allow the KDC to
439 -- do so (see Section 3.2.3.1).
440 ...
444 Tung & Zhu Expires January 20, 2006 [Page 8]
445 \f
446 Internet-Draft PKINIT July 2005
449 }
451 PKAuthenticator ::= SEQUENCE {
452 cusec [0] INTEGER (0..999999),
453 ctime [1] KerberosTime,
454 -- cusec and ctime are used as in [RFC4120], for
455 -- replay prevention.
456 nonce [2] INTEGER (0..4294967295),
457 -- Chosen randomly; This nonce does not need to
458 -- match with the nonce in the KDC-REQ-BODY.
459 paChecksum [3] OCTET STRING,
460 -- Contains the SHA1 checksum, performed over
461 -- KDC-REQ-BODY.
462 ...
463 }
465 The ContentInfo [RFC3852] structure for the signedAuthPack field is
466 filled out as follows:
468 1. The contentType field of the type ContentInfo is id-signedData
469 (as defined in [RFC3852]), and the content field is a SignedData
470 (as defined in [RFC3852]).
472 2. The eContentType field for the type SignedData is id-pkauthdata:
473 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
474 pkinit(3) pkauthdata(1) }.
476 3. The eContent field for the type SignedData contains the DER
477 encoding of the type AuthPack.
479 4. The signerInfos field of the type SignedData contains a single
480 signerInfo, which contains the signature over the type AuthPack.
482 5. The certificates field of the type SignedData contains
483 certificates intended to facilitate certification path
484 construction, so that the KDC can verify the signature over the
485 type AuthPack. For path validation, these certificates SHOULD be
486 sufficient to construct at least one certification path from the
487 client certificate to one trust anchor acceptable by the KDC
488 [CAPATH]. The client MUST be capable of including such a set of
489 certificates if configured to do so. The certificates field MUST
490 NOT contain "root" CA certificates.
492 6. The client's Diffie-Hellman public value (clientPublicValue) is
493 included if and only if the client wishes to use the Diffie-
494 Hellman key agreement method. The Diffie-Hellman domain
495 parameters [IEEE1363] for the client's public key are specified
496 in the algorithm field of the type SubjectPublicKeyInfo [RFC3279]
500 Tung & Zhu Expires January 20, 2006 [Page 9]
501 \f
502 Internet-Draft PKINIT July 2005
505 and the client's Diffie-Hellman public key value is mapped to a
506 subjectPublicKey (a BIT STRING) according to [RFC3279]. When
507 using the Diffie-Hellman key agreement method, implementations
508 MUST support Oakley 1024-bit Modular Exponential (MODP) well-
509 known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group
510 14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known
511 group 16 [RFC3526].
513 The Diffie-Hellman field size should be chosen so as to provide
514 sufficient cryptographic security [RFC3766].
516 When MODP Diffie-Hellman is used, the exponents should have at
517 least twice as many bits as the symmetric keys that will be
518 derived from them [ODL99].
520 7. The client may wish to reuse DH keys or to allow the KDC to do so
521 (see Section 3.2.3.1). If so, then the client includes the
522 clientDHNonce field. This nonce string needs to be as long as
523 the longest key length of the symmetric key types that the client
524 supports. This nonce MUST be chosen randomly.
527 3.2.2 Receipt of Client Request
529 Upon receiving the client's request, the KDC validates it. This
530 section describes the steps that the KDC MUST (unless otherwise
531 noted) take in validating the request.
533 The KDC verifies the client's signature in the signedAuthPack field
534 according to [RFC3852].
536 If, while validating the client's X.509 certificate [RFC3280], the
537 KDC cannot build a certification path to validate the client's
538 certificate, it sends back a KRB-ERROR [RFC4120] message with the
539 code KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for
540 this error message is a TYPED-DATA (as defined in [RFC4120]) that
541 contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and
542 whose data-value contains the DER encoding of the type TD-TRUSTED-
543 CERTIFIERS:
545 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
546 ExternalPrincipalIdentifier
547 -- Identifies a list of CAs trusted by the KDC.
548 -- Each ExternalPrincipalIdentifier identifies a CA
549 -- or a CA 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
556 Tung & Zhu Expires January 20, 2006 [Page 10]
557 \f
558 Internet-Draft PKINIT July 2005
561 requests) that form a certification path (or a partial path) from one
562 of the trust anchors acceptable by the KDC to its own certificate.
564 If, while processing the certification path, the KDC determines that
565 the signature on one of the certificates in the signedAuthPack field
566 is invalid, it returns a KRB-ERROR [RFC4120] message with the code
567 KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data for this error
568 message is a TYPED-DATA that contains an element whose data-type is
569 TD_INVALID_CERTIFICATES, and whose data-value contains the DER
570 encoding of the type TD-INVALID-CERTIFICATES:
572 TD-INVALID-CERTIFICATES ::= SEQUENCE OF
573 ExternalPrincipalIdentifier
574 -- Each ExternalPrincipalIdentifier identifies a
575 -- certificate (sent by the client) with an invalid
576 -- signature.
578 If more than one X.509 certificate signature is invalid, the KDC MAY
579 include one IssuerAndSerialNumber per invalid signature within the
580 TD-INVALID-CERTIFICATES.
582 The client's X.509 certificate is validated according to [RFC3280].
584 Based on local policy, the KDC may also check whether any X.509
585 certificates in the certification path validating the client's
586 certificate have been revoked. If any of them have been revoked, the
587 KDC MUST return an error message with the code
588 KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
589 revocation status but is unable to do so, it SHOULD return an error
590 message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN. The
591 certificate or certificates affected are identified exactly as for
592 the error code KDC_ERR_INVALID_CERTIFICATE (see above).
594 Note that the TD_INVALID_CERTIFICATES error data is only used to
595 identify invalid certificates sent by the client in the request.
597 The client's public key is then used to verify the signature. If the
598 signature fails to verify, the KDC MUST return an error message with
599 the code KDC_ERR_INVALID_SIG. There is no accompanying e-data for
600 this error message.
602 In addition to validating the client's signature, the KDC MUST also
603 check that the client's public key used to verify the client's
604 signature is bound to the client's principal name as specified in the
605 AS-REQ as follows:
612 Tung & Zhu Expires January 20, 2006 [Page 11]
613 \f
614 Internet-Draft PKINIT July 2005
617 1. If the KDC has its own binding between either the client's
618 signature-verification public key or the client's certificate and
619 the client's Kerberos principal name, it uses that binding.
621 2. Otherwise, if the client's X.509 certificate contains a Subject
622 Alternative Name (SAN) extension carrying a KRB5PrincipalName
623 (defined below) in the otherName field of the type GeneralName
624 [RFC3280], it binds the client's X.509 certificate to that name.
626 The type of the otherName field is AnotherName. The type-id field
627 of the type AnotherName is id-pksan:
629 id-pksan OBJECT IDENTIFIER ::=
630 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
631 x509-sanan (2) }
633 And the value field of the type AnotherName is a
634 KRB5PrincipalName.
636 KRB5PrincipalName ::= SEQUENCE {
637 realm [0] Realm,
638 principalName [1] PrincipalName
639 }
641 If the KDC does not have its own binding and there is no
642 KRB5PrincipalName name present in the client's X.509 certificate, or
643 if the Kerberos name in the request does not match the
644 KRB5PrincipalName in the client's X.509 certificate (including the
645 realm name), the KDC MUST return an error message with the code
646 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for
647 this error message.
649 Even if the certification path is validated and the certificate is
650 mapped to the client's principal name, the KDC may decide not to
651 accept the client's certificate, depending on local policy.
653 The KDC MAY require the presence of an Extended Key Usage (EKU)
654 KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the
655 client's X.509 certificate:
657 id-pkekuoid OBJECT IDENTIFIER ::=
658 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
659 pkinit(3) pkekuoid(4) }
660 -- PKINIT client authentication.
661 -- Key usage bits that MUST be consistent:
662 -- digitalSignature.
664 If this EKU KeyPurposeId is required but it is not present or if the
668 Tung & Zhu Expires January 20, 2006 [Page 12]
669 \f
670 Internet-Draft PKINIT July 2005
673 client certificate is restricted not to be used for PKINIT client
674 authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
675 an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE. There
676 is no accompanying e-data for this error message. KDCs implementing
677 this requirement SHOULD also accept the EKU KeyPurposeId id-ms-sc-
678 logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there
679 are a large number of X.509 client certificates deployed for use with
680 PKINIT which have this EKU.
682 As a matter of local policy, the KDC MAY decide to reject requests on
683 the basis of the absence or presence of other specific EKU OID's.
685 If the client's public key is not accepted, the KDC returns an error
686 message with the code KDC_ERR_CLIENT_NOT_TRUSTED.
688 The KDC MUST check the timestamp to ensure that the request is not a
689 replay, and that the time skew falls within acceptable limits. The
690 recommendations for clock skew times in [RFC4120] apply here. If the
691 check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
692 KRB_AP_ERR_SKEW, respectively.
694 If the clientPublicValue is filled in, indicating that the client
695 wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
696 check to see if the key parameters satisfy its policy. If they do
697 not, it MUST return an error message with the code
698 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The accompanying e-data is a
699 TYPED-DATA that contains an element whose data-type is
700 TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
701 the type TD-DH-PARAMETERS:
703 TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
704 -- Each AlgorithmIdentifier specifies a set of
705 -- Diffie-Hellman domain parameters [IEEE1363].
706 -- This list is in decreasing preference order.
708 TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
709 that the KDC supports in decreasing preference order, from which the
710 client SHOULD pick one to retry the request.
712 If the client included a kdcPkId field in the PA-PK-AS-REQ and the
713 KDC does not possess the corresponding key, the KDC MUST ignore the
714 kdcPkId field as if the client did not include one.
716 If there is a supportedCMSTypes field in the AuthPack, the KDC must
717 check to see if it supports any of the listed types. If it supports
718 more than one of the types, the KDC SHOULD use the one listed first.
719 If it does not support any of them, it MUST return an error message
720 with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].
724 Tung & Zhu Expires January 20, 2006 [Page 13]
725 \f
726 Internet-Draft PKINIT July 2005
729 3.2.3 Generation of KDC Reply
731 Assuming that the client's request has been properly validated, the
732 KDC proceeds as per [RFC4120], except as follows.
734 The KDC MUST set the initial flag and include an authorization data
735 element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued
736 ticket. The ad-data [RFC4120] field contains the DER encoding of the
737 type AD-INITIAL-VERIFIED-CAS:
739 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
740 ExternalPrincipalIdentifier
741 -- Identifies the certification path based on which
742 -- the client certificate was validated.
743 -- Each ExternalPrincipalIdentifier identifies a CA
744 -- or a CA certificate (thereby its public key).
746 The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
747 containers if the list of CAs satisfies the AS' realm's local policy
748 (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
749 [RFC4120]). Furthermore, any TGS MUST copy such authorization data
750 from tickets used within a PA-TGS-REQ of the TGS-REQ into the
751 resulting ticket. If the list of CAs satisfies the local KDC's
752 realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT
753 container, otherwise it MAY unwrap the authorization data out of the
754 AD-IF-RELEVANT container.
756 Application servers that understand this authorization data type
757 SHOULD apply local policy to determine whether a given ticket bearing
758 such a type *not* contained within an AD-IF-RELEVANT container is
759 acceptable. (This corresponds to the AP server checking the
760 transited field when the TRANSITED-POLICY-CHECKED flag has not been
761 set [RFC4120].) If such a data type is contained within an AD-IF-
762 RELEVANT container, AP servers MAY apply local policy to determine
763 whether the authorization data is acceptable.
765 The content of the AS-REP is otherwise unchanged from [RFC4120]. The
766 KDC encrypts the reply as usual, but not with the client's long-term
767 key. Instead, it encrypts it with either a shared key derived from a
768 Diffie-Hellman exchange, or a generated encryption key. The contents
769 of the PA-PK-AS-REP indicate which key delivery method is used:
771 PA-PK-AS-REP ::= CHOICE {
772 dhInfo [0] DHRepInfo,
773 -- Selected when Diffie-Hellman key exchange is
774 -- used.
775 encKeyPack [1] IMPLICIT OCTET STRING,
776 -- Selected when public key encryption is used.
780 Tung & Zhu Expires January 20, 2006 [Page 14]
781 \f
782 Internet-Draft PKINIT July 2005
785 -- Contains a CMS type ContentInfo encoded
786 -- according to [RFC3852].
787 -- The contentType field of the type ContentInfo is
788 -- id-envelopedData (1.2.840.113549.1.7.3).
789 -- The content field is an EnvelopedData.
790 -- The contentType field for the type EnvelopedData
791 -- is id-signedData (1.2.840.113549.1.7.2).
792 -- The eContentType field for the inner type
793 -- SignedData (when unencrypted) is id-pkrkeydata
794 -- (1.2.840.113549.1.7.3) and the eContent field
795 -- contains the DER encoding of the type
796 -- ReplyKeyPack.
797 -- ReplyKeyPack is defined in Section 3.2.3.2.
798 ...
799 }
801 DHRepInfo ::= SEQUENCE {
802 dhSignedData [0] IMPLICIT OCTET STRING,
803 -- Contains a CMS type ContentInfo encoded according
804 -- to [RFC3852].
805 -- The contentType field of the type ContentInfo is
806 -- id-signedData (1.2.840.113549.1.7.2), and the
807 -- content field is a SignedData.
808 -- The eContentType field for the type SignedData is
809 -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
810 -- eContent field contains the DER encoding of the
811 -- type KDCDHKeyInfo.
812 -- KDCDHKeyInfo is defined below.
813 serverDHNonce [1] DHNonce OPTIONAL
814 -- Present if and only if dhKeyExpiration is
815 -- present in the KDCDHKeyInfo.
816 }
818 KDCDHKeyInfo ::= SEQUENCE {
819 subjectPublicKey [0] BIT STRING,
820 -- KDC's DH public key.
821 -- The DH public key value is encoded as a BIT
822 -- STRING, as specified in Section 2.3.3 of
823 -- [RFC3279].
824 nonce [1] INTEGER (0..4294967295),
825 -- Contains the nonce in the PKAuthenticator of the
826 -- request if DH keys are NOT reused,
827 -- 0 otherwise.
828 dhKeyExpiration [2] KerberosTime OPTIONAL,
829 -- Expiration time for KDC's key pair,
830 -- present if and only if DH keys are reused. If
831 -- this field is omitted then the serverDHNonce
832 -- field MUST also be omitted. See Section 3.2.3.1.
836 Tung & Zhu Expires January 20, 2006 [Page 15]
837 \f
838 Internet-Draft PKINIT July 2005
841 ...
842 }
845 3.2.3.1 Using Diffie-Hellman Key Exchange
847 In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
849 The ContentInfo [RFC3852] structure for the dhSignedData field is
850 filled in as follows:
852 1. The contentType field of the type ContentInfo is id-signedData
853 (as defined in [RFC3852]), and the content field is a SignedData
854 (as defined in [RFC3852]).
856 2. The eContentType field for the type SignedData is the OID value
857 for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
858 security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }.
860 3. The eContent field for the type SignedData contains the DER
861 encoding of the type KDCDHKeyInfo.
863 4. The signerInfos field of the type SignedData contains a single
864 signerInfo, which contains the signature over the type
865 KDCDHKeyInfo.
867 5. The certificates field of the type SignedData contains
868 certificates intended to facilitate certification path
869 construction, so that the client can verify the KDC's signature
870 over the type KDCDHKeyInfo. The information contained in the
871 trustedCertifiers in the request SHOULD be used by the KDC as
872 hints to guide its selection of an appropriate certificate chain
873 to return to the client. This field may only. be left empty if
874 the KDC public key specified by the kdcPkId field in the PA-PK-
875 AS-REQ was used for signing. Otherwise, for path validation,
876 these certificates SHOULD be sufficient to construct at least one
877 certification path from the KDC certificate to one trust anchor
878 acceptable by the client [CAPATH]. The KDC MUST be capable of
879 including such a set of certificates if configured to do so. The
880 certificates field MUST NOT contain "root" CA certificates.
882 6. If the client included the clientDHNonce field, then the KDC may
883 choose to reuse its DH keys (see Section 3.2.3.1). If the server
884 reuses DH keys then it MUST include an expiration time in the
885 dhKeyExpiration field. Past the point of the expiration time,
886 the signature over the type DHRepInfo is considered expired/
887 invalid. When the server reuses DH keys then it MUST include a
888 serverDHNonce at least as long as the length of keys for the
892 Tung & Zhu Expires January 20, 2006 [Page 16]
893 \f
894 Internet-Draft PKINIT July 2005
897 symmetric encryption system used to encrypt the AS reply. Note
898 that including the serverDHNonce changes how the client and
899 server calculate the key to use to encrypt the reply; see below
900 for details. The KDC SHOULD NOT reuse DH keys unless the
901 clientDHNonce field is present in the request.
903 The AS reply key is derived as follows:
905 1. Both the KDC and the client calculate the shared secret value as
906 follows:
908 a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
909 shared secret value. DHSharedSecret is the value ZZ as
910 described in Section 2.1.1 of [RFC2631].
912 DHSharedSecret is first padded with leading zeros such that the
913 size of DHSharedSecret in octets is the same as that of the
914 modulus, then represented as a string of octets in big-endian
915 order.
917 Implementation note: Both the client and the KDC can cache the
918 triple (ya, yb, DHSharedSecret), where ya is the client's public
919 key and yb is the KDC's public key. If both ya and yb are the
920 same in a later exchange, the cached DHSharedSecret can be used.
922 2. Let K be the key-generation seed length [RFC3961] of the AS reply
923 key whose enctype is selected according to [RFC4120].
925 3. Define the function octetstring2key() as follows:
927 octetstring2key(x) == random-to-key(K-truncate(
928 SHA1(0x00 | x) |
929 SHA1(0x01 | x) |
930 SHA1(0x02 | x) |
931 ...
932 ))
934 where x is an octet string; | is the concatenation operator; 0x00,
935 0x01, 0x02, etc., are each represented as a single octet; random-
936 to-key() is an operation that generates a protocol key from a
937 bitstring of length K; and K-truncate truncates its input to the
938 first K bits. Both K and random-to-key() are as defined in the
939 kcrypto profile [RFC3961] for the enctype of the AS reply key.
948 Tung & Zhu Expires January 20, 2006 [Page 17]
949 \f
950 Internet-Draft PKINIT July 2005
953 4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
954 the serverDHNonce; otherwise, let both n_c and n_k be empty octet
955 strings.
957 5. The AS reply key k is:
959 k = octetstring2key(DHSharedSecret | n_c | n_k)
962 3.2.3.2 Using Public Key Encryption
964 In this case, the PA-PK-AS-REP contains a ContentInfo structure
965 wrapped in an OCTET STRING. The AS reply key is encrypted in the
966 encKeyPack field, which contains data of type ReplyKeyPack:
968 ReplyKeyPack ::= SEQUENCE {
969 replyKey [0] EncryptionKey,
970 -- Contains the session key used to encrypt the
971 -- enc-part field in the AS-REP.
972 asChecksum [1] Checksum,
973 -- Contains the checksum of the AS-REQ
974 -- corresponding to the containing AS-REP.
975 -- The checksum is performed over the type AS-REQ.
976 -- The protocol key [RFC3961] of the checksum is the
977 -- replyKey and the key usage number is 6.
978 -- If the replyKey's enctype is "newer" [RFC4120]
979 -- [RFC4121], the checksum is the required
980 -- checksum operation [RFC3961] for that enctype.
981 -- The client MUST verify this checksum upon receipt
982 -- of the AS-REP.
983 ...
984 }
986 The ContentInfo [RFC3852] structure for the encKeyPack field is
987 filled in as follows:
989 1. The contentType field of the type ContentInfo is id-envelopedData
990 (as defined in [RFC3852]), and the content field is an
991 EnvelopedData (as defined in [RFC3852]).
993 2. The contentType field for the type EnvelopedData is id-
994 signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
995 pkcs (1) pkcs7 (7) signedData (2) }.
997 3. The eContentType field for the inner type SignedData (when
998 decrypted from the encryptedContent field for the type
999 EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6)
1000 internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }.
1004 Tung & Zhu Expires January 20, 2006 [Page 18]
1005 \f
1006 Internet-Draft PKINIT July 2005
1009 4. The eContent field for the inner type SignedData contains the DER
1010 encoding of the type ReplyKeyPack.
1012 5. The signerInfos field of the inner type SignedData contains a
1013 single signerInfo, which contains the signature over the type
1014 ReplyKeyPack.
1016 6. The certificates field of the inner type SignedData contains
1017 certificates intended to facilitate certification path
1018 construction, so that the client can verify the KDC's signature
1019 over the type ReplyKeyPack. The information contained in the
1020 trustedCertifiers in the request SHOULD be used by the KDC as
1021 hints to guide its selection of an appropriate certificate chain
1022 to return to the client. This field may only be left empty if
1023 the KDC public key specified by the kdcPkId field in the PA-PK-
1024 AS-REQ was used for signing. Otherwise, for path validation,
1025 these certificates SHOULD be sufficient to construct at least one
1026 certification path from the KDC certificate to one trust anchor
1027 acceptable by the client [CAPATH]. The KDC MUST be capable of
1028 including such a set of certificates if configured to do so. The
1029 certificates field MUST NOT contain "root" CA certificates.
1031 7. The recipientInfos field of the type EnvelopedData is a SET which
1032 MUST contain exactly one member of type KeyTransRecipientInfo.
1033 The encryptedKey of this member contains the temporary key which
1034 is encrypted using the client's public key.
1036 8. The unprotectedAttrs or originatorInfo fields of the type
1037 EnvelopedData MAY be present.
1039 Implementations of this RSA encryption key delivery method are
1040 RECOMMENDED to support for RSA keys at least 2048 bits in size.
1042 3.2.4 Receipt of KDC Reply
1044 Upon receipt of the KDC's reply, the client proceeds as follows. If
1045 the PA-PK-AS-REP contains the dhSignedData field, the client derives
1046 the AS reply key using the same procedure used by the KDC as defined
1047 in Section 3.2.3.1. Otherwise, the message contains the encKeyPack
1048 field, and the client decrypts and extracts the temporary key in the
1049 encryptedKey field of the member KeyTransRecipientInfo, and then uses
1050 that as the AS reply key.
1052 In either case, the client MUST verify the signature in the
1053 SignedData according to [RFC3852]. The KDC's X.509 certificate MUST
1054 be validated according to [RFC3280]. In addition, unless the client
1055 can otherwise verify that the public key used to verify the KDC's
1056 signature is bound to the KDC of the target realm, the KDC's X.509
1060 Tung & Zhu Expires January 20, 2006 [Page 19]
1061 \f
1062 Internet-Draft PKINIT July 2005
1065 certificate MUST contain a Subject Alternative Name extension
1066 [RFC3280] carrying an AnotherName whose type-id is id-pksan (as
1067 defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
1068 matches the name of the TGS of the target realm (as defined in
1069 Section 7.3 of [RFC4120]).
1071 Based on local policy, the client MAY require that the KDC
1072 certificate contains the EKU KeyPurposeId [RFC3280] id-pkkdcekuoid:
1074 id-pkkdcekuoid OBJECT IDENTIFIER ::=
1075 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
1076 pkinit(3) pkkdcekuoid(5) }
1077 -- Signing KDC responses.
1078 -- Key usage bits that MUST be consistent:
1079 -- digitalSignature.
1081 If all applicable checks are satisfied, the client then decrypts the
1082 enc-part field of the KDC-REP in the AS-REP using the AS reply key,
1083 and then proceeds as described in [RFC4120].
1085 Implementation note: CAs issuing KDC certificates SHOULD place all
1086 "short" and "fully-qualified" Kerberos realm names of the KDC (one
1087 per GeneralName [RFC3280]) into the KDC certificate to allow maximum
1088 flexibility.
1090 3.3 Interoperability Requirements
1092 The client MUST be capable of sending a set of certificates
1093 sufficient to allow the KDC to construct a certification path for the
1094 client's certificate, if the correct set of certificates is provided
1095 through configuration or policy.
1097 If the client sends all the X.509 certificates on a certification
1098 path to a trust anchor acceptable by the KDC, and the KDC can not
1099 verify the client's public key otherwise, the KDC MUST be able to
1100 process path validation for the client's certificate based on the
1101 certificates in the request.
1103 The KDC MUST be capable of sending a set of certificates sufficient
1104 to allow the client to construct a certification path for the KDC's
1105 certificate, if the correct set of certificates is provided through
1106 configuration or policy.
1108 If the KDC sends all the X.509 certificates on a certification path
1109 to a trust anchor acceptable by the client, and the client can not
1110 verify the KDC's public key otherwise, the client MUST be able to
1111 process path validation for the KDC's certificate based on the
1112 certificates in the reply.
1116 Tung & Zhu Expires January 20, 2006 [Page 20]
1117 \f
1118 Internet-Draft PKINIT July 2005
1121 3.4 KDC Indication of PKINIT Support
1123 If pre-authentication is required, but was not present in the
1124 request, per [RFC4120] an error message with the code
1125 KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
1126 stored in the e-data field of the KRB-ERROR message to specify which
1127 pre-authentication mechanisms are acceptable. The KDC can then
1128 indicate the support of PKINIT by including an empty element whose
1129 padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
1131 Otherwise if it is required by the KDC's local policy that the client
1132 must be pre-authenticated using the pre-authentication mechanism
1133 specified in this document, but no PKINIT pre-authentication was
1134 present in the request, an error message with the code
1135 KDC_ERR_PREAUTH_FAILED SHOULD be returned.
1137 KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
1138 the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
1139 STRING), and clients MUST ignore this and any other value. Future
1140 extensions to this protocol may specify other data to send instead of
1141 an empty OCTET STRING.
1143 4. Security Considerations
1145 The symmetric reply key size and Diffie-Hellman field size or RSA
1146 modulus size should be chosen so as to provide sufficient
1147 cryptographic security [RFC3766].
1149 When MODP Diffie-Hellman is used, the exponents should have at least
1150 twice as many bits as the symmetric keys that will be derived from
1151 them [ODL99].
1153 PKINIT raises certain security considerations beyond those that can
1154 be regulated strictly in protocol definitions. We will address them
1155 in this section.
1157 PKINIT extends the cross-realm model to the public-key
1158 infrastructure. Users of PKINIT must understand security policies
1159 and procedures appropriate to the use of Public Key Infrastructures
1160 [RFC3280].
1162 Standard Kerberos allows the possibility of interactions between
1163 cryptosystems of varying strengths; this document adds interactions
1164 with public-key cryptosystems to Kerberos. Some administrative
1165 policies may allow the use of relatively weak public keys. Using
1166 such keys to wrap data encrypted under stronger conventional
1167 cryptosystems may be inappropriate.
1172 Tung & Zhu Expires January 20, 2006 [Page 21]
1173 \f
1174 Internet-Draft PKINIT July 2005
1177 PKINIT requires keys for symmetric cryptosystems to be generated.
1178 Some such systems contain "weak" keys. For recommendations regarding
1179 these weak keys, see [RFC4120].
1181 PKINIT allows the use of the same RSA key pair for encryption and
1182 signing when doing RSA encryption based key delivery. This is not
1183 recommended usage of RSA keys [RFC3447], by using DH based key
1184 delivery this is avoided.
1186 Care should be taken in how certificates are chosen for the purposes
1187 of authentication using PKINIT. Some local policies may require that
1188 key escrow be used for certain certificate types. Deployers of
1189 PKINIT should be aware of the implications of using certificates that
1190 have escrowed keys for the purposes of authentication. Because
1191 signing only certificates are normally not escrowed, by using DH
1192 based key delivery this is avoided.
1194 PKINIT does not provide for a "return routability" test to prevent
1195 attackers from mounting a denial-of-service attack on the KDC by
1196 causing it to perform unnecessary and expensive public-key
1197 operations. Strictly speaking, this is also true of standard
1198 Kerberos, although the potential cost is not as great, because
1199 standard Kerberos does not make use of public-key cryptography. By
1200 using DH based key delivery and reusing DH keys, the necessary crypto
1201 processing cost per request can be minimized.
1203 The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
1204 permit empty SEQUENCEs to be encoded. Such empty sequences may only
1205 be used if the KDC itself vouches for the user's certificate.
1207 5. Acknowledgements
1209 The following people have made significant contributions to this
1210 draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist
1211 Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle,
1212 Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik
1213 Jaganathan, Chaskiel M Grundman and Stefan Santesson.
1215 Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and
1216 Jonathan Trostle who wrote earlier versions of this document.
1218 The authors are indebted to the Kerberos working group chair Jeffrey
1219 Hutzelman who kept track of various issues and was enormously helpful
1220 during the creation of this document.
1222 Some of the ideas on which this document is based arose during
1223 discussions over several years between members of the SAAG, the IETF
1224 CAT working group, and the PSRG, regarding integration of Kerberos
1228 Tung & Zhu Expires January 20, 2006 [Page 22]
1229 \f
1230 Internet-Draft PKINIT July 2005
1233 and SPX. Some ideas have also been drawn from the DASS system.
1234 These changes are by no means endorsed by these groups. This is an
1235 attempt to revive some of the goals of those groups, and this
1236 document approaches those goals primarily from the Kerberos
1237 perspective.
1239 Lastly, comments from groups working on similar ideas in DCE have
1240 been invaluable.
1242 6. IANA Considerations
1244 This document has no actions for IANA.
1246 7. References
1248 7.1 Normative References
1250 [IEEE1363]
1251 IEEE, "Standard Specifications for Public Key
1252 Cryptography", IEEE 1363, 2000.
1254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1255 Requirement Levels", BCP 14, RFC 2119, March 1997.
1257 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
1258 RFC 2412, November 1998.
1260 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
1261 RFC 2631, June 1999.
1263 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
1264 Identifiers for the Internet X.509 Public Key
1265 Infrastructure Certificate and Certificate Revocation List
1266 (CRL) Profile", RFC 3279, April 2002.
1268 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
1269 X.509 Public Key Infrastructure Certificate and
1270 Certificate Revocation List (CRL) Profile", RFC 3280,
1271 April 2002.
1273 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
1274 Algorithms", RFC 3370, August 2002.
1276 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
1277 Standards (PKCS) #1: RSA Cryptography Specifications
1278 Version 2.1", RFC 3447, February 2003.
1280 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
1284 Tung & Zhu Expires January 20, 2006 [Page 23]
1285 \f
1286 Internet-Draft PKINIT July 2005
1289 Diffie-Hellman groups for Internet Key Exchange (IKE)",
1290 RFC 3526, May 2003.
1292 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES)
1293 Encryption Algorithm in Cryptographic Message Syntax
1294 (CMS)", RFC 3565, July 2003.
1296 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
1297 Public Keys Used For Exchanging Symmetric Keys", BCP 86,
1298 RFC 3766, April 2004.
1300 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
1301 RFC 3852, July 2004.
1303 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
1304 Kerberos 5", RFC 3961, February 2005.
1306 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES)
1307 Encryption for Kerberos 5", RFC 3962, February 2005.
1309 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
1310 Kerberos Network Authentication Service (V5)", RFC 4120,
1311 July 2005.
1313 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
1314 Version 5 Generic Security Service Application Program
1315 Interface (GSS-API) Mechanism: Version 2", RFC 4121,
1316 July 2005.
1318 [X.509-97] ITU-T. Recommendation X.509: The Directory - Authentication
1319 Framework. 1997.
1321 [X690] ASN.1 encoding rules: Specification of Basic Encoding
1322 Rules (BER), Canonical Encoding Rules (CER) and
1323 Distinguished Encoding Rules (DER), ITU-T Recommendation
1324 X.690 (1997) | ISO/IEC International Standard
1325 8825-1:1998.
1327 7.2 Informative References
1329 [CAPATH] RFC-Editor: To be replaced by RFC number for draft-ietf-
1330 pkix-certpathbuild. Work in Progress.
1332 [LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
1333 Sizes", Journal of Cryptology 14 (2001) 255-293.
1336 Tung & Zhu Expires January 20, 2006 [Page 24]
1337 \f
1338 Internet-Draft PKINIT July 2005
1342 [ODL99] Odlyzko, A., "Discrete logarithms: The past and the
1343 future, Designs, Codes, and Cryptography (1999)".
1346 Authors' Addresses
1348 Brian Tung
1349 USC Information Sciences Institute
1350 4676 Admiralty Way Suite 1001, Marina del Rey CA
1351 Marina del Rey, CA 90292
1352 US
1354 Email: brian@isi.edu
1357 Larry Zhu
1358 Microsoft Corporation
1359 One Microsoft Way
1360 Redmond, WA 98052
1361 US
1363 Email: lzhu@microsoft.com
1365 Appendix A. PKINIT ASN.1 Module
1367 KerberosV5-PK-INIT-SPEC {
1368 iso(1) identified-organization(3) dod(6) internet(1)
1369 security(5) kerberosV5(2) modules(4) pkinit(5)
1370 } DEFINITIONS EXPLICIT TAGS ::= BEGIN
1372 IMPORTS
1373 SubjectPublicKeyInfo, AlgorithmIdentifier
1374 FROM PKIX1Explicit88 { iso (1)
1375 identified-organization (3) dod (6) internet (1)
1376 security (5) mechanisms (5) pkix (7) id-mod (0)
1377 id-pkix1-explicit (18) }
1378 -- As defined in RFC 3280.
1380 DomainParameters
1381 FROM PKIX1Algorithms88 { iso(1)
1382 identified-organization(3) dod(6)
1383 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
1384 id-mod-pkix1-algorithms(17) }
1385 -- As defined in RFC 3279.
1387 KerberosTime, TYPED-DATA, PrincipalName, Realm, EncryptionKey
1388 FROM KerberosV5Spec2 { iso(1) identified-organization(3)
1392 Tung & Zhu Expires January 20, 2006 [Page 25]
1393 \f
1394 Internet-Draft PKINIT July 2005
1397 dod(6) internet(1) security(5) kerberosV5(2)
1398 modules(4) krb5spec2(2) } ;
1400 id-pkinit OBJECT IDENTIFIER ::=
1401 { iso (1) org (3) dod (6) internet (1) security (5)
1402 kerberosv5 (2) pkinit (3) }
1404 id-pkauthdata OBJECT IDENTIFIER ::= { id-pkinit 1 }
1405 id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 }
1406 id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 }
1407 id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 }
1408 id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 }
1410 pa-pk-as-req INTEGER ::= 16
1411 pa-pk-as-rep INTEGER ::= 17
1413 ad-initial-verified-cas INTEGER ::= 9
1415 td-trusted-certifiers INTEGER ::= 104
1416 td-invalid-certificates INTEGER ::= 105
1417 td-dh-parameters INTEGER ::= 109
1419 PA-PK-AS-REQ ::= SEQUENCE {
1420 signedAuthPack [0] IMPLICIT OCTET STRING,
1421 -- Contains a CMS type ContentInfo encoded
1422 -- according to [RFC3852].
1423 -- The contentType field of the type ContentInfo
1424 -- is id-signedData (1.2.840.113549.1.7.2),
1425 -- and the content field is a SignedData.
1426 -- The eContentType field for the type SignedData is
1427 -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
1428 -- eContent field contains the DER encoding of the
1429 -- type AuthPack.
1430 -- AuthPack is defined below.
1431 trustedCertifiers [1] SEQUENCE OF
1432 ExternalPrincipalIdentifier OPTIONAL,
1433 -- A list of CAs, trusted by the client, that can
1434 -- be used to certify the KDC.
1435 -- Each ExternalPrincipalIdentifier identifies a CA
1436 -- or a CA certificate (thereby its public key).
1437 -- The information contained in the
1438 -- trustedCertifiers SHOULD be used by the KDC as
1439 -- hints to guide its selection of an appropriate
1440 -- certificate chain to return to the client.
1441 kdcPkId [2] IMPLICIT OCTET STRING
1442 OPTIONAL,
1443 -- Contains a CMS type SignerIdentifier encoded
1444 -- according to [RFC3852].
1448 Tung & Zhu Expires January 20, 2006 [Page 26]
1449 \f
1450 Internet-Draft PKINIT July 2005
1453 -- Identifies, if present, a particular KDC
1454 -- public key that the client already has.
1455 ...
1456 }
1458 DHNonce ::= OCTET STRING
1460 ExternalPrincipalIdentifier ::= SEQUENCE {
1461 subjectName [0] IMPLICIT OCTET STRING OPTIONAL,
1462 -- Contains a PKIX type Name encoded according to
1463 -- [RFC3280].
1464 -- Identifies the certificate subject by the
1465 -- distinguished subject name.
1466 -- REQUIRED when there is a distinguished subject
1467 -- name present in the certificate.
1468 issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL,
1469 -- Contains a CMS type IssuerAndSerialNumber encoded
1470 -- according to [RFC3852].
1471 -- Identifies a certificate of the subject.
1472 -- REQUIRED for TD-INVALID-CERTIFICATES and
1473 -- TD-TRUSTED-CERTIFIERS.
1474 subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL,
1475 -- Identifies the subject's public key by a key
1476 -- identifier. When an X.509 certificate is
1477 -- referenced, this key identifier matches the X.509
1478 -- subjectKeyIdentifier extension value. When other
1479 -- certificate formats are referenced, the documents
1480 -- that specify the certificate format and their use
1481 -- with the CMS must include details on matching the
1482 -- key identifier to the appropriate certificate
1483 -- field.
1484 -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
1485 ...
1486 }
1488 AuthPack ::= SEQUENCE {
1489 pkAuthenticator [0] PKAuthenticator,
1490 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
1491 -- Type SubjectPublicKeyInfo is defined in
1492 -- [RFC3280].
1493 -- Specifies Diffie-Hellman domain parameters
1494 -- and the client's public key value [IEEE1363].
1495 -- The DH public key value is encoded as a BIT
1496 -- STRING, as specified in Section 2.3.3 of
1497 -- [RFC3279].
1498 -- This field is present only if the client wishes
1499 -- to use the Diffie-Hellman key agreement method.
1500 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
1504 Tung & Zhu Expires January 20, 2006 [Page 27]
1505 \f
1506 Internet-Draft PKINIT July 2005
1509 OPTIONAL,
1510 -- Type AlgorithmIdentifier is defined in
1511 -- [RFC3280].
1512 -- List of CMS encryption types supported by the
1513 -- client in order of (decreasing) preference.
1514 clientDHNonce [3] DHNonce OPTIONAL,
1515 -- Present only if the client indicates that it
1516 -- wishes to reuse DH keys or to allow the KDC to
1517 -- do so.
1518 ...
1519 }
1521 PKAuthenticator ::= SEQUENCE {
1522 cusec [0] INTEGER (0..999999),
1523 ctime [1] KerberosTime,
1524 -- cusec and ctime are used as in [RFC4120], for
1525 -- replay prevention.
1526 nonce [2] INTEGER (0..4294967295),
1527 -- Chosen randomly; This nonce does not need to
1528 -- match with the nonce in the KDC-REQ-BODY.
1529 paChecksum [3] OCTET STRING,
1530 -- Contains the SHA1 checksum, performed over
1531 -- KDC-REQ-BODY.
1532 ...
1533 }
1535 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
1536 ExternalPrincipalIdentifier
1537 -- Identifies a list of CAs trusted by the KDC.
1538 -- Each ExternalPrincipalIdentifier identifies a CA
1539 -- or a CA certificate (thereby its public key).
1541 TD-INVALID-CERTIFICATES ::= SEQUENCE OF
1542 ExternalPrincipalIdentifier
1543 -- Each ExternalPrincipalIdentifier identifies a
1544 -- certificate (sent by the client) with an invalid
1545 -- signature.
1547 KRB5PrincipalName ::= SEQUENCE {
1548 realm [0] Realm,
1549 principalName [1] PrincipalName
1550 }
1552 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
1553 ExternalPrincipalIdentifier
1554 -- Identifies the certification path based on which
1555 -- the client certificate was validated.
1556 -- Each ExternalPrincipalIdentifier identifies a CA
1560 Tung & Zhu Expires January 20, 2006 [Page 28]
1561 \f
1562 Internet-Draft PKINIT July 2005
1565 -- or a CA certificate (thereby its public key).
1567 PA-PK-AS-REP ::= CHOICE {
1568 dhInfo [0] DHRepInfo,
1569 -- Selected when Diffie-Hellman key exchange is
1570 -- used.
1571 encKeyPack [1] IMPLICIT OCTET STRING,
1572 -- Selected when public key encryption is used.
1573 -- Contains a CMS type ContentInfo encoded
1574 -- according to [RFC3852].
1575 -- The contentType field of the type ContentInfo is
1576 -- id-envelopedData (1.2.840.113549.1.7.3).
1577 -- The content field is an EnvelopedData.
1578 -- The contentType field for the type EnvelopedData
1579 -- is id-signedData (1.2.840.113549.1.7.2).
1580 -- The eContentType field for the inner type
1581 -- SignedData (when unencrypted) is id-pkrkeydata
1582 -- (1.2.840.113549.1.7.3) and the eContent field
1583 -- contains the DER encoding of the type
1584 -- ReplyKeyPack.
1585 -- ReplyKeyPack is defined below.
1586 ...
1587 }
1589 DHRepInfo ::= SEQUENCE {
1590 dhSignedData [0] IMPLICIT OCTET STRING,
1591 -- Contains a CMS type ContentInfo encoded according
1592 -- to [RFC3852].
1593 -- The contentType field of the type ContentInfo is
1594 -- id-signedData (1.2.840.113549.1.7.2), and the
1595 -- content field is a SignedData.
1596 -- The eContentType field for the type SignedData is
1597 -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
1598 -- eContent field contains the DER encoding of the
1599 -- type KDCDHKeyInfo.
1600 -- KDCDHKeyInfo is defined below.
1601 serverDHNonce [1] DHNonce OPTIONAL
1602 -- Present if and only if dhKeyExpiration is
1603 -- present.
1604 }
1606 KDCDHKeyInfo ::= SEQUENCE {
1607 subjectPublicKey [0] BIT STRING,
1608 -- KDC's DH public key.
1609 -- The DH public key value is encoded as a BIT
1610 -- STRING, as specified in Section 2.3.3 of
1611 -- [RFC3279].
1612 nonce [1] INTEGER (0..4294967295),
1616 Tung & Zhu Expires January 20, 2006 [Page 29]
1617 \f
1618 Internet-Draft PKINIT July 2005
1621 -- Contains the nonce in the PKAuthenticator of the
1622 -- request if DH keys are NOT reused,
1623 -- 0 otherwise.
1624 dhKeyExpiration [2] KerberosTime OPTIONAL,
1625 -- Expiration time for KDC's key pair,
1626 -- present if and only if DH keys are reused. If
1627 -- this field is omitted then the serverDHNonce
1628 -- field MUST also be omitted.
1629 ...
1630 }
1632 ReplyKeyPack ::= SEQUENCE {
1633 replyKey [0] EncryptionKey,
1634 -- Contains the session key used to encrypt the
1635 -- enc-part field in the AS-REP.
1636 asChecksum [1] Checksum,
1637 -- Contains the checksum of the AS-REQ
1638 -- corresponding to the containing AS-REP.
1639 -- The checksum is performed over the type AS-REQ.
1640 -- The protocol key [RFC3961] of the checksum is the
1641 -- replyKey and the key usage number is 6.
1642 -- If the replyKey's enctype is "newer" [RFC4120]
1643 -- [RFC4121], the checksum is the required
1644 -- checksum operation [RFC3961] for that enctype.
1645 -- The client MUST verify this checksum upon receipt
1646 -- of the AS-REP.
1647 ...
1648 }
1650 TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
1651 -- Each AlgorithmIdentifier specifies a set of
1652 -- Diffie-Hellman domain parameters [IEEE1363].
1653 -- This list is in decreasing preference order.
1654 END
1672 Tung & Zhu Expires January 20, 2006 [Page 30]
1673 \f
1674 Internet-Draft PKINIT July 2005
1677 Intellectual Property Statement
1679 The IETF takes no position regarding the validity or scope of any
1680 Intellectual Property Rights or other rights that might be claimed to
1681 pertain to the implementation or use of the technology described in
1682 this document or the extent to which any license under such rights
1683 might or might not be available; nor does it represent that it has
1684 made any independent effort to identify any such rights. Information
1685 on the procedures with respect to rights in RFC documents can be
1686 found in BCP 78 and BCP 79.
1688 Copies of IPR disclosures made to the IETF Secretariat and any
1689 assurances of licenses to be made available, or the result of an
1690 attempt made to obtain a general license or permission for the use of
1691 such proprietary rights by implementers or users of this
1692 specification can be obtained from the IETF on-line IPR repository at
1693 http://www.ietf.org/ipr.
1695 The IETF invites any interested party to bring to its attention any
1696 copyrights, patents or patent applications, or other proprietary
1697 rights that may cover technology that may be required to implement
1698 this standard. Please address the information to the IETF at
1699 ietf-ipr@ietf.org.
1702 Disclaimer of Validity
1704 This document and the information contained herein are provided on an
1705 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1706 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1707 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1708 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1709 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1710 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1713 Copyright Statement
1715 Copyright (C) The Internet Society (2005). This document is subject
1716 to the rights, licenses and restrictions contained in BCP 78, and
1717 except as set forth therein, the authors retain all their rights.
1720 Acknowledgment
1722 Funding for the RFC Editor function is currently provided by the
1723 Internet Society.
1728 Tung & Zhu Expires January 20, 2006 [Page 31]
1729 \f