| blob | f0cd9cac4c3b8f06b3949f770bb834775980c4ba |
4 NETWORK WORKING GROUP B. Tung
5 Internet-Draft USC Information Sciences Institute
6 Expires: August 4, 2005 L. Zhu
7 Microsoft Corporation
8 January 31, 2005
11 Public Key Cryptography for Initial Authentication in Kerberos
12 draft-ietf-cat-kerberos-pk-init
14 Status of this Memo
16 This document is an Internet-Draft and is subject to all provisions
17 of Section 3 of RFC 3667. By submitting this Internet-Draft, each
18 author represents that any applicable patent or other IPR claims of
19 which he or she is aware have been or will be disclosed, and any of
20 which he or she become aware will be disclosed, in accordance with
21 RFC 3668.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF), its areas, and its working groups. Note that
25 other groups may also distribute working documents as
26 Internet-Drafts.
28 Internet-Drafts are draft documents valid for a maximum of six months
29 and may be updated, replaced, or obsoleted by other documents at any
30 time. It is inappropriate to use Internet-Drafts as reference
31 material or to cite them other than as "work in progress."
33 The list of current Internet-Drafts can be accessed at
34 http://www.ietf.org/ietf/1id-abstracts.txt.
36 The list of Internet-Draft Shadow Directories can be accessed at
37 http://www.ietf.org/shadow.html.
39 This Internet-Draft will expire on August 4, 2005.
41 Copyright Notice
43 Copyright (C) The Internet Society (2005).
45 Abstract
47 This document describes protocol extensions (hereafter called PKINIT)
48 to the Kerberos protocol specification. These extensions provide a
49 method for integrating public key cryptography into the initial
50 authentication exchange, by passing digital certificates and
51 associated authenticators in pre-authentication data fields.
55 Tung & Zhu Expires August 4, 2005 [Page 1]
56 \f
57 Internet-Draft PKINIT January 2005
60 Table of Contents
62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
63 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
64 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
65 3.1 Definitions, Requirements, and Constants . . . . . . . . . 4
66 3.1.1 Required Algorithms . . . . . . . . . . . . . . . . . 4
67 3.1.2 Defined Message and Encryption Types . . . . . . . . . 5
68 3.1.3 Algorithm Identifiers . . . . . . . . . . . . . . . . 6
69 3.2 PKINIT Pre-authentication Syntax and Use . . . . . . . . . 6
70 3.2.1 Generation of Client Request . . . . . . . . . . . . . 7
71 3.2.2 Receipt of Client Request . . . . . . . . . . . . . . 9
72 3.2.3 Generation of KDC Reply . . . . . . . . . . . . . . . 12
73 3.2.4 Receipt of KDC Reply . . . . . . . . . . . . . . . . . 17
74 3.3 KDC Indication of PKINIT Support . . . . . . . . . . . . . 18
75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
76 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
79 7.1 Normative References . . . . . . . . . . . . . . . . . . . 20
80 7.2 Informative References . . . . . . . . . . . . . . . . . . 21
81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
82 A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 21
83 Intellectual Property and Copyright Statements . . . . . . . . 27
111 Tung & Zhu Expires August 4, 2005 [Page 2]
112 \f
113 Internet-Draft PKINIT January 2005
116 1. Introduction
118 A client typically authenticates itself to a service in Kerberos
119 using three distinct though related exchanges. First, the client
120 requests a ticket-granting ticket (TGT) from the Kerberos
121 authentication server (AS). Then, it uses the TGT to request a
122 service ticket from the Kerberos ticket-granting server (TGS).
123 Usually, the AS and TGS are integrated in a single device known as a
124 Kerberos Key Distribution Center, or KDC. (In this document, we will
125 refer to both the AS and the TGS as the KDC.) Finally, the client
126 uses the service ticket to authenticate itself to the service.
128 The advantage afforded by the TGT is that the client exposes his
129 long-term secrets only once. The TGT and its associated session key
130 can then be used for any subsequent service ticket requests. One
131 result of this is that all further authentication is independent of
132 the method by which the initial authentication was performed.
133 Consequently, initial authentication provides a convenient place to
134 integrate public-key cryptography into Kerberos authentication.
136 As defined in [CLAR], Kerberos authentication exchanges use
137 symmetric-key cryptography, in part for performance. One
138 disadvantage of using symmetric-key cryptography is that the keys
139 must be shared, so that before a client can authenticate itself, he
140 must already be registered with the KDC.
142 Conversely, public-key cryptography (in conjunction with an
143 established Public Key Infrastructure) permits authentication without
144 prior registration with a KDC. Adding it to Kerberos allows the
145 widespread use of Kerberized applications by clients without
146 requiring them to register first with a KDC--a requirement that has
147 no inherent security benefit.
149 As noted above, a convenient and efficient place to introduce
150 public-key cryptography into Kerberos is in the initial
151 authentication exchange. This document describes the methods and
152 data formats for integrating public-key cryptography into Kerberos
153 initial authentication.
155 2. Conventions Used in This Document
157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
159 document are to be interpreted as described in [RFC2119].
167 Tung & Zhu Expires August 4, 2005 [Page 3]
168 \f
169 Internet-Draft PKINIT January 2005
172 3. Extensions
174 This section describes extensions to [CLAR] for supporting the use of
175 public-key cryptography in the initial request for a ticket.
177 Briefly, this document defines the following extensions to [CLAR]:
179 1. The client indicates the use of public-key authentication by
180 including a special preauthenticator in the initial request. This
181 preauthenticator contains the client's public-key data and a
182 signature.
184 2. The KDC tests the client's request against its authentication
185 policy and trusted Certification Authorities (CAs).
187 3. If the request passes the verification tests, the KDC replies as
188 usual, but the reply is encrypted using either:
190 a. a key generated through a Diffie-Hellman (DH) key exchange
191 [RFC2631] with the client, signed using the KDC's signature
192 key; or
194 b. a symmetric encryption key, signed using the KDC's signature
195 key and encrypted using the client's public key.
197 Any keying material required by the client to obtain the
198 encryption key for decrypting the KDC reply is returned in a
199 pre-authentication field accompanying the usual reply.
201 4. The client obtains the encryption key, decrypts the reply, and
202 then proceeds as usual.
204 Section 3.1 of this document enumerates the required algorithms and
205 necessary extension message types. Section 3.2 describes the
206 extension messages in greater detail.
208 3.1 Definitions, Requirements, and Constants
210 3.1.1 Required Algorithms
212 All PKINIT implementations MUST support the following algorithms:
214 o AS reply key: AES256-CTS-HMAC-SHA1-96 etype [KCRYPTO].
216 o Signature algorithm: sha-1WithRSAEncryption [RFC3279].
218 o KDC AS reply key delivery method: ephemeral-ephemeral
219 Diffie-Hellman exchange (Diffie-Hellman keys are not cached).
223 Tung & Zhu Expires August 4, 2005 [Page 4]
224 \f
227 3.1.2 Defined Message and Encryption Types
229 PKINIT makes use of the following new pre-authentication types:
231 PA-PK-AS-REQ 16
232 PA-PK-AS-REP 17
234 PKINIT also makes use of the following new authorization data type:
236 AD-INITIAL-VERIFIED-CAS 9
238 PKINIT introduces the following new error codes:
240 KDC_ERR_CLIENT_NOT_TRUSTED 62
241 KDC_ERR_KDC_NOT_TRUSTED 63
242 KDC_ERR_INVALID_SIG 64
243 KDC_ERR_KEY_SIZE 65
244 KDC_ERR_CERTIFICATE_MISMATCH 66
245 KDC_ERR_CANT_VERIFY_CERTIFICATE 70
246 KDC_ERR_INVALID_CERTIFICATE 71
247 KDC_ERR_REVOKED_CERTIFICATE 72
248 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
249 KDC_ERR_CLIENT_NAME_MISMATCH 75
251 PKINIT uses the following typed data types for errors:
253 TD-TRUSTED-CERTIFIERS 104
254 TD-CERTIFICATE-INDEX 105
255 TD-DH-PARAMETERS 109
257 PKINIT defines the following encryption types, for use in the AS-REQ
258 message (to indicate acceptance of the corresponding encryption
259 Object Identifiers (OIDs) in PKINIT):
261 dsaWithSHA1-CmsOID 9
262 md5WithRSAEncryption-CmsOID 10
263 sha1WithRSAEncryption-CmsOID 11
264 rc2CBC-EnvOID 12
265 rsaEncryption-EnvOID (PKCS1 v1.5) 13
266 rsaES-OAEP-EnvOID (PKCS1 v2.0) 14
267 des-ede3-cbc-EnvOID 15
269 The above encryption types are used by the client only within the
270 KDC-REQ-BODY to indicate which Cryptographic Message Syntax (CMS)
271 [RFC3852] algorithms it supports. Their use within Kerberos
272 EncryptedData structures is not specified by this document.
274 The ASN.1 module for all structures defined in this document (plus
275 IMPORT statements for all imported structures) are given in
279 Tung & Zhu Expires August 4, 2005 [Page 5]
280 \f
281 Internet-Draft PKINIT January 2005
284 Appendix A.
286 All structures defined in or imported into this document MUST be
287 encoded using Distinguished Encoding Rules (DER) [X690]. All data
288 structures wrapped in OCTET STRINGs must be encoded according to the
289 rules specified in corresponding specifications.
291 Interoperability note: Some implementations may not be able to decode
292 CMS objects encoded with BER but not DER; specifically, they may not
293 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 for Diffie-Hellman key
303 agreement [RFC3279]:
305 dhpublicnumber
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 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)
327 3.2 PKINIT Pre-authentication Syntax and Use
329 This section defines the syntax and use of the various
330 pre-authentication fields employed by PKINIT.
335 Tung & Zhu Expires August 4, 2005 [Page 6]
336 \f
337 Internet-Draft PKINIT January 2005
340 3.2.1 Generation of Client Request
342 The initial authentication request (AS-REQ) is sent as per [CLAR]; in
343 addition, a pre-authentication field contains data signed by the
344 client's private signature key, as follows:
346 PA-PK-AS-REQ ::= SEQUENCE {
347 signedAuthPack [0] IMPLICIT OCTET STRING,
348 -- Contains a CMS type ContentInfo encoded
349 -- according to [RFC3852].
350 -- The contentType field of the type ContentInfo
351 -- is id-signedData (1.2.840.113549.1.7.2),
352 -- and the content field is a SignedData.
353 -- The eContentType field for the type SignedData is
354 -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
355 -- eContent field contains the DER encoding of the
356 -- type AuthPack.
357 -- AuthPack is defined below.
358 trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,
359 -- A list of CAs, trusted by the client, that can
360 -- be used to validate KDC certificates.
361 kdcCert [2] IMPLICIT OCTET STRING
362 OPTIONAL,
363 -- Contains a CMS type IssuerAndSerialNumber encoded
364 -- according to [RFC3852].
365 -- Identifies a particular KDC certificate, if the
366 -- client already has it.
367 ...
368 }
370 DHNonce ::= OCTET STRING
372 TrustedCA ::= CHOICE {
373 caName [1] IMPLICIT OCTET STRING,
374 -- Contains a PKIX type Name encoded according to
375 -- [RFC3280].
376 issuerAndSerial [2] IMPLICIT OCTET STRING,
377 -- Contains a CMS type IssuerAndSerialNumber encoded
378 -- according to [RFC3852].
379 -- Identifies a specific CA certificate.
380 ...
381 }
383 AuthPack ::= SEQUENCE {
384 pkAuthenticator [0] PKAuthenticator,
385 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
386 -- Defined in [RFC3280].
387 -- Present only if the client wishes to use the
391 Tung & Zhu Expires August 4, 2005 [Page 7]
392 \f
393 Internet-Draft PKINIT January 2005
396 -- Diffie-Hellman key agreement method.
397 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
398 OPTIONAL,
399 -- List of CMS encryption types supported by
400 -- client in order of (decreasing) preference.
401 clientDHNonce [3] DHNonce OPTIONAL,
402 -- Present only if the client indicates that it
403 -- wishes to cache DH keys or to allow the KDC to
404 -- do so.
405 ...
406 }
408 PKAuthenticator ::= SEQUENCE {
409 cusec [0] INTEGER (0..999999),
410 ctime [1] KerberosTime,
411 -- cusec and ctime are used as in [CLAR], for replay
412 -- prevention.
413 nonce [2] INTEGER (0..4294967295),
414 -- Chosen randomly; This nonce does not need to
415 -- match with the nonce in the KDC-REQ-BODY.
416 paChecksum [3] OCTET STRING,
417 -- Contains the SHA1 checksum, performed over
418 -- KDC-REQ-BODY.
419 ...
420 }
422 The ContentInfo [RFC3852] structure for the signedAuthPack field is
423 filled out as follows:
425 1. The contentType field of the type ContentInfo is id-signedData
426 (as defined in [RFC3852]), and the content field is a SignedData
427 (as defined in [RFC3852]).
429 2. The eContentType field for the type SignedData is id-pkauthdata:
430 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
431 pkinit(3) pkauthdata(1) }.
433 3. The eContent field for the type SignedData contains the DER
434 encoding of the type AuthPack.
436 4. The signerInfos field of the type SignedData contains a single
437 signerInfo, which contains the signature over the type AuthPack.
439 5. The certificates field of the type SignedData contains the
440 client's certificate and additional certificates intended to
441 facilitate certification path construction, so that the KDC can
442 validate the client's certificate and verify the signature over
443 the type AuthPack. The certificates field MUST NOT contain
447 Tung & Zhu Expires August 4, 2005 [Page 8]
448 \f
449 Internet-Draft PKINIT January 2005
452 "root" CA certificates.
454 6. The client's Diffie-Hellman public value (clientPublicValue) is
455 included if and only if the client wishes to use the
456 Diffie-Hellman key agreement method. For the Diffie-Hellman key
457 agreement method, implementations MUST support Oakley 1024-bit
458 MODP well-known group 2 [RFC2412] and SHOULD support Oakley
459 2048-bit MODP well-known group 14 and Oakley 4096-bit MODP
460 well-known group 16 [RFC3526]. They MAY support Oakley 185-bit
461 EC2N group 4 [RFC2412]. The Diffie-Hellman group size should be
462 chosen so as to provide sufficient cryptographic security. The
463 exponents should have at least twice as many bits as the
464 symmetric keys that will be derived from them [ODL99].
466 7. The client may wish to cache DH keys or to allow the KDC to do
467 so. If so, then the client includes the clientDHNonce field.
468 This nonce string needs to be as long as the longest key length
469 of the symmetric key types that the client supports. This nonce
470 MUST be chosen randomly.
473 3.2.2 Receipt of Client Request
475 Upon receiving the client's request, the KDC validates it. This
476 section describes the steps that the KDC MUST (unless otherwise
477 noted) take in validating the request.
479 The KDC looks for the client's certificate in the signedAuthPack
480 (based on the signerInfo) and validate this certificate.
482 If the KDC cannot find a certification path to validate the client's
483 certificate, it sends back an error of type
484 KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for this
485 error is a TYPED-DATA (as defined in [CLAR]). For this error, the
486 data-type is TD-TRUSTED-CERTIFIERS, and the data-value is the DER
487 encoding of
489 TrustedCertifiers ::= SEQUENCE OF OCTET STRING
490 -- The OCTET STRING contains a PKIX type Name encoded
491 -- according to [RFC3280].
493 If, while processing the certification path, the KDC determines that
494 the signature on one of the certificates in the signedAuthPack is
495 invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE.
496 The accompanying e-data for this error is a TYPED-DATA, whose
497 data-type is TD-CERTIFICATE-INDEX, and whose data-value is the DER
498 encoding of the index into the CertificateSet field, ordered as sent
499 by the client:
503 Tung & Zhu Expires August 4, 2005 [Page 9]
504 \f
505 Internet-Draft PKINIT January 2005
508 CertificateIndex ::= OCTET STRING
509 -- Contains a CMS type IssuerAndSerialNumber encoded
510 -- according to [RFC3852].
511 -- IssuerAndSerialNumber of certificate with an
512 -- invalid signature.
514 If more than one certificate signature is invalid, the KDC MAY send
515 one TYPED-DATA per invalid signature.
517 The KDC SHOULD also check whether any certificates in the client's
518 certification path have been revoked. If any of them have been
519 revoked, the KDC MUST return an error of type
520 KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
521 revocation status but is unable to do so, it SHOULD return an error
522 of type KDC_ERR_REVOCATION_STATUS_UNKNOWN. The certificate or
523 certificates affected are identified exactly as for an error of type
524 KDC_ERR_INVALID_CERTIFICATE (see above).
526 In addition to validating the client's certificate, the KDC MUST also
527 check that this certificate properly maps to the client's principal
528 name as specified in the AS-REQ as follows:
530 1. If the KDC has its own mapping from the name in the client's
531 certificate to a Kerberos name, it uses that Kerberos name.
533 2. Otherwise, if the client's certificate contains a SubjectAltName
534 extension with a Kerberos name in the otherName field, it uses
535 that name.
537 The otherName field (of type AnotherName) in the SubjectAltName
538 extension MUST contain KRB5PrincipalName as defined below.
540 The type-id field of the type AnotherName is id-pksan:
542 id-pksan OBJECT IDENTIFIER ::=
543 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
544 x509-sanan (2) }
546 The value field of the type AnotherName is the DER encoding of the
547 following ASN.1 type:
549 KRB5PrincipalName ::= SEQUENCE {
550 realm [0] Realm,
551 principalName [1] PrincipalName
552 }
554 If the KDC does not have its own mapping and there is no Kerberos
555 name present in the client's certificate, or if the name in the
559 Tung & Zhu Expires August 4, 2005 [Page 10]
560 \f
561 Internet-Draft PKINIT January 2005
564 request does not match the name in the certificate (including the
565 realm name), the KDC MUST return error code
566 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for
567 this error.
569 Even if the client's certificate is validated and it is mapped to the
570 client's principal name, the KDC may decide not to accept the
571 client's certificate, depending on local policy.
573 The KDC MAY require the presence of an Extended Key Usage (EKU)
574 KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the
575 client's certificate:
577 id-pkekuoid OBJECT IDENTIFIER ::=
578 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
579 pkinit(3) pkekuoid(4) }
580 -- PKINIT client authentication.
581 -- Key usage bits that may be consistent: digitalSignature
582 -- nonRepudiation, and (keyEncipherment or keyAgreement).
584 As a matter of local policy, the KDC may decide to reject requests on
585 the basis of the absence or presence of specific EKU OIDs. KDCs
586 implementing this requirement SHOULD also accept the EKU KeyPurposeId
587 id-ms-sc-logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement,
588 as there are a large number of client certificates deployed for use
589 with PKINIT which have this EKU.
591 The KDC MUST return the error code KDC_ERR_CLIENT_NOT_TRUSTED if the
592 client's certificate is not accepted.
594 Once the client's certificate is accepted, the KDC can then verify
595 the client's signature over the type AuthPack according to [RFC3852].
596 If the signature fails to verify, the KDC MUST return error
597 KDC_ERR_INVALID_SIG. There is no accompanying e-data for this error.
599 The KDC MUST check the timestamp to ensure that the request is not a
600 replay, and that the time skew falls within acceptable limits. The
601 recommendations clock skew times in [CLAR] apply here. If the check
602 fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
603 KRB_AP_ERR_SKEW, respectively.
605 If the clientPublicValue is filled in, indicating that the client
606 wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
607 check to see if the key parameters satisfy its policy. If they do
608 not, it MUST return error code KDC_ERR_KEY_SIZE. The accompanying
609 e-data is a TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and
610 whose data-value is the DER encoding of the following:
615 Tung & Zhu Expires August 4, 2005 [Page 11]
616 \f
617 Internet-Draft PKINIT January 2005
620 TD-DH-PARAMETERS ::= SEQUENCE OF DomainParameters
621 -- Type DomainParameters is defined in [RFC3279].
622 -- Contains a list of Diffie-Hellman group
623 -- parameters in decreasing preference order.
625 TD-DH-PARAMETERS contains a list of Diffie-Hellman group parameters
626 that the KDC supports in decreasing preference order, from which the
627 client should pick one to retry the request.
629 The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the
630 client included a kdcCert field in the PA-PK-AS-REQ and the KDC does
631 not have the corresponding certificate.
633 The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client
634 did not include a kdcCert field, but did include a trustedCertifiers
635 field, and the KDC does not possesses a certificate issued by one of
636 the listed certifiers.
638 If there is a supportedCMSTypes field in the AuthPack, the KDC must
639 check to see if it supports any of the listed types. If it supports
640 more than one of the types, the KDC SHOULD use the one listed first.
641 If it does not support any of them, it MUST return an error of type
642 KRB5KDC_ERR_ETYPE_NOSUPP.
644 3.2.3 Generation of KDC Reply
646 Assuming that the client's request has been properly validated, the
647 KDC proceeds as per [CLAR], except as follows.
649 The KDC MUST set the initial flag and include an authorization data
650 of type AD-INITIAL-VERIFIED-CAS in the issued ticket. The value is
651 an OCTET STRING containing the DER encoding of InitialVerifiedCAs:
653 InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
654 ca [0] IMPLICIT OCTET STRING,
655 -- Contains a PKIX type Name encoded according to
656 -- [RFC3280].
657 validated [1] BOOLEAN,
658 ...
659 }
661 The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
662 containers if the list of CAs satisfies the KDC's realm's policy
663 (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
664 [CLAR]). Furthermore, any TGS must copy such authorization data from
665 tickets used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket,
666 including the AD-IF-RELEVANT container, if present.
671 Tung & Zhu Expires August 4, 2005 [Page 12]
672 \f
673 Internet-Draft PKINIT January 2005
676 Application servers that understand this authorization data type
677 SHOULD apply local policy to determine whether a given ticket bearing
678 such a type *not* contained within an AD-IF-RELEVANT container is
679 acceptable. (This corresponds to the AP server checking the
680 transited field when the TRANSITED-POLICY-CHECKED flag has not been
681 set [CLAR].) If such a data type is contained within an
682 AD-IF-RELEVANT container, AP servers MAY apply local policy to
683 determine whether the authorization data is acceptable.
685 The AS-REP is otherwise unchanged from [CLAR]. The KDC encrypts the
686 reply as usual, but not with the client's long-term key. Instead, it
687 encrypts it with either a shared key derived from a Diffie-Hellman
688 exchange, or a generated encryption key. The contents of the
689 PA-PK-AS-REP indicate which key delivery method is used:
691 PA-PK-AS-REP ::= CHOICE {
692 dhInfo [0] DHRepInfo,
693 encKeyPack [1] IMPLICIT OCTET STRING,
694 -- Contains a CMS type ContentInfo encoded
695 -- according to [RFC3852].
696 -- The contentType field of the type ContentInfo is
697 -- id-envelopedData (1.2.840.113549.1.7.3).
698 -- The content field is an EnvelopedData.
699 -- The contentType field for the type EnvelopedData
700 -- is id-signedData (1.2.840.113549.1.7.2).
701 -- The eContentType field for the inner type
702 -- SignedData (when unencrypted) is id-pkrkeydata
703 -- (1.2.840.113549.1.7.3) and the eContent field
704 -- contains the DER encoding of the type
705 -- ReplyKeyPack.
706 -- ReplyKeyPack is defined below.
707 ...
708 }
710 DHRepInfo ::= SEQUENCE {
711 dhSignedData [0] IMPLICIT OCTET STRING,
712 -- Contains a CMS type ContentInfo encoded according
713 -- to [RFC3852].
714 -- The contentType field of the type ContentInfo is
715 -- id-signedData (1.2.840.113549.1.7.2), and the
716 -- content field is a SignedData.
717 -- The eContentType field for the type SignedData is
718 -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
719 -- eContent field contains the DER encoding of the
720 -- type KDCDHKeyInfo.
721 -- KDCDHKeyInfo is defined below.
722 serverDHNonce [1] DHNonce OPTIONAL
723 -- Present if and only if dhKeyExpiration is
727 Tung & Zhu Expires August 4, 2005 [Page 13]
728 \f
729 Internet-Draft PKINIT January 2005
732 -- present.
733 }
735 KDCDHKeyInfo ::= SEQUENCE {
736 subjectPublicKey [0] BIT STRING,
737 -- KDC's public key, y = g^x mod p.
738 -- MUST be ASN.1 encoded as an INTEGER;
739 -- This encoding is then used as the contents
740 -- (i.e., the value) of this BIT STRING field.
741 nonce [1] INTEGER (0..4294967295),
742 -- Contains the nonce in the PKAuthenticator of the
743 -- request if cached DH keys are NOT used,
744 -- 0 otherwise.
745 dhKeyExpiration [2] KerberosTime OPTIONAL,
746 -- Expiration time for KDC's cached values, present
747 -- if and only if cached DH keys are used. If this
748 -- field is omitted then the serverDHNonce field
749 -- MUST also be omitted.
750 ...
751 }
754 3.2.3.1 Using Diffie-Hellman Key Exchange
756 In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
758 The ContentInfo [RFC3852] structure for the dhSignedData field is
759 filled in as follows:
761 1. The contentType field of the type ContentInfo is id-signedData
762 (as defined in [RFC3852]), and the content field is a SignedData
763 (as defined in [RFC3852]).
765 2. The eContentType field for the type SignedData is the OID value
766 for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
767 security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }.
769 3. The eContent field for the type SignedData contains the DER
770 encoding of the type KDCDHKeyInfo.
772 4. The signerInfos field of the type SignedData contains a single
773 signerInfo, which contains the signature over the type
774 KDCDHKeyInfo.
776 5. The certificates field of the type SignedData contains the KDC's
777 certificate and additional certificates intended to facilitate
778 certification path construction, so that the client can validate
779 the KDC's certificate and verify the KDC's signature over the
783 Tung & Zhu Expires August 4, 2005 [Page 14]
784 \f
785 Internet-Draft PKINIT January 2005
788 type KDCDHKeyInfo. This field may only be left empty if the
789 client did include a kdcCert field in the PA-PK-AS-REQ,
790 indicating that the client already has the KDC's certificate.
791 The certificates field MUST NOT contain "root" CA certificates.
793 6. If the client included the clientDHNonce field, then the KDC may
794 choose to reuse its DH keys. If the server reuses DH keys then
795 it MUST include an expiration time in the dhKeyExperiation field.
796 Past the point of the expiration time, the signature over the
797 type DHRepInfo is considered expired/invalid. When the server
798 reuses DH keys then it MUST include a serverDHNonce at least as
799 long as the length of keys for the symmetric encryption system
800 used to encrypt the AS reply. Note that including the
801 serverDHNonce changes how the client and server calculate the key
802 to use to encrypt the reply; see below for details. The KDC
803 SHOULD NOT reuse DH keys unless the clientDHNonce field is
804 present in the request.
806 The reply key for use to decrypt the KDC reply [CLAR] is derived as
807 follows:
809 1. Both the KDC and the client calculate the shared secret value
810 DHKey:
812 DHKey = g^(xb * xa) mod p
814 where xb and xa are the KDC's and client's private exponents,
815 respectively. DHKey, padded first with leading zeros as needed to
816 make it as long as the modulus p, is represented as a string of
817 octets in big-endian order (such that the size of DHKey in octets
818 is the size of the modulus p).
820 2. Let K be the key-generation seed length [KCRYPTO] of the reply
821 key whose enctype is selected according to [CLAR].
823 3. Define the function octetstring2key() as follows:
825 octetstring2key(x) == random-to-key(K-truncate(
826 SHA1(0x00 | x) |
827 SHA1(0x01 | x) |
828 SHA1(0x02 | x) |
829 ...
830 ))
832 where x is an octet string; | is the concatenation operator; 0x00,
833 0x01, 0x02, etc., are each represented as a single octet;
834 random-to-key() is an operation that generates a protocol key from
835 a bitstring of length K; and K-truncate truncates its input to the
839 Tung & Zhu Expires August 4, 2005 [Page 15]
840 \f
841 Internet-Draft PKINIT January 2005
844 first K bits. Both K and random-to-key() are defined in the
845 kcrypto profile [KCRYPTO] for the enctype of the reply key.
847 4. When cached DH keys are used, let n_c be the clientDHNonce, and
848 n_k be the serverDHNonce; otherwise, let both n_c and n_k be empty
849 octet strings.
851 5. The reply key k is:
853 k = octetstring2key(DHKey | n_c | n_k)
856 3.2.3.2 Using Public Key Encryption
858 In this case, the PA-PK-AS-REP contains a ContentInfo structure
859 wrapped in an OCTET STRING. The reply key for use to decrypt the KDC
860 reply [CLAR] is encrypted in the encKeyPack field, which contains
861 data of type ReplyKeyPack:
863 ReplyKeyPack ::= SEQUENCE {
864 replyKey [0] EncryptionKey,
865 -- Contains the session key used to encrypt the
866 -- enc-part field in the AS-REP.
867 nonce [1] INTEGER (0..4294967295),
868 -- Contains the nonce in the PKAuthenticator of the
869 -- request.
870 ...
871 }
873 The ContentInfo [RFC3852] structure for the encKeyPack field is
874 filled in as follows:
876 1. The contentType field of the type ContentInfo is id-envelopedData
877 (as defined in [RFC3852]), and the content field is an
878 EnvelopedData (as defined in [RFC3852]).
880 2. The contentType field for the type EnvelopedData is
881 id-signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
882 pkcs (1) pkcs7 (7) signedData (2) }.
884 3. The eContentType field for the inner type SignedData (when
885 decrypted from the encryptedContent field for the type
886 EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6)
887 internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }.
889 4. The eContent field for the inner type SignedData contains the DER
890 encoding of the type ReplyKeyPack.
895 Tung & Zhu Expires August 4, 2005 [Page 16]
896 \f
897 Internet-Draft PKINIT January 2005
900 5. The signerInfos field of the inner type SignedData contains a
901 single signerInfo, which contains the signature over the type
902 ReplyKeyPack.
904 6. The certificates field of the inner type SignedData contains the
905 KDC's certificate and additional certificates intended to
906 facilitate certification path construction, so that the client
907 can validate the KDC's certificate and verify the KDC's signature
908 over the type ReplyKeyPack. This field may only be left empty if
909 the client included a kdcCert field in the PA-PK-AS-REQ,
910 indicating that the client already has the KDC's certificate.
911 The certificates field MUST NOT contain "root" CA certificates.
913 7. The recipientInfos field of the type EnvelopedData is a SET which
914 MUST contain exactly one member of type KeyTransRecipientInfo.
915 The encryptedKey of this member contains the temporary key which
916 is encrypted using the client's public key.
918 8. The unprotectedAttrs or originatorInfo fields of the type
919 EnvelopedData MAY be present.
921 3.2.4 Receipt of KDC Reply
923 Upon receipt of the KDC's reply, the client proceeds as follows. If
924 the PA-PK-AS-REP contains the dhSignedData field, the client derives
925 the shared key using the same procedure used by the KDC as defined in
926 Section 3.2.3.1. Otherwise, the message contains an encKeyPack, and
927 the client decrypts and verifies the temporary encryption key.
929 In either case, the client MUST validate the KDC's certificate and
930 verify the signature in the SignedData according to [RFC3852].
931 Unless the client can otherwise prove that the KDC's certificate is
932 for the target KDC (i.e., the subject distinguished name in the KDC
933 certificate is bound to the hostname or IP address of the KDC
934 authenticating the client), it MUST do the following to verify the
935 responder's identity:
937 1. The client checks to see if the included certificate contains a
938 Subject Alternative Name extension [RFC3280] carrying a dNSName or
939 an iPAddress (if the KDC is specified by an IP address instead of
940 a name). If it does, it MUST check to see if that name value
941 matches that of the KDC it believes it is communicating with, with
942 matching rules specified in [RFC3280].
944 2. The client verifies that the KDC's certificate MUST contain the
945 EKU KeyPurposeId [RFC3280] id-pkkdcekuoid:
951 Tung & Zhu Expires August 4, 2005 [Page 17]
952 \f
953 Internet-Draft PKINIT January 2005
958 id-pkkdcekuoid OBJECT IDENTIFIER ::=
959 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
960 pkinit(3) pkkdcekuoid(5) }
961 -- Signing KDC responses.
962 -- Key usage bits that may be consistent:
963 -- digitalSignature.
965 If all applicable checks are satisfied, the client then decrypts the
966 enc-part of the KDC-REP in the AS_REP with the resulting key, and
967 then proceeds as described in [CLAR].
969 3.3 KDC Indication of PKINIT Support
971 If pre-authentication is required, but was not present in the
972 request, per [CLAR] an error message with the code
973 KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
974 stored in the e-data field of the KRB-ERROR message to specify which
975 pre-authentication mechanisms are acceptable. The KDC can then
976 indicate the support of PKINIT by including a PA-PK-AS-REQ element in
977 that METHOD-DATA object.
979 Otherwise if it is required by the KDC's local policy that the client
980 must be pre-authenticated using the pre-authentication mechanism
981 specified in this document, but no PKINIT pre-authentication was
982 present in the request, an error message with the code
983 KDC_ERR_PREAUTH_FAILED SHOULD be returned.
985 KDCs MUST leave the padata-value of PA-PK-AS-REQ entry in the
986 KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
987 STRING), and clients MUST ignore this and any other value. Future
988 extensions to this protocol may specify other data to send instead of
989 an empty OCTET STRING.
991 4. Security Considerations
993 PKINIT raises certain security considerations beyond those that can
994 be regulated strictly in protocol definitions. We will address them
995 in this section.
997 PKINIT extends the cross-realm model to the public-key
998 infrastructure. Users of PKINIT must understand security policies
999 and procedures appropriate to the use of Public Key Infrastructures.
1001 Standard Kerberos allows the possibility of interactions between
1002 cryptosystems of varying strengths; this document adds interactions
1003 with public-key cryptosystems to Kerberos. Some administrative
1007 Tung & Zhu Expires August 4, 2005 [Page 18]
1008 \f
1009 Internet-Draft PKINIT January 2005
1012 policies may allow the use of relatively weak public keys. Using
1013 such keys to wrap data encrypted under stronger conventional
1014 cryptosystems may be inappropriate.
1016 PKINIT requires keys for symmetric cryptosystems to be generated.
1017 Some such systems contain "weak" keys. For recommendations regarding
1018 these weak keys, see [CLAR].
1020 PKINIT uses the same RSA key pair for encryption and signing when
1021 doing RSA encryption based key delivery. This is not recommended
1022 usage of RSA keys [RFC3447], by using DH based key delivery this is
1023 avoided.
1025 Care should be taken in how certificates are chosen for the purposes
1026 of authentication using PKINIT. Some local policies may require that
1027 key escrow be used for certain certificate types. Deployers of
1028 PKINIT should be aware of the implications of using certificates that
1029 have escrowed keys for the purposes of authentication.
1031 PKINIT does not provide for a "return routability" test to prevent
1032 attackers from mounting a denial-of-service attack on the KDC by
1033 causing it to perform unnecessary and expensive public-key
1034 operations. Strictly speaking, this is also true of standard
1035 Kerberos, although the potential cost is not as great, because
1036 standard Kerberos does not make use of public-key cryptography.
1038 The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
1039 permit empty SEQUENCEs to be encoded. Such empty sequences may only
1040 be used if the KDC itself vouches for the user's certificate.
1042 5. Acknowledgements
1044 The following people have made significant contributions to this
1045 draft: Paul Leach, Phil Hallin, Kelvin Yiu, Sam Hartman, Love
1046 Hornquist Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan
1047 Trostle, Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon and
1048 Karthik Jaganathan.
1050 Special thanks to Clifford Neuman, Mat Hur and Sasha Medvinsky who
1051 wrote earlier versions of this document.
1053 The authors are indebt to the Kerberos working group chair Jeffrey
1054 Hutzelman who kept track of various issues and was enormously helpful
1055 during the creation of this document.
1057 Some of the ideas on which this document is based arose during
1058 discussions over several years between members of the SAAG, the IETF
1059 CAT working group, and the PSRG, regarding integration of Kerberos
1063 Tung & Zhu Expires August 4, 2005 [Page 19]
1064 \f
1065 Internet-Draft PKINIT January 2005
1068 and SPX. Some ideas have also been drawn from the DASS system.
1069 These changes are by no means endorsed by these groups. This is an
1070 attempt to revive some of the goals of those groups, and this
1071 document approaches those goals primarily from the Kerberos
1072 perspective.
1074 Lastly, comments from groups working on similar ideas in DCE have
1075 been invaluable.
1077 6. IANA Considerations
1079 This document has no actions for IANA.
1081 7. References
1083 7.1 Normative References
1085 [CLAR] RFC-Editor: To be replaced by RFC number for draft-ietf-
1086 krb-wg-kerberos-clarifications. Work in Progress.
1088 [KCRYPTO] RFC-Editor: To be replaced by RFC number for draft-ietf-
1089 krb-wg-crypto. Work in Progress.
1091 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1092 Requirement Levels", BCP 14, RFC 2119, March 1997.
1094 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
1095 RFC 2412, November 1998.
1097 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
1098 RFC 2631, June 1999.
1100 [RFC3279] Bassham, L., Polk, W. and R. Housley, "Algorithms and
1101 Identifiers for the Internet X.509 Public Key
1102 Infrastructure Certificate and Certificate Revocation List
1103 (CRL) Profile", RFC 3279, April 2002.
1105 [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
1106 X.509 Public Key Infrastructure Certificate and
1107 Certificate Revocation List (CRL) Profile", RFC 3280,
1108 April 2002.
1110 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
1111 Algorithms", RFC 3370, August 2002.
1113 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
1114 Standards (PKCS) #1: RSA Cryptography Specifications
1118 Tung & Zhu Expires August 4, 2005 [Page 20]
1119 \f
1120 Internet-Draft PKINIT January 2005
1123 Version 2.1", RFC 3447, February 2003.
1125 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
1126 Diffie-Hellman groups for Internet Key Exchange (IKE)",
1127 RFC 3526, May 2003.
1129 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES)
1130 Encryption Algorithm in Cryptographic Message Syntax
1131 (CMS)", RFC 3565, July 2003.
1133 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
1134 RFC 3852, July 2004.
1136 [X690] ASN.1 encoding rules: Specification of Basic Encoding
1137 Rules (BER), Canonical Encoding Rules (CER) and
1138 Distinguished Encoding Rules (DER), ITU-T Recommendation
1139 X.690 (1997) | ISO/IEC International Standard
1140 8825-1:1998.
1142 7.2 Informative References
1144 [ODL99] Odlyzko, A., "Discrete logarithms: The past and the
1145 future, Designs, Codes, and Cryptography (1999)".
1147 Authors' Addresses
1149 Brian Tung
1150 USC Information Sciences Institute
1151 4676 Admiralty Way Suite 1001, Marina del Rey CA
1152 Marina del Rey, CA 90292
1153 US
1155 Email: brian@isi.edu
1158 Larry Zhu
1159 Microsoft Corporation
1160 One Microsoft Way
1161 Redmond, WA 98052
1162 US
1164 Email: lzhu@microsoft.com
1166 Appendix A. PKINIT ASN.1 Module
1168 KerberosV5-PK-INIT-SPEC {
1169 iso(1) identified-organization(3) dod(6) internet(1)
1173 Tung & Zhu Expires August 4, 2005 [Page 21]
1174 \f
1175 Internet-Draft PKINIT January 2005
1178 security(5) kerberosV5(2) modules(4) pkinit(5)
1179 } DEFINITIONS EXPLICIT TAGS ::= BEGIN
1181 IMPORTS
1182 SubjectPublicKeyInfo, AlgorithmIdentifier
1183 FROM PKIX1Explicit88 { iso (1)
1184 identified-organization (3) dod (6) internet (1)
1185 security (5) mechanisms (5) pkix (7) id-mod (0)
1186 id-pkix1-explicit (18) }
1187 -- As defined in RFC 3280.
1189 DomainParameters
1190 FROM PKIX1Algorithms88 { iso(1)
1191 identified-organization(3) dod(6)
1192 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
1193 id-mod-pkix1-algorithms(17) }
1194 -- As defined in RFC 3279.
1196 KerberosTime, TYPED-DATA, PrincipalName, Realm, EncryptionKey
1197 FROM KerberosV5Spec2 { iso(1) identified-organization(3)
1198 dod(6) internet(1) security(5) kerberosV5(2)
1199 modules(4) krb5spec2(2) } ;
1201 id-pkinit OBJECT IDENTIFIER ::=
1202 { iso (1) org (3) dod (6) internet (1) security (5)
1203 kerberosv5 (2) pkinit (3) }
1205 id-pkauthdata OBJECT IDENTIFIER ::= { id-pkinit 1 }
1206 id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 }
1207 id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 }
1208 id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 }
1209 id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 }
1211 pa-pk-as-req INTEGER ::= 16
1212 pa-pk-as-rep INTEGER ::= 17
1214 ad-initial-verified-cas INTEGER ::= 9
1216 td-trusted-certifiers INTEGER ::= 104
1217 td-certificate-index INTEGER ::= 105
1218 td-dh-parameters INTEGER ::= 109
1220 PA-PK-AS-REQ ::= SEQUENCE {
1221 signedAuthPack [0] IMPLICIT OCTET STRING,
1222 -- Contains a CMS type ContentInfo encoded
1223 -- according to [RFC3852].
1224 -- The contentType field of the type ContentInfo
1225 -- is id-signedData (1.2.840.113549.1.7.2),
1229 Tung & Zhu Expires August 4, 2005 [Page 22]
1230 \f
1231 Internet-Draft PKINIT January 2005
1234 -- and the content field is a SignedData.
1235 -- The eContentType field for the type SignedData is
1236 -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
1237 -- eContent field contains the DER encoding of the
1238 -- type AuthPack.
1239 -- AuthPack is defined below.
1240 trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,
1241 -- A list of CAs, trusted by the client, that can
1242 -- be used to validate KDC certificates.
1243 kdcCert [2] IMPLICIT OCTET STRING
1244 OPTIONAL,
1245 -- Contains a CMS type IssuerAndSerialNumber encoded
1246 -- according to [RFC3852].
1247 -- Identifies a particular KDC certificate, if the
1248 -- client already has it.
1249 ...
1250 }
1252 DHNonce ::= OCTET STRING
1254 TrustedCA ::= CHOICE {
1255 caName [1] IMPLICIT OCTET STRING,
1256 -- Contains a PKIX type Name encoded according to
1257 -- [RFC3280].
1258 issuerAndSerial [2] IMPLICIT OCTET STRING,
1259 -- Contains a CMS type IssuerAndSerialNumber encoded
1260 -- according to [RFC3852].
1261 -- Identifies a specific CA certificate.
1262 ...
1263 }
1265 AuthPack ::= SEQUENCE {
1266 pkAuthenticator [0] PKAuthenticator,
1267 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
1268 -- Defined in [RFC3280].
1269 -- Present only if the client wishes to use the
1270 -- Diffie-Hellman key agreement method.
1271 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
1272 OPTIONAL,
1273 -- List of CMS encryption types supported by
1274 -- client in order of (decreasing) preference.
1275 clientDHNonce [3] DHNonce OPTIONAL,
1276 -- Present only if the client indicates that it
1277 -- wishes to cache DH keys or to allow the KDC to
1278 -- do so.
1279 ...
1280 }
1285 Tung & Zhu Expires August 4, 2005 [Page 23]
1286 \f
1287 Internet-Draft PKINIT January 2005
1290 PKAuthenticator ::= SEQUENCE {
1291 cusec [0] INTEGER (0..999999),
1292 ctime [1] KerberosTime,
1293 -- cusec and ctime are used as in [CLAR], for replay
1294 -- prevention.
1295 nonce [2] INTEGER (0..4294967295),
1296 -- Chosen randomly; This nonce does not need to
1297 -- match with the nonce in the KDC-REQ-BODY.
1298 paChecksum [3] OCTET STRING,
1299 -- Contains the SHA1 checksum, performed over
1300 -- KDC-REQ-BODY.
1301 ...
1302 }
1304 TrustedCertifiers ::= SEQUENCE OF OCTET STRING
1305 -- The OCTET STRING contains a PKIX type Name encoded
1306 -- according to [RFC3280].
1308 CertificateIndex ::= OCTET STRING
1309 -- Contains a CMS type IssuerAndSerialNumber encoded
1310 -- according to [RFC3852].
1312 KRB5PrincipalName ::= SEQUENCE {
1313 realm [0] Realm,
1314 principalName [1] PrincipalName
1315 }
1317 InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
1318 ca [0] IMPLICIT OCTET STRING,
1319 -- Contains a PKIX type Name encoded according to
1320 -- [RFC3280].
1321 validated [1] BOOLEAN,
1322 ...
1323 }
1325 PA-PK-AS-REP ::= CHOICE {
1326 dhInfo [0] DHRepInfo,
1327 encKeyPack [1] IMPLICIT OCTET STRING,
1328 -- Contains a CMS type ContentInfo encoded
1329 -- according to [RFC3852].
1330 -- The contentType field of the type ContentInfo is
1331 -- id-envelopedData (1.2.840.113549.1.7.3).
1332 -- The content field is an EnvelopedData.
1333 -- The contentType field for the type EnvelopedData
1334 -- is id-signedData (1.2.840.113549.1.7.2).
1335 -- The eContentType field for the inner type
1336 -- SignedData (when unencrypted) is id-pkrkeydata
1337 -- (1.2.840.113549.1.7.3) and the eContent field
1341 Tung & Zhu Expires August 4, 2005 [Page 24]
1342 \f
1343 Internet-Draft PKINIT January 2005
1346 -- contains the DER encoding of the type
1347 -- ReplyKeyPack.
1348 -- ReplyKeyPack is defined below.
1349 ...
1350 }
1352 DHRepInfo ::= SEQUENCE {
1353 dhSignedData [0] IMPLICIT OCTET STRING,
1354 -- Contains a CMS type ContentInfo encoded according
1355 -- to [RFC3852].
1356 -- The contentType field of the type ContentInfo is
1357 -- id-signedData (1.2.840.113549.1.7.2), and the
1358 -- content field is a SignedData.
1359 -- The eContentType field for the type SignedData is
1360 -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
1361 -- eContent field contains the DER encoding of the
1362 -- type KDCDHKeyInfo.
1363 -- KDCDHKeyInfo is defined below.
1364 serverDHNonce [1] DHNonce OPTIONAL
1365 -- Present if and only if dhKeyExpiration is
1366 -- present.
1367 }
1369 KDCDHKeyInfo ::= SEQUENCE {
1370 subjectPublicKey [0] BIT STRING,
1371 -- KDC's public key, y = g^x mod p.
1372 -- MUST be ASN.1 encoded as an INTEGER;
1373 -- This encoding is then used as the contents
1374 -- (i.e., the value) of this BIT STRING field.
1375 nonce [1] INTEGER (0..4294967295),
1376 -- Contains the nonce in the PKAuthenticator of the
1377 -- request if cached DH keys are NOT used,
1378 -- 0 otherwise.
1379 dhKeyExpiration [2] KerberosTime OPTIONAL,
1380 -- Expiration time for KDC's cached values, present
1381 -- if and only if cached DH keys are used. If this
1382 -- field is omitted then the serverDHNonce field
1383 -- MUST also be omitted.
1384 ...
1385 }
1387 ReplyKeyPack ::= SEQUENCE {
1388 replyKey [0] EncryptionKey,
1389 -- Contains the session key used to encrypt the
1390 -- enc-part field in the AS-REP.
1391 nonce [1] INTEGER (0..4294967295),
1392 -- Contains the nonce in the PKAuthenticator of the
1393 -- request.
1397 Tung & Zhu Expires August 4, 2005 [Page 25]
1398 \f
1399 Internet-Draft PKINIT January 2005
1402 ...
1403 }
1405 TD-DH-PARAMETERS ::= SEQUENCE OF DomainParameters
1406 -- Contains a list of Diffie-Hellman group
1407 -- parameters in decreasing preference order.
1408 END
1453 Tung & Zhu Expires August 4, 2005 [Page 26]
1454 \f
1455 Internet-Draft PKINIT January 2005
1458 Intellectual Property Statement
1460 The IETF takes no position regarding the validity or scope of any
1461 Intellectual Property Rights or other rights that might be claimed to
1462 pertain to the implementation or use of the technology described in
1463 this document or the extent to which any license under such rights
1464 might or might not be available; nor does it represent that it has
1465 made any independent effort to identify any such rights. Information
1466 on the procedures with respect to rights in RFC documents can be
1467 found in BCP 78 and BCP 79.
1469 Copies of IPR disclosures made to the IETF Secretariat and any
1470 assurances of licenses to be made available, or the result of an
1471 attempt made to obtain a general license or permission for the use of
1472 such proprietary rights by implementers or users of this
1473 specification can be obtained from the IETF on-line IPR repository at
1474 http://www.ietf.org/ipr.
1476 The IETF invites any interested party to bring to its attention any
1477 copyrights, patents or patent applications, or other proprietary
1478 rights that may cover technology that may be required to implement
1479 this standard. Please address the information to the IETF at
1480 ietf-ipr@ietf.org.
1483 Disclaimer of Validity
1485 This document and the information contained herein are provided on an
1486 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1487 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1488 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1489 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1490 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1491 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1494 Copyright Statement
1496 Copyright (C) The Internet Society (2005). This document is subject
1497 to the rights, licenses and restrictions contained in BCP 78, and
1498 except as set forth therein, the authors retain all their rights.
1501 Acknowledgment
1503 Funding for the RFC Editor function is currently provided by the
1504 Internet Society.
1509 Tung & Zhu Expires August 4, 2005 [Page 27]
1510 \f