2 INTERNET-DRAFT Brian Tung
3 draft-ietf-cat-kerberos-pk-init-15.txt Clifford Neuman
4 Updates: RFC 1510bis USC/ISI
5 expires May 25, 2002 Matthew Hur
16 Public Key Cryptography for Initial Authentication in Kerberos
18 0. Status Of This Memo
20 This document is an Internet-Draft and is in full conformance with
21 all provisions of Section 10 of RFC 2026. Internet-Drafts are
22 working documents of the Internet Engineering Task Force (IETF),
23 its areas, and its working groups. Note that other groups may also
24 distribute working documents as Internet-Drafts.
26 Internet-Drafts are draft documents valid for a maximum of six
27 months and may be updated, replaced, or obsoleted by other
28 documents at any time. It is inappropriate to use Internet-Drafts
29 as reference material or to cite them other than as "work in
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 To learn the current status of any Internet-Draft, please check
39 the "1id-abstracts.txt" listing contained in the Internet-Drafts
40 Shadow Directories on ftp.ietf.org (US East Coast),
41 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
42 munnari.oz.au (Pacific Rim).
44 The distribution of this memo is unlimited. It is filed as
45 draft-ietf-cat-kerberos-pk-init-15.txt, and expires May 25, 2002.
46 Please send comments to the authors.
50 This document defines extensions (PKINIT) to the Kerberos protocol
51 specification (RFC 1510bis [1]) to provide a method for using public
52 key cryptography during initial authentication. The methods
53 defined specify the ways in which preauthentication data fields and
54 error data fields in Kerberos messages are to be used to transport
59 The popularity of public key cryptography has produced a desire for
60 its support in Kerberos [2]. The advantages provided by public key
61 cryptography include simplified key management (from the Kerberos
62 perspective) and the ability to leverage existing and developing
63 public key certification infrastructures.
65 Public key cryptography can be integrated into Kerberos in a number
66 of ways. One is to associate a key pair with each realm, which can
67 then be used to facilitate cross-realm authentication; this is the
68 topic of another draft proposal. Another way is to allow users with
69 public key certificates to use them in initial authentication. This
70 is the concern of the current document.
72 PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in
73 combination with DSA keys as the primary, required mechanism. Note
74 that PKINIT supports the use of separate signature and encryption
77 PKINIT enables access to Kerberos-secured services based on initial
78 authentication utilizing public key cryptography. PKINIT utilizes
79 standard public key signature and encryption data formats within the
80 standard Kerberos messages. The basic mechanism is as follows: The
81 user sends an AS-REQ message to the KDC as before, except that if that
82 user is to use public key cryptography in the initial authentication
83 step, his certificate and a signature accompany the initial request
84 in the preauthentication fields. Upon receipt of this request, the
85 KDC verifies the certificate and issues a ticket granting ticket
86 (TGT) as before, except that the encPart from the AS-REP message
87 carrying the TGT is now encrypted utilizing either a Diffie-Hellman
88 derived key or the user's public key. This message is authenticated
89 utilizing the public key signature of the KDC.
91 Note that PKINIT does not require the use of certificates. A KDC
92 may store the public key of a principal as part of that principal's
93 record. In this scenario, the KDC is the trusted party that vouches
94 for the principal (as in a standard, non-cross realm, Kerberos
95 environment). Thus, for any principal, the KDC may maintain a
96 symmetric key, a public key, or both.
98 The PKINIT specification may also be used as a building block for
99 other specifications. PKINIT may be utilized to establish
100 inter-realm keys for the purposes of issuing cross-realm service
101 tickets. It may also be used to issue anonymous Kerberos tickets
102 using the Diffie-Hellman option. Efforts are under way to draft
103 specifications for these two application protocols.
105 Additionally, the PKINIT specification may be used for direct peer
106 to peer authentication without contacting a central KDC. This
107 application of PKINIT is based on concepts introduced in [6, 7].
108 For direct client-to-server authentication, the client uses PKINIT
109 to authenticate to the end server (instead of a central KDC), which
110 then issues a ticket for itself. This approach has an advantage
111 over TLS [5] in that the server does not need to save state (cache
112 session keys). Furthermore, an additional benefit is that Kerberos
113 tickets can facilitate delegation (see [6]).
115 3. Proposed Extensions
117 This section describes extensions to RFC 1510bis for supporting the
118 use of public key cryptography in the initial request for a ticket
119 granting ticket (TGT).
121 In summary, the following change to RFC 1510bis is proposed:
123 * Users may authenticate using either a public key pair or a
124 conventional (symmetric) key. If public key cryptography is
125 used, public key data is transported in preauthentication
126 data fields to help establish identity. The user presents
127 a public key certificate and obtains an ordinary TGT that may
128 be used for subsequent authentication, with such
129 authentication using only conventional cryptography.
131 Section 3.1 provides definitions to help specify message formats.
132 Section 3.2 describes the extensions for the initial authentication
137 The extensions involve new preauthentication fields; we introduce
138 the following preauthentication types:
143 The extensions also involve new error types; we introduce the
146 KDC_ERR_CLIENT_NOT_TRUSTED 62
147 KDC_ERR_KDC_NOT_TRUSTED 63
148 KDC_ERR_INVALID_SIG 64
149 KDC_ERR_KEY_TOO_WEAK 65
150 KDC_ERR_CERTIFICATE_MISMATCH 66
151 KDC_ERR_CANT_VERIFY_CERTIFICATE 70
152 KDC_ERR_INVALID_CERTIFICATE 71
153 KDC_ERR_REVOKED_CERTIFICATE 72
154 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
155 KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74
156 KDC_ERR_CLIENT_NAME_MISMATCH 75
157 KDC_ERR_KDC_NAME_MISMATCH 76
159 We utilize the following typed data for errors:
161 TD-PKINIT-CMS-CERTIFICATES 101
164 TD-TRUSTED-CERTIFIERS 104
165 TD-CERTIFICATE-INDEX 105
167 We utilize the following encryption types (which map directly to
171 md5WithRSAEncryption-CmsOID 10
172 sha1WithRSAEncryption-CmsOID 11
174 rsaEncryption-EnvOID (PKCS#1 v1.5) 13
175 rsaES-OAEP-ENV-OID (PKCS#1 v2.0) 14
176 des-ede3-cbc-Env-OID 15
178 These mappings are provided so that a client may send the
179 appropriate enctypes in the AS-REQ message in order to indicate
180 support for the corresponding OIDs (for performing PKINIT). The
181 above encryption types are utilized only within CMS structures
182 within the PKINIT preauthentication fields. Their use within
183 the Kerberos EncryptedData structure is unspecified.
185 In many cases, PKINIT requires the encoding of the X.500 name of a
186 certificate authority as a Realm. When such a name appears as
187 a realm it will be represented using the "Other" form of the realm
188 name as specified in the naming constraints section of RFC 1510bis.
189 For a realm derived from an X.500 name, NAMETYPE will have the value
190 X500-RFC2253. The full realm name will appear as follows:
192 <nametype> + ":" + <string>
194 where nametype is "X500-RFC2253" and string is the result of doing
195 an RFC2253 encoding of the distinguished name, i.e.
197 "X500-RFC2253:" + RFC2253Encode(DistinguishedName)
199 where DistinguishedName is an X.500 name, and RFC2253Encode is a
200 function returing a readable UTF encoding of an X.500 name, as
201 defined by RFC 2253 [11] (part of LDAPv3 [15]).
203 Each component of a DistinguishedName is called a
204 RelativeDistinguishedName, where a RelativeDistinguishedName is a
205 SET OF AttributeTypeAndValue. RFC 2253 does not specify the order
206 in which to encode the elements of the RelativeDistinguishedName and
207 so to ensure that this encoding is unique, we add the following rule
208 to those specified by RFC 2253:
210 When converting a multi-valued RelativeDistinguishedName
211 to a string, the output consists of the string encodings
212 of each AttributeTypeAndValue, in the same order as
213 specified by the DER encoding.
215 Similarly, in cases where the KDC does not provide a specific
216 policy-based mapping from the X.500 name or X.509 Version 3
217 SubjectAltName extension in the user's certificate to a Kerberos
218 principal name, PKINIT requires the direct encoding of the X.500
219 name as a PrincipalName. In this case, the name-type of the
220 principal name MUST be set to KRB_NT-X500-PRINCIPAL. This new
221 name type is defined in RFC 1510bis as:
223 KRB_NT_X500_PRINCIPAL 6
225 For this type, the name-string MUST be set as follows:
227 RFC2253Encode(DistinguishedName)
229 as described above. When this name type is used, the principal's
230 realm MUST be set to the certificate authority's distinguished
231 name using the X500-RFC2253 realm name format described earlier in
234 Note that the same string may be represented using several different
235 ASN.1 data types. As the result, the reverse conversion from an
236 RFC2253-encoded principal name back to an X.500 name may not be
237 unique and may result in an X.500 name that is not the same as the
238 original X.500 name found in the client certificate.
240 RFC 1510bis describes an alternate encoding of an X.500 name into a
241 realm name. However, as described in RFC 1510bis, the alternate
242 encoding does not guarantee a unique mapping from a
243 DistinguishedName inside a certificate into a realm name and
244 similarly cannot be used to produce a unique principal name. PKINIT
245 therefore uses an RFC 2253-based name mapping approach, as specified
248 RFC 1510bis specifies the ASN.1 structure for PrincipalName as follows:
250 PrincipalName ::= SEQUENCE {
251 name-type[0] INTEGER,
252 name-string[1] SEQUENCE OF GeneralString
255 The following rules relate to the the matching of PrincipalNames
256 with regard to the PKI name constraints for CAs as laid out in RFC
257 2459 [12]. In order to be regarded as a match (for permitted and
258 excluded name trees), the following MUST be satisfied.
260 1. If the constraint is given as a user plus realm name, or
261 as a client principal name plus realm name (as specified in
262 RFC 1510bis), the realm name MUST be valid (see 2.a-d below)
263 and the match MUST be exact, byte for byte.
265 2. If the constraint is given only as a realm name, matching
266 depends on the type of the realm:
268 a. If the realm contains a colon (':') before any equal
269 sign ('='), it is treated as a realm of type Other,
270 and MUST match exactly, byte for byte.
272 b. Otherwise, if the realm name conforms to rules regarding
273 the format of DNS names, it is considered a realm name of
274 type Domain. The constraint may be given as a realm
275 name 'FOO.BAR', which matches any PrincipalName within
276 the realm 'FOO.BAR' but not those in subrealms such as
277 'CAR.FOO.BAR'. A constraint of the form '.FOO.BAR'
278 matches PrincipalNames in subrealms of the form
279 'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself.
281 c. Otherwise, the realm name is invalid and does not match
282 under any conditions.
284 3.1.1. Encryption and Key Formats
286 In the exposition below, we use the terms public key and private
287 key generically. It should be understood that the term "public
288 key" may be used to refer to either a public encryption key or a
289 signature verification key, and that the term "private key" may be
290 used to refer to either a private decryption key or a signature
291 generation key. The fact that these are logically distinct does
292 not preclude the assignment of bitwise identical keys for RSA
295 In the case of Diffie-Hellman, the key is produced from the agreed
296 bit string as follows:
298 * Truncate the bit string to the required length.
299 * Apply the specific cryptosystem's random-to-key function.
301 Appropriate key constraints for each valid cryptosystem are given
304 3.1.2. Algorithm Identifiers
306 PKINIT does not define, but does permit, the algorithm identifiers
309 3.1.2.1. Signature Algorithm Identifiers
311 The following signature algorithm identifiers specified in [8] and
312 in [12] are used with PKINIT:
314 id-dsa-with-sha1 (DSA with SHA1)
315 md5WithRSAEncryption (RSA with MD5)
316 sha-1WithRSAEncryption (RSA with SHA1)
318 3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier
320 The following algorithm identifier shall be used within the
321 SubjectPublicKeyInfo data structure: dhpublicnumber
323 This identifier and the associated algorithm parameters are
324 specified in RFC 2459 [12].
326 3.1.2.3. Algorithm Identifiers for RSA Encryption
328 These algorithm identifiers are used inside the EnvelopedData data
329 structure, for encrypting the temporary key with a public key:
331 rsaEncryption (RSA encryption, PKCS#1 v1.5)
332 id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0)
334 Both of the above RSA encryption schemes are specified in [13].
335 Currently, only PKCS#1 v1.5 is specified by CMS [8], although the
336 CMS specification says that it will likely include PKCS#1 v2.0 in
337 the future. (PKCS#1 v2.0 addresses adaptive chosen ciphertext
338 vulnerability discovered in PKCS#1 v1.5.)
340 3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys
342 These algorithm identifiers are used inside the EnvelopedData data
343 structure in the PKINIT Reply, for encrypting the reply key with the
345 des-ede3-cbc (3-key 3-DES, CBC mode)
346 rc2-cbc (RC2, CBC mode)
348 The full definition of the above algorithm identifiers and their
349 corresponding parameters (an IV for block chaining) is provided in
350 the CMS specification [8].
352 3.2. Public Key Authentication
354 Implementation of the changes in this section is REQUIRED for
355 compliance with PKINIT.
357 3.2.1. Client Request
359 Public keys may be signed by some certification authority (CA), or
360 they may be maintained by the KDC in which case the KDC is the
361 trusted authority. Note that the latter mode does not require the
364 The initial authentication request is sent as per RFC 1510bis, except
365 that a preauthentication field containing data signed by the user's
366 private key accompanies the request:
368 PA-PK-AS-REQ ::= SEQUENCE {
370 signedAuthPack [0] ContentInfo,
371 -- Defined in CMS [8];
372 -- SignedData OID is {pkcs7 2}
373 -- AuthPack (below) defines the
374 -- data that is signed.
375 trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL,
376 -- This is a list of CAs that the
377 -- client trusts and that certify
379 kdcCert [2] IssuerAndSerialNumber OPTIONAL
380 -- As defined in CMS [8];
381 -- specifies a particular KDC
382 -- certificate if the client
384 encryptionCert [3] IssuerAndSerialNumber OPTIONAL
385 -- For example, this may be the
386 -- client's Diffie-Hellman
387 -- certificate, or it may be the
388 -- client's RSA encryption
392 TrustedCas ::= CHOICE {
393 principalName [0] KerberosName,
396 -- fully qualified X.500 name
397 -- as defined by X.509
398 issuerAndSerial [2] IssuerAndSerialNumber
399 -- Since a CA may have a number of
400 -- certificates, only one of which
404 The type of the ContentInfo in the signedAuthPack is SignedData.
405 Its usage is as follows:
407 The SignedData data type is specified in the Cryptographic
408 Message Syntax, a product of the S/MIME working group of the
409 IETF. The following describes how to fill in the fields of
412 1. The encapContentInfo field MUST contain the PKAuthenticator
413 and, optionally, the client's Diffie Hellman public value.
415 a. The eContentType field MUST contain the OID value for
416 pkauthdata: iso (1) org (3) dod (6) internet (1)
417 security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)
419 b. The eContent field is data of the type AuthPack (below).
421 2. The signerInfos field contains the signature of AuthPack.
423 3. The Certificates field, when non-empty, contains the client's
424 certificate chain. If present, the KDC uses the public key
425 from the client's certificate to verify the signature in the
426 request. Note that the client may pass different certificate
427 chains that are used for signing or for encrypting. Thus,
428 the KDC may utilize a different client certificate for
429 signature verification than the one it uses to encrypt the
430 reply to the client. For example, the client may place a
431 Diffie-Hellman certificate in this field in order to convey
432 its static Diffie Hellman certificate to the KDC to enable
433 static-ephemeral Diffie-Hellman mode for the reply; in this
434 case, the client does NOT place its public value in the
435 AuthPack (defined below). As another example, the client may
436 place an RSA encryption certificate in this field. However,
437 there MUST always be (at least) a signature certificate.
439 4. When a DH key is being used, the public exponent is provided
440 in the subjectPublicKey field of the SubjectPublicKeyInfo and
441 the DH parameters are supplied as a DHParameter in the
442 AlgorithmIdentitfier parameters. The DH paramters SHOULD be
443 chosen from the First and Second defined Oakley Groups [The
444 Internet Key Exchange (IKE) RFC-2409], if a server will not
445 accept either of these groups, it will respond with a krb-error
446 of KDC_ERR_KEY_TOO_WEAK and the e_data will contain a
447 DHParameter with appropriate parameters for the client to use.
449 5. The KDC may wish to use cached Diffie-Hellman parameters
450 (see Section 3.2.2, KDC Response). To indicate acceptance
451 of cached parameters, the client sends zero in the nonce
452 field of the PKAuthenticator. Zero is not a valid value
453 for this field under any other circumstances. If cached
454 parameters are used, the client and the KDC MUST perform
455 key derivation (for the appropriate cryptosystem) on the
456 resulting encryption key, as specified in RFC 1510bis. (With
457 a zero nonce, message binding is performed using the nonce
458 in the main request, which must be encrypted using the
459 encapsulated reply key.)
461 AuthPack ::= SEQUENCE {
462 pkAuthenticator [0] PKAuthenticator,
463 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL
464 -- if client is using Diffie-Hellman
465 -- (ephemeral-ephemeral only)
468 PKAuthenticator ::= SEQUENCE {
470 -- for replay prevention as in RFC 1510bis
471 ctime [1] KerberosTime,
472 -- for replay prevention as in RFC 1510bis
474 -- zero only if client will accept
475 -- cached DH parameters from KDC;
476 -- must be non-zero otherwise
477 pachecksum [3] Checksum
478 -- Checksum over KDC-REQ-BODY
479 -- Defined by Kerberos spec;
480 -- must be unkeyed, e.g. sha1 or rsa-md5
483 SubjectPublicKeyInfo ::= SEQUENCE {
484 algorithm AlgorithmIdentifier,
486 subjectPublicKey BIT STRING
488 -- public exponent (INTEGER encoded
489 -- as payload of BIT STRING)
490 } -- as specified by the X.509 recommendation [7]
492 AlgorithmIdentifier ::= SEQUENCE {
493 algorithm OBJECT IDENTIFIER,
494 -- for dhKeyAgreement, this is
495 -- { iso (1) member-body (2) US (840)
496 -- rsadsi (113459) pkcs (1) 3 1 }
498 parameters ANY DEFINED by algorithm OPTIONAL
499 -- for dhKeyAgreement, this is
501 } -- as specified by the X.509 recommendation [7]
503 DHParameter ::= SEQUENCE {
508 privateValueLength INTEGER OPTIONAL
510 } -- as defined in PKCS #3 [17]
512 If the client passes an issuer and serial number in the request,
513 the KDC is requested to use the referred-to certificate. If none
514 exists, then the KDC returns an error of type
515 KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the
516 other hand, the client does not pass any trustedCertifiers,
517 believing that it has the KDC's certificate, but the KDC has more
518 than one certificate. The KDC should include information in the
519 KRB-ERROR message that indicates the KDC certificate(s) that a
520 client may utilize. This data is specified in the e-data, which
521 is defined in RFC 1510bis revisions as a SEQUENCE of TypedData:
523 TypedData ::= SEQUENCE {
524 data-type [0] INTEGER,
525 data-value [1] OCTET STRING,
526 } -- per Kerberos RFC 1510bis
529 data-type = TD-PKINIT-CMS-CERTIFICATES = 101
530 data-value = CertificateSet // as specified by CMS [8]
532 The PKAuthenticator carries information to foil replay attacks, to
533 bind the pre-authentication data to the KDC-REQ-BODY, and to bind the
534 request and response. The PKAuthenticator is signed with the client's
539 Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
540 type, the KDC attempts to verify the user's certificate chain
541 (userCert), if one is provided in the request. This is done by
542 verifying the certification path against the KDC's policy of
543 legitimate certifiers.
545 If the client's certificate chain contains no certificate signed by
546 a CA trusted by the KDC, then the KDC sends back an error message
547 of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data
548 is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104)
549 whose data-value is an OCTET STRING which is the DER encoding of
551 TrustedCertifiers ::= SEQUENCE OF PrincipalName
552 -- X.500 name encoded as a principal name
555 If while verifying a certificate chain the KDC determines that the
556 signature on one of the certificates in the CertificateSet from
557 the signedAuthPack fails verification, then the KDC returns an
558 error of type KDC_ERR_INVALID_CERTIFICATE. The accompanying
559 e-data is a SEQUENCE of one TypedData (with type
560 TD-CERTIFICATE-INDEX=105) whose data-value is an OCTET STRING
561 which is the DER encoding of the index into the CertificateSet
562 ordered as sent by the client.
564 CertificateIndex ::= INTEGER
565 -- 0 = 1st certificate,
566 -- (in order of encoding)
567 -- 1 = 2nd certificate, etc
569 The KDC may also check whether any of the certificates in the
570 client's chain has been revoked. If one of the certificates has
571 been revoked, then the KDC returns an error of type
572 KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that
573 the certificate's revocation status is unknown or not
574 available, then if required by policy, the KDC returns the
575 appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or
576 KDC_ERR_REVOCATION_STATUS_UNAVAILABLE. In any of these three
577 cases, the affected certificate is identified by the accompanying
578 e-data, which contains a CertificateIndex as described for
579 KDC_ERR_INVALID_CERTIFICATE.
581 If the certificate chain can be verified, but the name of the
582 client in the certificate does not match the client's name in the
583 request, then the KDC returns an error of type
584 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data
587 Even if all succeeds, the KDC may--for policy reasons--decide not
588 to trust the client. In this case, the KDC returns an error message
589 of type KDC_ERR_CLIENT_NOT_TRUSTED. One specific case of this is
590 the presence or absence of an Enhanced Key Usage (EKU) OID within
591 the certificate extensions. The rules regarding acceptability of
592 an EKU sequence (or the absence of any sequence) are a matter of
593 local policy. For the benefit of implementers, we define a PKINIT
594 EKU OID as the following: iso (1) org (3) dod (6) internet (1)
595 security (5) kerberosv5 (2) pkinit (3) pkekuoid (2).
597 If a trust relationship exists, the KDC then verifies the client's
598 signature on AuthPack. If that fails, the KDC returns an error
599 message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the
600 timestamp (ctime and cusec) in the PKAuthenticator to assure that
601 the request is not a replay. The KDC also verifies that its name
602 is specified in the PKAuthenticator.
604 If the clientPublicValue field is filled in, indicating that the
605 client wishes to use Diffie-Hellman key agreement, then the KDC
606 checks to see that the parameters satisfy its policy. If they do
607 not (e.g., the prime size is insufficient for the expected
608 encryption type), then the KDC sends back an error message of type
609 KDC_ERR_KEY_TOO_WEAK, with an e-data containing a structure of
610 type DHParameter with appropriate DH parameters for the client to
611 retry the request. Otherwise, it generates its own public and
612 private values for the response.
614 The KDC also checks that the timestamp in the PKAuthenticator is
615 within the allowable window and that the principal name and realm
616 are correct. If the local (server) time and the client time in the
617 authenticator differ by more than the allowable clock skew, then the
618 KDC returns an error message of type KRB_AP_ERR_SKEW as defined in
621 Assuming no errors, the KDC replies as per RFC 1510bis, except as
622 follows. The user's name in the ticket is determined by the
623 following decision algorithm:
625 1. If the KDC has a mapping from the name in the certificate
626 to a Kerberos name, then use that name.
628 2. If the certificate contains the SubjectAltName extention
629 and the local KDC policy defines a mapping from the
630 SubjectAltName to a Kerberos name, then use that name.
632 3. Use the name as represented in the certificate, mapping
633 as necessary (e.g., as per RFC 2253 for X.500 names). In
634 this case the realm in the ticket MUST be the name of the
635 certifier that issued the user's certificate.
637 Note that a principal name may be carried in the subjectAltName
638 field of a certificate. This name may be mapped to a principal
639 record in a security database based on local policy, for example
640 the subjectAltName may be kerberos/principal@realm format. In
641 this case the realm name is not that of the CA but that of the
642 local realm doing the mapping (or some realm name chosen by that
645 If a non-KDC X.509 certificate contains the principal name within
646 the subjectAltName version 3 extension, that name may utilize
647 KerberosName as defined below, or, in the case of an S/MIME
648 certificate [14], may utilize the email address. If the KDC
649 is presented with an S/MIME certificate, then the email address
650 within subjectAltName will be interpreted as a principal and realm
651 separated by the "@" sign, or as a name that needs to be mapped
652 according to local policy. If the resulting name does not correspond
653 to a registered principal name, then the principal name is formed as
654 defined in section 3.1.
656 The trustedCertifiers field contains a list of certification
657 authorities trusted by the client, in the case that the client does
658 not possess the KDC's public key certificate. If the KDC has no
659 certificate signed by any of the trustedCertifiers, then it returns
660 an error of type KDC_ERR_KDC_NOT_TRUSTED.
662 KDCs should try to (in order of preference):
663 1. Use the KDC certificate identified by the serialNumber included
664 in the client's request.
665 2. Use a certificate issued to the KDC by one of the client's
667 If the KDC is unable to comply with any of these options, then the
668 KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the
671 The KDC encrypts the reply not with the user's long-term key, but
672 with the Diffie Hellman derived key or a random key generated
673 for this particular response which is carried in the padata field of
676 PA-PK-AS-REP ::= CHOICE {
678 dhSignedData [0] ContentInfo,
679 -- Defined in CMS [8] and used only with
680 -- Diffie-Hellman key exchange (if the
681 -- client public value was present in the
683 -- SignedData OID is {pkcs7 2}
684 -- This choice MUST be supported
685 -- by compliant implementations.
686 encKeyPack [1] ContentInfo
687 -- Defined in CMS [8].
688 -- The temporary key is encrypted
689 -- using the client public key
691 -- EnvelopedData OID is {pkcs7 3}
692 -- SignedReplyKeyPack, encrypted
693 -- with the temporary key, is also
697 The type of the ContentInfo in the dhSignedData is SignedData.
698 Its usage is as follows:
700 When the Diffie-Hellman option is used, dhSignedData in
701 PA-PK-AS-REP provides authenticated Diffie-Hellman parameters
702 of the KDC. The reply key used to encrypt part of the KDC reply
703 message is derived from the Diffie-Hellman exchange:
705 1. Both the KDC and the client calculate a secret value
706 (g^ab mod p), where a is the client's private exponent and
707 b is the KDC's private exponent.
709 2. Both the KDC and the client take the first N bits of this
710 secret value and convert it into a reply key. N depends on
713 a. For example, if the reply key is DES, N=64 bits, where
714 some of the bits are replaced with parity bits, according
717 b. As another example, if the reply key is (3-key) 3-DES,
718 N=192 bits, where some of the bits are replaced with
719 parity bits, according to FIPS PUB 74.
721 3. The encapContentInfo field MUST contain the KdcDHKeyInfo as
724 a. The eContentType field MUST contain the OID value for
725 pkdhkeydata: iso (1) org (3) dod (6) internet (1)
726 security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2)
728 b. The eContent field is data of the type KdcDHKeyInfo
731 4. The certificates field MUST contain the certificates
732 necessary for the client to establish trust in the KDC's
733 certificate based on the list of trusted certifiers sent by
734 the client in the PA-PK-AS-REQ. This field may be empty if
735 the client did not send to the KDC a list of trusted
736 certifiers (the trustedCertifiers field was empty, meaning
737 that the client already possesses the KDC's certificate).
739 5. The signerInfos field is a SET that MUST contain at least
740 one member, since it contains the actual signature.
742 6. If the client indicated acceptance of cached Diffie-Hellman
743 parameters from the KDC, and the KDC supports such an option
744 (for performance reasons), the KDC should return a zero in
745 the nonce field and include the expiration time of the
746 parameters in the dhKeyExpiration field. If this time is
747 exceeded, the client SHOULD NOT use the reply. If the time
748 is absent, the client SHOULD NOT use the reply and MAY
749 resubmit a request with a non-zero nonce (thus indicating
750 non-acceptance of cached Diffie-Hellman parameters). As
751 indicated above in Section 3.2.1, Client Request, when the
752 KDC uses cached parameters, the client and the KDC MUST
753 perform key derivation (for the appropriate cryptosystem)
754 on the resulting encryption key, as specified in RFC 1510bis.
756 KdcDHKeyInfo ::= SEQUENCE {
757 -- used only when utilizing Diffie-Hellman
758 subjectPublicKey [0] BIT STRING,
759 -- Equals public exponent (g^a mod p)
760 -- INTEGER encoded as payload of
763 -- Binds response to the request
764 -- Exception: Set to zero when KDC
765 -- is using a cached DH value
766 dhKeyExpiration [2] KerberosTime OPTIONAL
767 -- Expiration time for KDC's cached
771 The type of the ContentInfo in the encKeyPack is EnvelopedData. Its
774 The EnvelopedData data type is specified in the Cryptographic
775 Message Syntax, a product of the S/MIME working group of the
776 IETF. It contains a temporary key encrypted with the PKINIT
777 client's public key. It also contains a signed and encrypted
780 1. The originatorInfo field is not required, since that
781 information may be presented in the signedData structure
782 that is encrypted within the encryptedContentInfo field.
784 2. The optional unprotectedAttrs field is not required for
787 3. The recipientInfos field is a SET which MUST contain exactly
788 one member of the KeyTransRecipientInfo type for encryption
791 a. The encryptedKey field (in KeyTransRecipientInfo)
792 contains the temporary key which is encrypted with the
793 PKINIT client's public key.
795 4. The encryptedContentInfo field contains the signed and
798 a. The contentType field MUST contain the OID value for
799 id-signedData: iso (1) member-body (2) us (840)
800 rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2)
802 b. The encryptedContent field is encrypted data of the CMS
803 type signedData as specified below.
805 i. The encapContentInfo field MUST contains the
808 * The eContentType field MUST contain the OID value
809 for pkrkeydata: iso (1) org (3) dod (6) internet (1)
810 security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3)
812 * The eContent field is data of the type ReplyKeyPack
815 ii. The certificates field MUST contain the certificates
816 necessary for the client to establish trust in the
817 KDC's certificate based on the list of trusted
818 certifiers sent by the client in the PA-PK-AS-REQ.
819 This field may be empty if the client did not send
820 to the KDC a list of trusted certifiers (the
821 trustedCertifiers field was empty, meaning that the
822 client already possesses the KDC's certificate).
824 iii. The signerInfos field is a SET that MUST contain at
825 least one member, since it contains the actual
828 ReplyKeyPack ::= SEQUENCE {
829 -- not used for Diffie-Hellman
830 replyKey [0] EncryptionKey,
832 -- used to encrypt main reply
833 -- ENCTYPE is at least as strong as
834 -- ENCTYPE of session key
836 -- binds response to the request
837 -- must be same as the nonce
838 -- passed in the PKAuthenticator
842 3.2.2.1. Use of transited Field
844 Since each certifier in the certification path of a user's
845 certificate is equivalent to a separate Kerberos realm, the name
846 of each certifier in the certificate chain MUST be added to the
847 transited field of the ticket. The format of these realm names is
848 defined in Section 3.1 of this document. If applicable, the
849 transit-policy-checked flag should be set in the issued ticket.
852 3.2.2.2. Kerberos Names in Certificates
854 The KDC's certificate(s) MUST bind the public key(s) of the KDC to
855 a name derivable from the name of the realm for that KDC. X.509
856 certificates MUST contain the principal name of the KDC (defined in
857 RFC 1510bis) as the SubjectAltName version 3 extension. Below is
858 the definition of this version 3 extension, as specified by the
861 subjectAltName EXTENSION ::= {
863 IDENTIFIED BY id-ce-subjectAltName
866 GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName
868 GeneralName ::= CHOICE {
869 otherName [0] OtherName,
873 OtherName ::= SEQUENCE {
874 type-id OBJECT IDENTIFIER,
875 value [0] EXPLICIT ANY DEFINED BY type-id
878 For the purpose of specifying a Kerberos principal name, the value
879 in OtherName MUST be a KerberosName, defined as follows:
881 KerberosName ::= SEQUENCE {
883 principalName [1] PrincipalName
886 This specific syntax is identified within subjectAltName by setting
887 the type-id in OtherName to krb5PrincipalName, where (from the
888 Kerberos specification) we have
890 krb5 OBJECT IDENTIFIER ::= { iso (1)
897 krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }
899 (This specification may also be used to specify a Kerberos name
900 within the user's certificate.) The KDC's certificate may be signed
901 directly by a CA, or there may be intermediaries if the server resides
902 within a large organization, or it may be unsigned if the client
903 indicates possession (and trust) of the KDC's certificate.
905 Note that the KDC's principal name has the instance equal to the
906 realm, and those fields should be appropriately set in the realm
907 and principalName fields of the KerberosName. This is the case
908 even when obtaining a cross-realm ticket using PKINIT.
911 3.2.3. Client Extraction of Reply
913 The client then extracts the random key used to encrypt the main
914 reply. This random key (in encPaReply) is encrypted with either the
915 client's public key or with a key derived from the DH values
916 exchanged between the client and the KDC. The client uses this
917 random key to decrypt the main reply, and subsequently proceeds as
918 described in RFC 1510bis.
920 3.2.4. Required Algorithms
922 Not all of the algorithms in the PKINIT protocol specification have
923 to be implemented in order to comply with the proposed standard.
924 Below is a list of the required algorithms:
926 * Diffie-Hellman public/private key pairs
927 * utilizing Diffie-Hellman ephemeral-ephemeral mode
928 * SHA1 digest and DSA for signatures
929 * SHA1 digest for the Checksum in the PKAuthenticator
930 * using Kerberos checksum type 'sha1'
931 * 3-key triple DES keys derived from the Diffie-Hellman Exchange
932 * 3-key triple DES Temporary and Reply keys
934 4. Logistics and Policy
936 This section describes a way to define the policy on the use of
937 PKINIT for each principal and request.
939 The KDC is not required to contain a database record for users
940 who use public key authentication. However, if these users are
941 registered with the KDC, it is recommended that the database record
942 for these users be modified to an additional flag in the attributes
943 field to indicate that the user should authenticate using PKINIT.
944 If this flag is set and a request message does not contain the
945 PKINIT preauthentication field, then the KDC sends back as error of
946 type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication
947 field of type PA-PK-AS-REQ must be included in the request.
949 5. Security Considerations
951 PKINIT raises a few security considerations, which we will address
954 First of all, PKINIT extends the cross-realm model to the public
955 key infrastructure. Anyone using PKINIT must be aware of how the
956 certification infrastructure they are linking to works.
958 Also, as in standard Kerberos, PKINIT presents the possibility of
959 interactions between different cryptosystems of varying strengths,
960 and this now includes public-key cryptosystems. Many systems, for
961 instance, allow the use of 512-bit public keys. Using such keys
962 to wrap data encrypted under strong conventional cryptosystems,
963 such as triple-DES, may be inappropriate.
965 Care should be taken in how certificates are choosen for the purposes
966 of authentication using PKINIT. Some local policies require that key
967 escrow be applied for certain certificate types. People deploying
968 PKINIT should be aware of the implications of using certificates that
969 have escrowed keys for the purposes of authentication.
971 As described in Section 3.2, PKINIT allows for the caching of the
972 Diffie-Hellman parameters on the KDC side, for performance reasons.
973 For similar reasons, the signed data in this case does not vary from
974 message to message, until the cached parameters expire. Because of
975 the persistence of these parameters, the client and the KDC are to
976 use the appropriate key derivation measures (as described in RFC
977 1510bis) when using cached DH parameters.
979 Lastly, PKINIT calls for randomly generated keys for conventional
980 cryptosystems. Many such systems contain systematically "weak"
981 keys. For recommendations regarding these weak keys, see RFC
986 Certificate chains can potentially grow quite large and span several
987 UDP packets; this in turn increases the probability that a Kerberos
988 message involving PKINIT extensions will be broken in transit. In
989 light of the possibility that the Kerberos specification will
990 require KDCs to accept requests using TCP as a transport mechanism,
991 we make the same recommendation with respect to the PKINIT
996 [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service
997 (V5). Request for Comments 1510.
999 [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
1000 for Computer Networks, IEEE Communications, 32(9):33-38. September
1003 [3] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos
1004 Using Public Key Cryptography. Symposium On Network and Distributed
1005 System Security, 1997.
1007 [4] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction
1008 Protocol. In Proceedings of the USENIX Workshop on Electronic
1009 Commerce, July 1995.
1011 [5] T. Dierks, C. Allen. The TLS Protocol, Version 1.0
1012 Request for Comments 2246, January 1999.
1014 [6] B.C. Neuman, Proxy-Based Authorization and Accounting for
1015 Distributed Systems. In Proceedings of the 13th International
1016 Conference on Distributed Computing Systems, May 1993.
1018 [7] ITU-T (formerly CCITT) Information technology - Open Systems
1019 Interconnection - The Directory: Authentication Framework
1020 Recommendation X.509 ISO/IEC 9594-8
1022 [8] R. Housley. Cryptographic Message Syntax.
1023 draft-ietf-smime-cms-13.txt, April 1999, approved for publication
1026 [9] PKCS #7: Cryptographic Message Syntax Standard,
1027 An RSA Laboratories Technical Note Version 1.5
1028 Revised November 1, 1993
1030 [10] R. Rivest, MIT Laboratory for Computer Science and RSA Data
1031 Security, Inc. A Description of the RC2(r) Encryption Algorithm
1033 Request for Comments 2268.
1035 [11] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
1036 Protocol (v3): UTF-8 String Representation of Distinguished Names.
1037 Request for Comments 2253.
1039 [12] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
1040 Key Infrastructure, Certificate and CRL Profile, January 1999.
1041 Request for Comments 2459.
1043 [13] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
1044 Specifications, October 1998. Request for Comments 2437.
1046 [14] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. S/MIME
1047 Version 2 Certificate Handling, March 1998. Request for
1050 [15] M. Wahl, T. Howes, S. Kille. Lightweight Directory Access
1051 Protocol (v3), December 1997. Request for Comments 2251.
1053 [16] ITU-T (formerly CCITT) Information Processing Systems - Open
1054 Systems Interconnection - Specification of Abstract Syntax Notation
1055 One (ASN.1) Rec. X.680 ISO/IEC 8824-1
1057 [17] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA
1058 Laboratories Technical Note, Version 1.4, Revised November 1, 1993.
1062 Some of the ideas on which this proposal is based arose during
1063 discussions over several years between members of the SAAG, the IETF
1064 CAT working group, and the PSRG, regarding integration of Kerberos
1065 and SPX. Some ideas have also been drawn from the DASS system.
1066 These changes are by no means endorsed by these groups. This is an
1067 attempt to revive some of the goals of those groups, and this
1068 proposal approaches those goals primarily from the Kerberos
1069 perspective. Lastly, comments from groups working on similar ideas
1070 in DCE have been invaluable.
1074 This draft expires May 25, 2002.
1080 USC Information Sciences Institute
1081 4676 Admiralty Way Suite 1001
1082 Marina del Rey CA 90292-6695
1083 Phone: +1 310 822 1511
1084 E-mail: {brian, bcn}@isi.edu
1090 Phone: (206) 256-3197
1091 E-Mail: mhur@cisco.com
1095 150 Independence Drive
1097 Phone: +1 650 289 3134
1098 E-mail: ari@keen.com
1105 E-mail: smedvinsky@gi.com
1108 Iris Associates, Inc.
1109 5 Technology Park Dr.
1111 E-mail: John_Wray@iris.com
1117 E-mail: jtrostle@cisco.com