| blob | e7928ae0c0f5ba81ba11d5e8d79707940b83cc1e |
3 NETWORK WORKING GROUP B. Tung
4 Internet-Draft USC Information Sciences Institute
5 Expires: August 4, 2005 L. Zhu
6 Microsoft Corporation
7 January 31, 2005
10 Public Key Cryptography for Initial Authentication in Kerberos
11 draft-ietf-cat-kerberos-pk-init-23
13 Status of this Memo
15 This document is an Internet-Draft and is subject to all provisions
16 of Section 3 of RFC 3667. By submitting this Internet-Draft, each
17 author represents that any applicable patent or other IPR claims of
18 which he or she is aware have been or will be disclosed, and any of
19 which he or she become aware will be disclosed, in accordance with
20 RFC 3668.
22 Internet-Drafts are working documents of the Internet Engineering
23 Task Force (IETF), its areas, and its working groups. Note that
24 other groups may also distribute working documents as
25 Internet-Drafts.
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet-Drafts as reference
30 material or to cite them other than as "work in progress."
32 The list of current Internet-Drafts can be accessed at
33 http://www.ietf.org/ietf/1id-abstracts.txt.
35 The list of Internet-Draft Shadow Directories can be accessed at
36 http://www.ietf.org/shadow.html.
38 This Internet-Draft will expire on August 4, 2005.
40 Copyright Notice
42 Copyright (C) The Internet Society (2005).
44 Abstract
46 This document describes protocol extensions (hereafter called PKINIT)
47 to the Kerberos protocol specification. These extensions provide a
48 method for integrating public key cryptography into the initial
49 authentication exchange, by passing digital certificates and
50 associated authenticators in pre-authentication data fields.
54 Tung & Zhu Expires August 4, 2005 [Page 1]
55 \f
56 Internet-Draft PKINIT January 2005
59 Table of Contents
61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
62 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
63 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
64 3.1 Definitions, Requirements, and Constants . . . . . . . . . 4
65 3.1.1 Required Algorithms . . . . . . . . . . . . . . . . . 4
66 3.1.2 Defined Message and Encryption Types . . . . . . . . . 5
67 3.1.3 Algorithm Identifiers . . . . . . . . . . . . . . . . 6
68 3.2 PKINIT Pre-authentication Syntax and Use . . . . . . . . . 6
69 3.2.1 Generation of Client Request . . . . . . . . . . . . . 7
70 3.2.2 Receipt of Client Request . . . . . . . . . . . . . . 9
71 3.2.3 Generation of KDC Reply . . . . . . . . . . . . . . . 12
72 3.2.4 Receipt of KDC Reply . . . . . . . . . . . . . . . . . 17
73 3.3 KDC Indication of PKINIT Support . . . . . . . . . . . . . 18
74 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
75 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
78 7.1 Normative References . . . . . . . . . . . . . . . . . . . 20
79 7.2 Informative References . . . . . . . . . . . . . . . . . . 21
80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
81 A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 21
82 Intellectual Property and Copyright Statements . . . . . . . . 27
110 Tung & Zhu Expires August 4, 2005 [Page 2]
111 \f
112 Internet-Draft PKINIT January 2005
115 1. Introduction
117 A client typically authenticates itself to a service in Kerberos
118 using three distinct though related exchanges. First, the client
119 requests a ticket-granting ticket (TGT) from the Kerberos
120 authentication server (AS). Then, it uses the TGT to request a
121 service ticket from the Kerberos ticket-granting server (TGS).
122 Usually, the AS and TGS are integrated in a single device known as a
123 Kerberos Key Distribution Center, or KDC. (In this document, we will
124 refer to both the AS and the TGS as the KDC.) Finally, the client
125 uses the service ticket to authenticate itself to the service.
127 The advantage afforded by the TGT is that the client exposes his
128 long-term secrets only once. The TGT and its associated session key
129 can then be used for any subsequent service ticket requests. One
130 result of this is that all further authentication is independent of
131 the method by which the initial authentication was performed.
132 Consequently, initial authentication provides a convenient place to
133 integrate public-key cryptography into Kerberos authentication.
135 As defined in [CLAR], Kerberos authentication exchanges use
136 symmetric-key cryptography, in part for performance. One
137 disadvantage of using symmetric-key cryptography is that the keys
138 must be shared, so that before a client can authenticate itself, he
139 must already be registered with the KDC.
141 Conversely, public-key cryptography (in conjunction with an
142 established Public Key Infrastructure) permits authentication without
143 prior registration with a KDC. Adding it to Kerberos allows the
144 widespread use of Kerberized applications by clients without
145 requiring them to register first with a KDC--a requirement that has
146 no inherent security benefit.
148 As noted above, a convenient and efficient place to introduce
149 public-key cryptography into Kerberos is in the initial
150 authentication exchange. This document describes the methods and
151 data formats for integrating public-key cryptography into Kerberos
152 initial authentication.
154 2. Conventions Used in This Document
156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
158 document are to be interpreted as described in [RFC2119].
166 Tung & Zhu Expires August 4, 2005 [Page 3]
167 \f
168 Internet-Draft PKINIT January 2005
171 3. Extensions
173 This section describes extensions to [CLAR] for supporting the use of
174 public-key cryptography in the initial request for a ticket.
176 Briefly, this document defines the following extensions to [CLAR]:
178 1. The client indicates the use of public-key authentication by
179 including a special preauthenticator in the initial request. This
180 preauthenticator contains the client's public-key data and a
181 signature.
183 2. The KDC tests the client's request against its authentication
184 policy and trusted Certification Authorities (CAs).
186 3. If the request passes the verification tests, the KDC replies as
187 usual, but the reply is encrypted using either:
189 a. a key generated through a Diffie-Hellman (DH) key exchange
190 [RFC2631] with the client, signed using the KDC's signature
191 key; or
193 b. a symmetric encryption key, signed using the KDC's signature
194 key and encrypted using the client's public key.
196 Any keying material required by the client to obtain the
197 encryption key for decrypting the KDC reply is returned in a
198 pre-authentication field accompanying the usual reply.
200 4. The client obtains the encryption key, decrypts the reply, and
201 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: AES256-CTS-HMAC-SHA1-96 etype [KCRYPTO].
215 o Signature algorithm: sha-1WithRSAEncryption [RFC3279].
217 o KDC AS reply key delivery method: ephemeral-ephemeral
218 Diffie-Hellman exchange (Diffie-Hellman keys are not cached).
222 Tung & Zhu Expires August 4, 2005 [Page 4]
223 \f
226 3.1.2 Defined Message and Encryption Types
228 PKINIT makes use of the following new pre-authentication types:
230 PA-PK-AS-REQ 16
231 PA-PK-AS-REP 17
233 PKINIT also makes use of the following new authorization data type:
235 AD-INITIAL-VERIFIED-CAS 9
237 PKINIT introduces the following new error codes:
239 KDC_ERR_CLIENT_NOT_TRUSTED 62
240 KDC_ERR_KDC_NOT_TRUSTED 63
241 KDC_ERR_INVALID_SIG 64
242 KDC_ERR_KEY_SIZE 65
243 KDC_ERR_CERTIFICATE_MISMATCH 66
244 KDC_ERR_CANT_VERIFY_CERTIFICATE 70
245 KDC_ERR_INVALID_CERTIFICATE 71
246 KDC_ERR_REVOKED_CERTIFICATE 72
247 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
248 KDC_ERR_CLIENT_NAME_MISMATCH 75
250 PKINIT uses the following typed data types for errors:
252 TD-TRUSTED-CERTIFIERS 104
253 TD-CERTIFICATE-INDEX 105
254 TD-DH-PARAMETERS 109
256 PKINIT defines the following encryption types, for use in the AS-REQ
257 message (to indicate acceptance of the corresponding encryption
258 Object Identifiers (OIDs) in PKINIT):
260 dsaWithSHA1-CmsOID 9
261 md5WithRSAEncryption-CmsOID 10
262 sha1WithRSAEncryption-CmsOID 11
263 rc2CBC-EnvOID 12
264 rsaEncryption-EnvOID (PKCS1 v1.5) 13
265 rsaES-OAEP-EnvOID (PKCS1 v2.0) 14
266 des-ede3-cbc-EnvOID 15
268 The above encryption types are used by the client only within the
269 KDC-REQ-BODY to indicate which Cryptographic Message Syntax (CMS)
270 [RFC3852] algorithms it supports. Their use within Kerberos
271 EncryptedData structures is not specified by this document.
273 The ASN.1 module for all structures defined in this document (plus
274 IMPORT statements for all imported structures) are given in
278 Tung & Zhu Expires August 4, 2005 [Page 5]
279 \f
280 Internet-Draft PKINIT January 2005
283 Appendix A.
285 All structures defined in or imported into this document MUST be
286 encoded using Distinguished Encoding Rules (DER) [X690]. All data
287 structures wrapped in OCTET STRINGs must be encoded according to the
288 rules specified in corresponding specifications.
290 Interoperability note: Some implementations may not be able to decode
291 CMS objects encoded with BER but not DER; specifically, they may not
292 be able to decode infinite length encodings. To maximize
293 interoperability, implementers SHOULD encode CMS objects used in
294 PKINIT with DER.
296 3.1.3 Algorithm Identifiers
298 PKINIT does not define, but does make use of, the following algorithm
299 identifiers.
301 PKINIT uses the following algorithm identifier for Diffie-Hellman key
302 agreement [RFC3279]:
304 dhpublicnumber
306 PKINIT uses the following signature algorithm identifiers [RFC3279]:
308 sha-1WithRSAEncryption (RSA with SHA1)
309 md5WithRSAEncryption (RSA with MD5)
310 id-dsa-with-sha1 (DSA with SHA1)
312 PKINIT uses the following encryption algorithm identifiers [RFC3447]
313 for encrypting the temporary key with a public key:
315 rsaEncryption (PKCS1 v1.5)
316 id-RSAES-OAEP (PKCS1 v2.0)
318 PKINIT uses the following algorithm identifiers [RFC3370][RFC3565]
319 for encrypting the reply key with the temporary key:
321 des-ede3-cbc (three-key 3DES, CBC mode)
322 rc2-cbc (RC2, CBC mode)
323 id-aes256-CBC (AES-256, CBC mode)
326 3.2 PKINIT Pre-authentication Syntax and Use
328 This section defines the syntax and use of the various
329 pre-authentication fields employed by PKINIT.
334 Tung & Zhu Expires August 4, 2005 [Page 6]
335 \f
336 Internet-Draft PKINIT January 2005
339 3.2.1 Generation of Client Request
341 The initial authentication request (AS-REQ) is sent as per [CLAR]; in
342 addition, a pre-authentication field contains data signed by the
343 client's private signature key, as follows:
345 PA-PK-AS-REQ ::= SEQUENCE {
346 signedAuthPack [0] IMPLICIT OCTET STRING,
347 -- Contains a CMS type ContentInfo encoded
348 -- according to [RFC3852].
349 -- The contentType field of the type ContentInfo
350 -- is id-signedData (1.2.840.113549.1.7.2),
351 -- and the content field is a SignedData.
352 -- The eContentType field for the type SignedData is
353 -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
354 -- eContent field contains the DER encoding of the
355 -- type AuthPack.
356 -- AuthPack is defined below.
357 trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,
358 -- A list of CAs, trusted by the client, that can
359 -- be used to validate KDC certificates.
360 kdcCert [2] IMPLICIT OCTET STRING
361 OPTIONAL,
362 -- Contains a CMS type IssuerAndSerialNumber encoded
363 -- according to [RFC3852].
364 -- Identifies a particular KDC certificate, if the
365 -- client already has it.
366 ...
367 }
369 DHNonce ::= OCTET STRING
371 TrustedCA ::= CHOICE {
372 caName [1] IMPLICIT OCTET STRING,
373 -- Contains a PKIX type Name encoded according to
374 -- [RFC3280].
375 issuerAndSerial [2] IMPLICIT OCTET STRING,
376 -- Contains a CMS type IssuerAndSerialNumber encoded
377 -- according to [RFC3852].
378 -- Identifies a specific CA certificate.
379 ...
380 }
382 AuthPack ::= SEQUENCE {
383 pkAuthenticator [0] PKAuthenticator,
384 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
385 -- Defined in [RFC3280].
386 -- Present only if the client wishes to use the
390 Tung & Zhu Expires August 4, 2005 [Page 7]
391 \f
392 Internet-Draft PKINIT January 2005
395 -- Diffie-Hellman key agreement method.
396 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
397 OPTIONAL,
398 -- List of CMS encryption types supported by
399 -- client in order of (decreasing) preference.
400 clientDHNonce [3] DHNonce OPTIONAL,
401 -- Present only if the client indicates that it
402 -- wishes to cache DH keys or to allow the KDC to
403 -- do so.
404 ...
405 }
407 PKAuthenticator ::= SEQUENCE {
408 cusec [0] INTEGER (0..999999),
409 ctime [1] KerberosTime,
410 -- cusec and ctime are used as in [CLAR], for replay
411 -- prevention.
412 nonce [2] INTEGER (0..4294967295),
413 -- Chosen randomly; This nonce does not need to
414 -- match with the nonce in the KDC-REQ-BODY.
415 paChecksum [3] OCTET STRING,
416 -- Contains the SHA1 checksum, performed over
417 -- KDC-REQ-BODY.
418 ...
419 }
421 The ContentInfo [RFC3852] structure for the signedAuthPack field is
422 filled out as follows:
424 1. The contentType field of the type ContentInfo is id-signedData
425 (as defined in [RFC3852]), and the content field is a SignedData
426 (as defined in [RFC3852]).
428 2. The eContentType field for the type SignedData is id-pkauthdata:
429 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
430 pkinit(3) pkauthdata(1) }.
432 3. The eContent field for the type SignedData contains the DER
433 encoding of the type AuthPack.
435 4. The signerInfos field of the type SignedData contains a single
436 signerInfo, which contains the signature over the type AuthPack.
438 5. The certificates field of the type SignedData contains the
439 client's certificate and additional certificates intended to
440 facilitate certification path construction, so that the KDC can
441 validate the client's certificate and verify the signature over
442 the type AuthPack. The certificates field MUST NOT contain
446 Tung & Zhu Expires August 4, 2005 [Page 8]
447 \f
448 Internet-Draft PKINIT January 2005
451 "root" CA certificates.
453 6. The client's Diffie-Hellman public value (clientPublicValue) is
454 included if and only if the client wishes to use the
455 Diffie-Hellman key agreement method. For the Diffie-Hellman key
456 agreement method, implementations MUST support Oakley 1024-bit
457 MODP well-known group 2 [RFC2412] and SHOULD support Oakley
458 2048-bit MODP well-known group 14 and Oakley 4096-bit MODP
459 well-known group 16 [RFC3526]. They MAY support Oakley 185-bit
460 EC2N group 4 [RFC2412]. The Diffie-Hellman group size should be
461 chosen so as to provide sufficient cryptographic security. The
462 exponents should have at least twice as many bits as the
463 symmetric keys that will be derived from them [ODL99].
465 7. The client may wish to cache DH keys or to allow the KDC to do
466 so. If so, then the client includes the clientDHNonce field.
467 This nonce string needs to be as long as the longest key length
468 of the symmetric key types that the client supports. This nonce
469 MUST be chosen randomly.
472 3.2.2 Receipt of Client Request
474 Upon receiving the client's request, the KDC validates it. This
475 section describes the steps that the KDC MUST (unless otherwise
476 noted) take in validating the request.
478 The KDC looks for the client's certificate in the signedAuthPack
479 (based on the signerInfo) and validate this certificate.
481 If the KDC cannot find a certification path to validate the client's
482 certificate, it sends back an error of type
483 KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for this
484 error is a TYPED-DATA (as defined in [CLAR]). For this error, the
485 data-type is TD-TRUSTED-CERTIFIERS, and the data-value is the DER
486 encoding of
488 TrustedCertifiers ::= SEQUENCE OF OCTET STRING
489 -- The OCTET STRING contains a PKIX type Name encoded
490 -- according to [RFC3280].
492 If, while processing the certification path, the KDC determines that
493 the signature on one of the certificates in the signedAuthPack is
494 invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE.
495 The accompanying e-data for this error is a TYPED-DATA, whose
496 data-type is TD-CERTIFICATE-INDEX, and whose data-value is the DER
497 encoding of the index into the CertificateSet field, ordered as sent
498 by the client:
502 Tung & Zhu Expires August 4, 2005 [Page 9]
503 \f
504 Internet-Draft PKINIT January 2005
507 CertificateIndex ::= OCTET STRING
508 -- Contains a CMS type IssuerAndSerialNumber encoded
509 -- according to [RFC3852].
510 -- IssuerAndSerialNumber of certificate with an
511 -- invalid signature.
513 If more than one certificate signature is invalid, the KDC MAY send
514 one TYPED-DATA per invalid signature.
516 The KDC SHOULD also check whether any certificates in the client's
517 certification path have been revoked. If any of them have been
518 revoked, the KDC MUST return an error of type
519 KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
520 revocation status but is unable to do so, it SHOULD return an error
521 of type KDC_ERR_REVOCATION_STATUS_UNKNOWN. The certificate or
522 certificates affected are identified exactly as for an error of type
523 KDC_ERR_INVALID_CERTIFICATE (see above).
525 In addition to validating the client's certificate, the KDC MUST also
526 check that this certificate properly maps to the client's principal
527 name as specified in the AS-REQ as follows:
529 1. If the KDC has its own mapping from the name in the client's
530 certificate to a Kerberos name, it uses that Kerberos name.
532 2. Otherwise, if the client's certificate contains a SubjectAltName
533 extension with a Kerberos name in the otherName field, it uses
534 that name.
536 The otherName field (of type AnotherName) in the SubjectAltName
537 extension MUST contain KRB5PrincipalName as defined below.
539 The type-id field of the type AnotherName is id-pksan:
541 id-pksan OBJECT IDENTIFIER ::=
542 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
543 x509-sanan (2) }
545 The value field of the type AnotherName is the DER encoding of the
546 following ASN.1 type:
548 KRB5PrincipalName ::= SEQUENCE {
549 realm [0] Realm,
550 principalName [1] PrincipalName
551 }
553 If the KDC does not have its own mapping and there is no Kerberos
554 name present in the client's certificate, or if the name in the
558 Tung & Zhu Expires August 4, 2005 [Page 10]
559 \f
560 Internet-Draft PKINIT January 2005
563 request does not match the name in the certificate (including the
564 realm name), the KDC MUST return error code
565 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for
566 this error.
568 Even if the client's certificate is validated and it is mapped to the
569 client's principal name, the KDC may decide not to accept the
570 client's certificate, depending on local policy.
572 The KDC MAY require the presence of an Extended Key Usage (EKU)
573 KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the
574 client's certificate:
576 id-pkekuoid OBJECT IDENTIFIER ::=
577 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
578 pkinit(3) pkekuoid(4) }
579 -- PKINIT client authentication.
580 -- Key usage bits that may be consistent: digitalSignature
581 -- nonRepudiation, and (keyEncipherment or keyAgreement).
583 As a matter of local policy, the KDC may decide to reject requests on
584 the basis of the absence or presence of specific EKU OIDs. KDCs
585 implementing this requirement SHOULD also accept the EKU KeyPurposeId
586 id-ms-sc-logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement,
587 as there are a large number of client certificates deployed for use
588 with PKINIT which have this EKU.
590 The KDC MUST return the error code KDC_ERR_CLIENT_NOT_TRUSTED if the
591 client's certificate is not accepted.
593 Once the client's certificate is accepted, the KDC can then verify
594 the client's signature over the type AuthPack according to [RFC3852].
595 If the signature fails to verify, the KDC MUST return error
596 KDC_ERR_INVALID_SIG. There is no accompanying e-data for this error.
598 The KDC MUST check the timestamp to ensure that the request is not a
599 replay, and that the time skew falls within acceptable limits. The
600 recommendations clock skew times in [CLAR] apply here. If the check
601 fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
602 KRB_AP_ERR_SKEW, respectively.
604 If the clientPublicValue is filled in, indicating that the client
605 wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
606 check to see if the key parameters satisfy its policy. If they do
607 not, it MUST return error code KDC_ERR_KEY_SIZE. The accompanying
608 e-data is a TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and
609 whose data-value is the DER encoding of the following:
614 Tung & Zhu Expires August 4, 2005 [Page 11]
615 \f
616 Internet-Draft PKINIT January 2005
619 TD-DH-PARAMETERS ::= SEQUENCE OF DomainParameters
620 -- Type DomainParameters is defined in [RFC3279].
621 -- Contains a list of Diffie-Hellman group
622 -- parameters in decreasing preference order.
624 TD-DH-PARAMETERS contains a list of Diffie-Hellman group parameters
625 that the KDC supports in decreasing preference order, from which the
626 client should pick one to retry the request.
628 The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the
629 client included a kdcCert field in the PA-PK-AS-REQ and the KDC does
630 not have the corresponding certificate.
632 The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client
633 did not include a kdcCert field, but did include a trustedCertifiers
634 field, and the KDC does not possesses a certificate issued by one of
635 the listed certifiers.
637 If there is a supportedCMSTypes field in the AuthPack, the KDC must
638 check to see if it supports any of the listed types. If it supports
639 more than one of the types, the KDC SHOULD use the one listed first.
640 If it does not support any of them, it MUST return an error of type
641 KRB5KDC_ERR_ETYPE_NOSUPP.
643 3.2.3 Generation of KDC Reply
645 Assuming that the client's request has been properly validated, the
646 KDC proceeds as per [CLAR], except as follows.
648 The KDC MUST set the initial flag and include an authorization data
649 of type AD-INITIAL-VERIFIED-CAS in the issued ticket. The value is
650 an OCTET STRING containing the DER encoding of InitialVerifiedCAs:
652 InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
653 ca [0] IMPLICIT OCTET STRING,
654 -- Contains a PKIX type Name encoded according to
655 -- [RFC3280].
656 validated [1] BOOLEAN,
657 ...
658 }
660 The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
661 containers if the list of CAs satisfies the KDC's realm's policy
662 (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
663 [CLAR]). Furthermore, any TGS must copy such authorization data from
664 tickets used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket,
665 including the AD-IF-RELEVANT container, if present.
670 Tung & Zhu Expires August 4, 2005 [Page 12]
671 \f
672 Internet-Draft PKINIT January 2005
675 Application servers that understand this authorization data type
676 SHOULD apply local policy to determine whether a given ticket bearing
677 such a type *not* contained within an AD-IF-RELEVANT container is
678 acceptable. (This corresponds to the AP server checking the
679 transited field when the TRANSITED-POLICY-CHECKED flag has not been
680 set [CLAR].) If such a data type is contained within an
681 AD-IF-RELEVANT container, AP servers MAY apply local policy to
682 determine whether the authorization data is acceptable.
684 The AS-REP is otherwise unchanged from [CLAR]. The KDC encrypts the
685 reply as usual, but not with the client's long-term key. Instead, it
686 encrypts it with either a shared key derived from a Diffie-Hellman
687 exchange, or a generated encryption key. The contents of the
688 PA-PK-AS-REP indicate which key delivery method is used:
690 PA-PK-AS-REP ::= CHOICE {
691 dhInfo [0] DHRepInfo,
692 encKeyPack [1] IMPLICIT OCTET STRING,
693 -- Contains a CMS type ContentInfo encoded
694 -- according to [RFC3852].
695 -- The contentType field of the type ContentInfo is
696 -- id-envelopedData (1.2.840.113549.1.7.3).
697 -- The content field is an EnvelopedData.
698 -- The contentType field for the type EnvelopedData
699 -- is id-signedData (1.2.840.113549.1.7.2).
700 -- The eContentType field for the inner type
701 -- SignedData (when unencrypted) is id-pkrkeydata
702 -- (1.2.840.113549.1.7.3) and the eContent field
703 -- contains the DER encoding of the type
704 -- ReplyKeyPack.
705 -- ReplyKeyPack is defined below.
706 ...
707 }
709 DHRepInfo ::= SEQUENCE {
710 dhSignedData [0] IMPLICIT OCTET STRING,
711 -- Contains a CMS type ContentInfo encoded according
712 -- to [RFC3852].
713 -- The contentType field of the type ContentInfo is
714 -- id-signedData (1.2.840.113549.1.7.2), and the
715 -- content field is a SignedData.
716 -- The eContentType field for the type SignedData is
717 -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
718 -- eContent field contains the DER encoding of the
719 -- type KDCDHKeyInfo.
720 -- KDCDHKeyInfo is defined below.
721 serverDHNonce [1] DHNonce OPTIONAL
722 -- Present if and only if dhKeyExpiration is
726 Tung & Zhu Expires August 4, 2005 [Page 13]
727 \f
728 Internet-Draft PKINIT January 2005
731 -- present.
732 }
734 KDCDHKeyInfo ::= SEQUENCE {
735 subjectPublicKey [0] BIT STRING,
736 -- KDC's public key, y = g^x mod p.
737 -- MUST be ASN.1 encoded as an INTEGER;
738 -- This encoding is then used as the contents
739 -- (i.e., the value) of this BIT STRING field.
740 nonce [1] INTEGER (0..4294967295),
741 -- Contains the nonce in the PKAuthenticator of the
742 -- request if cached DH keys are NOT used,
743 -- 0 otherwise.
744 dhKeyExpiration [2] KerberosTime OPTIONAL,
745 -- Expiration time for KDC's cached values, present
746 -- if and only if cached DH keys are used. If this
747 -- field is omitted then the serverDHNonce field
748 -- MUST also be omitted.
749 ...
750 }
753 3.2.3.1 Using Diffie-Hellman Key Exchange
755 In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
757 The ContentInfo [RFC3852] structure for the dhSignedData field is
758 filled in as follows:
760 1. The contentType field of the type ContentInfo is id-signedData
761 (as defined in [RFC3852]), and the content field is a SignedData
762 (as defined in [RFC3852]).
764 2. The eContentType field for the type SignedData is the OID value
765 for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
766 security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }.
768 3. The eContent field for the type SignedData contains the DER
769 encoding of the type KDCDHKeyInfo.
771 4. The signerInfos field of the type SignedData contains a single
772 signerInfo, which contains the signature over the type
773 KDCDHKeyInfo.
775 5. The certificates field of the type SignedData contains the KDC's
776 certificate and additional certificates intended to facilitate
777 certification path construction, so that the client can validate
778 the KDC's certificate and verify the KDC's signature over the
782 Tung & Zhu Expires August 4, 2005 [Page 14]
783 \f
784 Internet-Draft PKINIT January 2005
787 type KDCDHKeyInfo. This field may only be left empty if the
788 client did include a kdcCert field in the PA-PK-AS-REQ,
789 indicating that the client already has the KDC's certificate.
790 The certificates field MUST NOT contain "root" CA certificates.
792 6. If the client included the clientDHNonce field, then the KDC may
793 choose to reuse its DH keys. If the server reuses DH keys then
794 it MUST include an expiration time in the dhKeyExperiation field.
795 Past the point of the expiration time, the signature over the
796 type DHRepInfo is considered expired/invalid. When the server
797 reuses DH keys then it MUST include a serverDHNonce at least as
798 long as the length of keys for the symmetric encryption system
799 used to encrypt the AS reply. Note that including the
800 serverDHNonce changes how the client and server calculate the key
801 to use to encrypt the reply; see below for details. The KDC
802 SHOULD NOT reuse DH keys unless the clientDHNonce field is
803 present in the request.
805 The reply key for use to decrypt the KDC reply [CLAR] is derived as
806 follows:
808 1. Both the KDC and the client calculate the shared secret value
809 DHKey:
811 DHKey = g^(xb * xa) mod p
813 where xb and xa are the KDC's and client's private exponents,
814 respectively. DHKey, padded first with leading zeros as needed to
815 make it as long as the modulus p, is represented as a string of
816 octets in big-endian order (such that the size of DHKey in octets
817 is the size of the modulus p).
819 2. Let K be the key-generation seed length [KCRYPTO] of the reply
820 key whose enctype is selected according to [CLAR].
822 3. Define the function octetstring2key() as follows:
824 octetstring2key(x) == random-to-key(K-truncate(
825 SHA1(0x00 | x) |
826 SHA1(0x01 | x) |
827 SHA1(0x02 | x) |
828 ...
829 ))
831 where x is an octet string; | is the concatenation operator; 0x00,
832 0x01, 0x02, etc., are each represented as a single octet;
833 random-to-key() is an operation that generates a protocol key from
834 a bitstring of length K; and K-truncate truncates its input to the
838 Tung & Zhu Expires August 4, 2005 [Page 15]
839 \f
840 Internet-Draft PKINIT January 2005
843 first K bits. Both K and random-to-key() are defined in the
844 kcrypto profile [KCRYPTO] for the enctype of the reply key.
846 4. When cached DH keys are used, let n_c be the clientDHNonce, and
847 n_k be the serverDHNonce; otherwise, let both n_c and n_k be empty
848 octet strings.
850 5. The reply key k is:
852 k = octetstring2key(DHKey | n_c | n_k)
855 3.2.3.2 Using Public Key Encryption
857 In this case, the PA-PK-AS-REP contains a ContentInfo structure
858 wrapped in an OCTET STRING. The reply key for use to decrypt the KDC
859 reply [CLAR] is encrypted in the encKeyPack field, which contains
860 data of type ReplyKeyPack:
862 ReplyKeyPack ::= SEQUENCE {
863 replyKey [0] EncryptionKey,
864 -- Contains the session key used to encrypt the
865 -- enc-part field in the AS-REP.
866 nonce [1] INTEGER (0..4294967295),
867 -- Contains the nonce in the PKAuthenticator of the
868 -- request.
869 ...
870 }
872 The ContentInfo [RFC3852] structure for the encKeyPack field is
873 filled in as follows:
875 1. The contentType field of the type ContentInfo is id-envelopedData
876 (as defined in [RFC3852]), and the content field is an
877 EnvelopedData (as defined in [RFC3852]).
879 2. The contentType field for the type EnvelopedData is
880 id-signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
881 pkcs (1) pkcs7 (7) signedData (2) }.
883 3. The eContentType field for the inner type SignedData (when
884 decrypted from the encryptedContent field for the type
885 EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6)
886 internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }.
888 4. The eContent field for the inner type SignedData contains the DER
889 encoding of the type ReplyKeyPack.
894 Tung & Zhu Expires August 4, 2005 [Page 16]
895 \f
896 Internet-Draft PKINIT January 2005
899 5. The signerInfos field of the inner type SignedData contains a
900 single signerInfo, which contains the signature over the type
901 ReplyKeyPack.
903 6. The certificates field of the inner type SignedData contains the
904 KDC's certificate and additional certificates intended to
905 facilitate certification path construction, so that the client
906 can validate the KDC's certificate and verify the KDC's signature
907 over the type ReplyKeyPack. This field may only be left empty if
908 the client included a kdcCert field in the PA-PK-AS-REQ,
909 indicating that the client already has the KDC's certificate.
910 The certificates field MUST NOT contain "root" CA certificates.
912 7. The recipientInfos field of the type EnvelopedData is a SET which
913 MUST contain exactly one member of type KeyTransRecipientInfo.
914 The encryptedKey of this member contains the temporary key which
915 is encrypted using the client's public key.
917 8. The unprotectedAttrs or originatorInfo fields of the type
918 EnvelopedData MAY be present.
920 3.2.4 Receipt of KDC Reply
922 Upon receipt of the KDC's reply, the client proceeds as follows. If
923 the PA-PK-AS-REP contains the dhSignedData field, the client derives
924 the shared key using the same procedure used by the KDC as defined in
925 Section 3.2.3.1. Otherwise, the message contains an encKeyPack, and
926 the client decrypts and verifies the temporary encryption key.
928 In either case, the client MUST validate the KDC's certificate and
929 verify the signature in the SignedData according to [RFC3852].
930 Unless the client can otherwise prove that the KDC's certificate is
931 for the target KDC (i.e., the subject distinguished name in the KDC
932 certificate is bound to the hostname or IP address of the KDC
933 authenticating the client), it MUST do the following to verify the
934 responder's identity:
936 1. The client checks to see if the included certificate contains a
937 Subject Alternative Name extension [RFC3280] carrying a dNSName or
938 an iPAddress (if the KDC is specified by an IP address instead of
939 a name). If it does, it MUST check to see if that name value
940 matches that of the KDC it believes it is communicating with, with
941 matching rules specified in [RFC3280].
943 2. The client verifies that the KDC's certificate MUST contain the
944 EKU KeyPurposeId [RFC3280] id-pkkdcekuoid:
950 Tung & Zhu Expires August 4, 2005 [Page 17]
951 \f
952 Internet-Draft PKINIT January 2005
957 id-pkkdcekuoid OBJECT IDENTIFIER ::=
958 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
959 pkinit(3) pkkdcekuoid(5) }
960 -- Signing KDC responses.
961 -- Key usage bits that may be consistent:
962 -- digitalSignature.
964 If all applicable checks are satisfied, the client then decrypts the
965 enc-part of the KDC-REP in the AS_REP with the resulting key, and
966 then proceeds as described in [CLAR].
968 3.3 KDC Indication of PKINIT Support
970 If pre-authentication is required, but was not present in the
971 request, per [CLAR] an error message with the code
972 KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
973 stored in the e-data field of the KRB-ERROR message to specify which
974 pre-authentication mechanisms are acceptable. The KDC can then
975 indicate the support of PKINIT by including a PA-PK-AS-REQ element in
976 that METHOD-DATA object.
978 Otherwise if it is required by the KDC's local policy that the client
979 must be pre-authenticated using the pre-authentication mechanism
980 specified in this document, but no PKINIT pre-authentication was
981 present in the request, an error message with the code
982 KDC_ERR_PREAUTH_FAILED SHOULD be returned.
984 KDCs MUST leave the padata-value of PA-PK-AS-REQ entry in the
985 KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
986 STRING), and clients MUST ignore this and any other value. Future
987 extensions to this protocol may specify other data to send instead of
988 an empty OCTET STRING.
990 4. Security Considerations
992 PKINIT raises certain security considerations beyond those that can
993 be regulated strictly in protocol definitions. We will address them
994 in this section.
996 PKINIT extends the cross-realm model to the public-key
997 infrastructure. Users of PKINIT must understand security policies
998 and procedures appropriate to the use of Public Key Infrastructures.
1000 Standard Kerberos allows the possibility of interactions between
1001 cryptosystems of varying strengths; this document adds interactions
1002 with public-key cryptosystems to Kerberos. Some administrative
1006 Tung & Zhu Expires August 4, 2005 [Page 18]
1007 \f
1008 Internet-Draft PKINIT January 2005
1011 policies may allow the use of relatively weak public keys. Using
1012 such keys to wrap data encrypted under stronger conventional
1013 cryptosystems may be inappropriate.
1015 PKINIT requires keys for symmetric cryptosystems to be generated.
1016 Some such systems contain "weak" keys. For recommendations regarding
1017 these weak keys, see [CLAR].
1019 PKINIT uses the same RSA key pair for encryption and signing when
1020 doing RSA encryption based key delivery. This is not recommended
1021 usage of RSA keys [RFC3447], by using DH based key delivery this is
1022 avoided.
1024 Care should be taken in how certificates are chosen for the purposes
1025 of authentication using PKINIT. Some local policies may require that
1026 key escrow be used for certain certificate types. Deployers of
1027 PKINIT should be aware of the implications of using certificates that
1028 have escrowed keys for the purposes of authentication.
1030 PKINIT does not provide for a "return routability" test to prevent
1031 attackers from mounting a denial-of-service attack on the KDC by
1032 causing it to perform unnecessary and expensive public-key
1033 operations. Strictly speaking, this is also true of standard
1034 Kerberos, although the potential cost is not as great, because
1035 standard Kerberos does not make use of public-key cryptography.
1037 The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
1038 permit empty SEQUENCEs to be encoded. Such empty sequences may only
1039 be used if the KDC itself vouches for the user's certificate.
1041 5. Acknowledgements
1043 The following people have made significant contributions to this
1044 draft: Paul Leach, Phil Hallin, Kelvin Yiu, Sam Hartman, Love
1045 Hornquist Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan
1046 Trostle, Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon and
1047 Karthik Jaganathan.
1049 Special thanks to Clifford Neuman, Mat Hur and Sasha Medvinsky who
1050 wrote earlier versions of this document.
1052 The authors are indebt to the Kerberos working group chair Jeffrey
1053 Hutzelman who kept track of various issues and was enormously helpful
1054 during the creation of this document.
1056 Some of the ideas on which this document is based arose during
1057 discussions over several years between members of the SAAG, the IETF
1058 CAT working group, and the PSRG, regarding integration of Kerberos
1062 Tung & Zhu Expires August 4, 2005 [Page 19]
1063 \f
1064 Internet-Draft PKINIT January 2005
1067 and SPX. Some ideas have also been drawn from the DASS system.
1068 These changes are by no means endorsed by these groups. This is an
1069 attempt to revive some of the goals of those groups, and this
1070 document approaches those goals primarily from the Kerberos
1071 perspective.
1073 Lastly, comments from groups working on similar ideas in DCE have
1074 been invaluable.
1076 6. IANA Considerations
1078 This document has no actions for IANA.
1080 7. References
1082 7.1 Normative References
1084 [CLAR] RFC-Editor: To be replaced by RFC number for draft-ietf-
1085 krb-wg-kerberos-clarifications. Work in Progress.
1087 [KCRYPTO] RFC-Editor: To be replaced by RFC number for draft-ietf-
1088 krb-wg-crypto. Work in Progress.
1090 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1091 Requirement Levels", BCP 14, RFC 2119, March 1997.
1093 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
1094 RFC 2412, November 1998.
1096 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
1097 RFC 2631, June 1999.
1099 [RFC3279] Bassham, L., Polk, W. and R. Housley, "Algorithms and
1100 Identifiers for the Internet X.509 Public Key
1101 Infrastructure Certificate and Certificate Revocation List
1102 (CRL) Profile", RFC 3279, April 2002.
1104 [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
1105 X.509 Public Key Infrastructure Certificate and
1106 Certificate Revocation List (CRL) Profile", RFC 3280,
1107 April 2002.
1109 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
1110 Algorithms", RFC 3370, August 2002.
1112 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
1113 Standards (PKCS) #1: RSA Cryptography Specifications
1117 Tung & Zhu Expires August 4, 2005 [Page 20]
1118 \f
1119 Internet-Draft PKINIT January 2005
1122 Version 2.1", RFC 3447, February 2003.
1124 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
1125 Diffie-Hellman groups for Internet Key Exchange (IKE)",
1126 RFC 3526, May 2003.
1128 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES)
1129 Encryption Algorithm in Cryptographic Message Syntax
1130 (CMS)", RFC 3565, July 2003.
1132 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
1133 RFC 3852, July 2004.
1135 [X690] ASN.1 encoding rules: Specification of Basic Encoding
1136 Rules (BER), Canonical Encoding Rules (CER) and
1137 Distinguished Encoding Rules (DER), ITU-T Recommendation
1138 X.690 (1997) | ISO/IEC International Standard
1139 8825-1:1998.
1141 7.2 Informative References
1143 [ODL99] Odlyzko, A., "Discrete logarithms: The past and the
1144 future, Designs, Codes, and Cryptography (1999)".
1146 Authors' Addresses
1148 Brian Tung
1149 USC Information Sciences Institute
1150 4676 Admiralty Way Suite 1001, Marina del Rey CA
1151 Marina del Rey, CA 90292
1152 US
1154 Email: brian@isi.edu
1157 Larry Zhu
1158 Microsoft Corporation
1159 One Microsoft Way
1160 Redmond, WA 98052
1161 US
1163 Email: lzhu@microsoft.com
1165 Appendix A. PKINIT ASN.1 Module
1167 KerberosV5-PK-INIT-SPEC {
1168 iso(1) identified-organization(3) dod(6) internet(1)
1172 Tung & Zhu Expires August 4, 2005 [Page 21]
1173 \f
1174 Internet-Draft PKINIT January 2005
1177 security(5) kerberosV5(2) modules(4) pkinit(5)
1178 } DEFINITIONS EXPLICIT TAGS ::= BEGIN
1180 IMPORTS
1181 SubjectPublicKeyInfo, AlgorithmIdentifier
1182 FROM PKIX1Explicit88 { iso (1)
1183 identified-organization (3) dod (6) internet (1)
1184 security (5) mechanisms (5) pkix (7) id-mod (0)
1185 id-pkix1-explicit (18) }
1186 -- As defined in RFC 3280.
1188 DomainParameters
1189 FROM PKIX1Algorithms88 { iso(1)
1190 identified-organization(3) dod(6)
1191 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
1192 id-mod-pkix1-algorithms(17) }
1193 -- As defined in RFC 3279.
1195 KerberosTime, TYPED-DATA, PrincipalName, Realm, EncryptionKey
1196 FROM KerberosV5Spec2 { iso(1) identified-organization(3)
1197 dod(6) internet(1) security(5) kerberosV5(2)
1198 modules(4) krb5spec2(2) } ;
1200 id-pkinit OBJECT IDENTIFIER ::=
1201 { iso (1) org (3) dod (6) internet (1) security (5)
1202 kerberosv5 (2) pkinit (3) }
1204 id-pkauthdata OBJECT IDENTIFIER ::= { id-pkinit 1 }
1205 id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 }
1206 id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 }
1207 id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 }
1208 id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 }
1210 pa-pk-as-req INTEGER ::= 16
1211 pa-pk-as-rep INTEGER ::= 17
1213 ad-initial-verified-cas INTEGER ::= 9
1215 td-trusted-certifiers INTEGER ::= 104
1216 td-certificate-index INTEGER ::= 105
1217 td-dh-parameters INTEGER ::= 109
1219 PA-PK-AS-REQ ::= SEQUENCE {
1220 signedAuthPack [0] IMPLICIT OCTET STRING,
1221 -- Contains a CMS type ContentInfo encoded
1222 -- according to [RFC3852].
1223 -- The contentType field of the type ContentInfo
1224 -- is id-signedData (1.2.840.113549.1.7.2),
1228 Tung & Zhu Expires August 4, 2005 [Page 22]
1229 \f
1230 Internet-Draft PKINIT January 2005
1233 -- and the content field is a SignedData.
1234 -- The eContentType field for the type SignedData is
1235 -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
1236 -- eContent field contains the DER encoding of the
1237 -- type AuthPack.
1238 -- AuthPack is defined below.
1239 trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,
1240 -- A list of CAs, trusted by the client, that can
1241 -- be used to validate KDC certificates.
1242 kdcCert [2] IMPLICIT OCTET STRING
1243 OPTIONAL,
1244 -- Contains a CMS type IssuerAndSerialNumber encoded
1245 -- according to [RFC3852].
1246 -- Identifies a particular KDC certificate, if the
1247 -- client already has it.
1248 ...
1249 }
1251 DHNonce ::= OCTET STRING
1253 TrustedCA ::= CHOICE {
1254 caName [1] IMPLICIT OCTET STRING,
1255 -- Contains a PKIX type Name encoded according to
1256 -- [RFC3280].
1257 issuerAndSerial [2] IMPLICIT OCTET STRING,
1258 -- Contains a CMS type IssuerAndSerialNumber encoded
1259 -- according to [RFC3852].
1260 -- Identifies a specific CA certificate.
1261 ...
1262 }
1264 AuthPack ::= SEQUENCE {
1265 pkAuthenticator [0] PKAuthenticator,
1266 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
1267 -- Defined in [RFC3280].
1268 -- Present only if the client wishes to use the
1269 -- Diffie-Hellman key agreement method.
1270 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
1271 OPTIONAL,
1272 -- List of CMS encryption types supported by
1273 -- client in order of (decreasing) preference.
1274 clientDHNonce [3] DHNonce OPTIONAL,
1275 -- Present only if the client indicates that it
1276 -- wishes to cache DH keys or to allow the KDC to
1277 -- do so.
1278 ...
1279 }
1284 Tung & Zhu Expires August 4, 2005 [Page 23]
1285 \f
1286 Internet-Draft PKINIT January 2005
1289 PKAuthenticator ::= SEQUENCE {
1290 cusec [0] INTEGER (0..999999),
1291 ctime [1] KerberosTime,
1292 -- cusec and ctime are used as in [CLAR], for replay
1293 -- prevention.
1294 nonce [2] INTEGER (0..4294967295),
1295 -- Chosen randomly; This nonce does not need to
1296 -- match with the nonce in the KDC-REQ-BODY.
1297 paChecksum [3] OCTET STRING,
1298 -- Contains the SHA1 checksum, performed over
1299 -- KDC-REQ-BODY.
1300 ...
1301 }
1303 TrustedCertifiers ::= SEQUENCE OF OCTET STRING
1304 -- The OCTET STRING contains a PKIX type Name encoded
1305 -- according to [RFC3280].
1307 CertificateIndex ::= OCTET STRING
1308 -- Contains a CMS type IssuerAndSerialNumber encoded
1309 -- according to [RFC3852].
1311 KRB5PrincipalName ::= SEQUENCE {
1312 realm [0] Realm,
1313 principalName [1] PrincipalName
1314 }
1316 InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
1317 ca [0] IMPLICIT OCTET STRING,
1318 -- Contains a PKIX type Name encoded according to
1319 -- [RFC3280].
1320 validated [1] BOOLEAN,
1321 ...
1322 }
1324 PA-PK-AS-REP ::= CHOICE {
1325 dhInfo [0] DHRepInfo,
1326 encKeyPack [1] IMPLICIT OCTET STRING,
1327 -- Contains a CMS type ContentInfo encoded
1328 -- according to [RFC3852].
1329 -- The contentType field of the type ContentInfo is
1330 -- id-envelopedData (1.2.840.113549.1.7.3).
1331 -- The content field is an EnvelopedData.
1332 -- The contentType field for the type EnvelopedData
1333 -- is id-signedData (1.2.840.113549.1.7.2).
1334 -- The eContentType field for the inner type
1335 -- SignedData (when unencrypted) is id-pkrkeydata
1336 -- (1.2.840.113549.1.7.3) and the eContent field
1340 Tung & Zhu Expires August 4, 2005 [Page 24]
1341 \f
1342 Internet-Draft PKINIT January 2005
1345 -- contains the DER encoding of the type
1346 -- ReplyKeyPack.
1347 -- ReplyKeyPack is defined below.
1348 ...
1349 }
1351 DHRepInfo ::= SEQUENCE {
1352 dhSignedData [0] IMPLICIT OCTET STRING,
1353 -- Contains a CMS type ContentInfo encoded according
1354 -- to [RFC3852].
1355 -- The contentType field of the type ContentInfo is
1356 -- id-signedData (1.2.840.113549.1.7.2), and the
1357 -- content field is a SignedData.
1358 -- The eContentType field for the type SignedData is
1359 -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
1360 -- eContent field contains the DER encoding of the
1361 -- type KDCDHKeyInfo.
1362 -- KDCDHKeyInfo is defined below.
1363 serverDHNonce [1] DHNonce OPTIONAL
1364 -- Present if and only if dhKeyExpiration is
1365 -- present.
1366 }
1368 KDCDHKeyInfo ::= SEQUENCE {
1369 subjectPublicKey [0] BIT STRING,
1370 -- KDC's public key, y = g^x mod p.
1371 -- MUST be ASN.1 encoded as an INTEGER;
1372 -- This encoding is then used as the contents
1373 -- (i.e., the value) of this BIT STRING field.
1374 nonce [1] INTEGER (0..4294967295),
1375 -- Contains the nonce in the PKAuthenticator of the
1376 -- request if cached DH keys are NOT used,
1377 -- 0 otherwise.
1378 dhKeyExpiration [2] KerberosTime OPTIONAL,
1379 -- Expiration time for KDC's cached values, present
1380 -- if and only if cached DH keys are used. If this
1381 -- field is omitted then the serverDHNonce field
1382 -- MUST also be omitted.
1383 ...
1384 }
1386 ReplyKeyPack ::= SEQUENCE {
1387 replyKey [0] EncryptionKey,
1388 -- Contains the session key used to encrypt the
1389 -- enc-part field in the AS-REP.
1390 nonce [1] INTEGER (0..4294967295),
1391 -- Contains the nonce in the PKAuthenticator of the
1392 -- request.
1396 Tung & Zhu Expires August 4, 2005 [Page 25]
1397 \f
1398 Internet-Draft PKINIT January 2005
1401 ...
1402 }
1404 TD-DH-PARAMETERS ::= SEQUENCE OF DomainParameters
1405 -- Contains a list of Diffie-Hellman group
1406 -- parameters in decreasing preference order.
1407 END
1452 Tung & Zhu Expires August 4, 2005 [Page 26]
1453 \f
1454 Internet-Draft PKINIT January 2005
1457 Intellectual Property Statement
1459 The IETF takes no position regarding the validity or scope of any
1460 Intellectual Property Rights or other rights that might be claimed to
1461 pertain to the implementation or use of the technology described in
1462 this document or the extent to which any license under such rights
1463 might or might not be available; nor does it represent that it has
1464 made any independent effort to identify any such rights. Information
1465 on the procedures with respect to rights in RFC documents can be
1466 found in BCP 78 and BCP 79.
1468 Copies of IPR disclosures made to the IETF Secretariat and any
1469 assurances of licenses to be made available, or the result of an
1470 attempt made to obtain a general license or permission for the use of
1471 such proprietary rights by implementers or users of this
1472 specification can be obtained from the IETF on-line IPR repository at
1473 http://www.ietf.org/ipr.
1475 The IETF invites any interested party to bring to its attention any
1476 copyrights, patents or patent applications, or other proprietary
1477 rights that may cover technology that may be required to implement
1478 this standard. Please address the information to the IETF at
1479 ietf-ipr@ietf.org.
1482 Disclaimer of Validity
1484 This document and the information contained herein are provided on an
1485 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1486 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1487 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1488 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1489 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1490 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1493 Copyright Statement
1495 Copyright (C) The Internet Society (2005). This document is subject
1496 to the rights, licenses and restrictions contained in BCP 78, and
1497 except as set forth therein, the authors retain all their rights.
1500 Acknowledgment
1502 Funding for the RFC Editor function is currently provided by the
1503 Internet Society.
1508 Tung & Zhu Expires August 4, 2005 [Page 27]
1509 \f