1 INTERNET-DRAFT Brian Tung
2 draft-ietf-cat-kerberos-pk-init-12.txt Clifford Neuman
3 Updates: RFC 1510 USC/ISI
4 expires January 15, 2001 Matthew Hur
15 Public Key Cryptography for Initial Authentication in Kerberos
17 0. Status Of This Memo
19 This document is an Internet-Draft and is in full conformance with
20 all provisions of Section 10 of RFC 2026. Internet-Drafts are
21 working documents of the Internet Engineering Task Force (IETF),
22 its areas, and its working groups. Note that other groups may also
23 distribute working documents as Internet-Drafts.
25 Internet-Drafts are draft documents valid for a maximum of six
26 months and may be updated, replaced, or obsoleted by other
27 documents at any time. It is inappropriate to use Internet-Drafts
28 as reference material or to cite them other than as "work in
31 The list of current Internet-Drafts can be accessed at
32 http://www.ietf.org/ietf/1id-abstracts.txt
34 The list of Internet-Draft Shadow Directories can be accessed at
35 http://www.ietf.org/shadow.html.
37 To learn the current status of any Internet-Draft, please check
38 the "1id-abstracts.txt" listing contained in the Internet-Drafts
39 Shadow Directories on ftp.ietf.org (US East Coast),
40 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
41 munnari.oz.au (Pacific Rim).
43 The distribution of this memo is unlimited. It is filed as
44 draft-ietf-cat-kerberos-pk-init-11.txt, and expires January 15,
45 2001. Please send comments to the authors.
49 This document defines extensions (PKINIT) to the Kerberos protocol
50 specification (RFC 1510 [1]) to provide a method for using public
51 key cryptography during initial authentication. The methods
52 defined specify the ways in which preauthentication data fields and
53 error data fields in Kerberos messages are to be used to transport
58 The popularity of public key cryptography has produced a desire for
59 its support in Kerberos [2]. The advantages provided by public key
60 cryptography include simplified key management (from the Kerberos
61 perspective) and the ability to leverage existing and developing
62 public key certification infrastructures.
64 Public key cryptography can be integrated into Kerberos in a number
65 of ways. One is to associate a key pair with each realm, which can
66 then be used to facilitate cross-realm authentication; this is the
67 topic of another draft proposal. Another way is to allow users with
68 public key certificates to use them in initial authentication. This
69 is the concern of the current document.
71 PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in
72 combination with digital signature keys as the primary, required
73 mechanism. It also allows for the use of RSA keys and/or (static)
74 Diffie-Hellman certificates. Note in particular that PKINIT supports
75 the use of separate signature and encryption keys.
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 secret key, a public key, or both.
98 The PKINIT specification may also be used as a building block for
99 other specifications. PKCROSS [3] utilizes PKINIT for establishing
100 the inter-realm key and associated inter-realm policy to be applied
101 in issuing cross realm service tickets. As specified in [4],
102 anonymous Kerberos tickets can be issued by applying a NULL
103 signature in combination with Diffie-Hellman in the PKINIT exchange.
104 Additionally, the PKINIT specification may be used for direct peer
105 to peer authentication without contacting a central KDC. This
106 application of PKINIT is described in PKTAPP [5] and is based on
107 concepts introduced in [6, 7]. For direct client-to-server
108 authentication, the client uses PKINIT to authenticate to the end
109 server (instead of a central KDC), which then issues a ticket for
110 itself. This approach has an advantage over TLS [8] in that the
111 server does not need to save state (cache session keys).
112 Furthermore, an additional benefit is that Kerberos tickets can
113 facilitate delegation (see [9]).
115 3. Proposed Extensions
117 This section describes extensions to RFC 1510 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 1510 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).
182 In many cases, PKINIT requires the encoding of the X.500 name of a
183 certificate authority as a Realm. When such a name appears as
184 a realm it will be represented using the "other" form of the realm
185 name as specified in the naming constraints section of RFC1510.
186 For a realm derived from an X.500 name, NAMETYPE will have the value
187 X500-RFC2253. The full realm name will appear as follows:
189 <nametype> + ":" + <string>
191 where nametype is "X500-RFC2253" and string is the result of doing
192 an RFC2253 encoding of the distinguished name, i.e.
194 "X500-RFC2253:" + RFC2253Encode(DistinguishedName)
196 where DistinguishedName is an X.500 name, and RFC2253Encode is a
197 function returing a readable UTF encoding of an X.500 name, as
198 defined by RFC 2253 [14] (part of LDAPv3 [18]).
200 To ensure that this encoding is unique, we add the following rule
201 to those specified by RFC 2253:
203 The order in which the attributes appear in the RFC 2253
204 encoding must be the reverse of the order in the ASN.1
205 encoding of the X.500 name that appears in the public key
206 certificate. The order of the relative distinguished names
207 (RDNs), as well as the order of the AttributeTypeAndValues
208 within each RDN, will be reversed. (This is despite the fact
209 that an RDN is defined as a SET of AttributeTypeAndValues, where
210 an order is normally not important.)
212 Similarly, in cases where the KDC does not provide a specific
213 policy based mapping from the X.500 name or X.509 Version 3
214 SubjectAltName extension in the user's certificate to a Kerberos
215 principal name, PKINIT requires the direct encoding of the X.500
216 name as a PrincipalName. In this case, the name-type of the
217 principal name shall be set to KRB_NT-X500-PRINCIPAL. This new
218 name type is defined in RFC 1510 as:
220 KRB_NT_X500_PRINCIPAL 6
222 The name-string shall be set as follows:
224 RFC2253Encode(DistinguishedName)
226 as described above. When this name type is used, the principal's
227 realm shall be set to the certificate authority's distinguished
228 name using the X500-RFC2253 realm name format described earlier in
231 RFC 1510 specifies the ASN.1 structure for PrincipalName as follows:
233 PrincipalName ::= SEQUENCE {
234 name-type[0] INTEGER,
235 name-string[1] SEQUENCE OF GeneralString
238 For the purposes of encoding an X.500 name as a Kerberos name for
239 use in Kerberos structures, the name-string shall be encoded as a
240 single GeneralString. The name-type should be KRB_NT_X500_PRINCIPAL,
241 as noted above. All Kerberos names must conform to validity
242 requirements as given in RFC 1510. Note that name mapping may be
243 required or optional, based on policy.
245 We also define the following similar ASN.1 structure:
247 CertPrincipalName ::= SEQUENCE {
248 name-type[0] INTEGER,
249 name-string[1] SEQUENCE OF UTF8String
252 When a Kerberos PrincipalName is to be placed within an X.509 data
253 structure, the CertPrincipalName structure is to be used, with the
254 name-string encoded as a single UTF8String. The name-type should be
255 as identified in the original PrincipalName structure. The mapping
256 between the GeneralString and UTF8String formats can be found in
259 The following rules relate to the the matching of PrincipalNames (or
260 corresponding CertPrincipalNames) with regard to the PKI name
261 constraints for CAs as laid out in RFC 2459 [15]. In order to be
262 regarded as a match (for permitted and excluded name trees), the
263 following must be satisfied.
265 1. If the constraint is given as a user plus realm name, or
266 as a user plus instance plus realm name (as specified in
267 RFC 1510), the realm name must be valid (see 2.a-d below)
268 and the match must be exact, byte for byte.
270 2. If the constraint is given only as a realm name, matching
271 depends on the type of the realm:
273 a. If the realm contains a colon (':') before any equal
274 sign ('='), it is treated as a realm of type Other,
275 and must match exactly, byte for byte.
277 b. Otherwise, if the realm contains an equal sign, it
278 is treated as an X.500 name. In order to match, every
279 component in the constraint MUST be in the principal
280 name, and have the same value. For example, 'C=US'
281 matches 'C=US/O=ISI' but not 'C=UK'.
283 c. Otherwise, if the realm name conforms to rules regarding
284 the format of DNS names, it is considered a realm name of
285 type Domain. The constraint may be given as a realm
286 name 'FOO.BAR', which matches any PrincipalName within
287 the realm 'FOO.BAR' but not those in subrealms such as
288 'CAR.FOO.BAR'. A constraint of the form '.FOO.BAR'
289 matches PrincipalNames in subrealms of the form
290 'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself.
292 d. Otherwise, the realm name is invalid and does not match
293 under any conditions.
295 3.1.1. Encryption and Key Formats
297 In the exposition below, we use the terms public key and private
298 key generically. It should be understood that the term "public
299 key" may be used to refer to either a public encryption key or a
300 signature verification key, and that the term "private key" may be
301 used to refer to either a private decryption key or a signature
302 generation key. The fact that these are logically distinct does
303 not preclude the assignment of bitwise identical keys for RSA
306 In the case of Diffie-Hellman, the key shall be produced from the
307 agreed bit string as follows:
309 * Truncate the bit string to the appropriate length.
310 * Rectify parity in each byte (if necessary) to obtain the key.
312 For instance, in the case of a DES key, we take the first eight
313 bytes of the bit stream, and then adjust the least significant bit
314 of each byte to ensure that each byte has odd parity.
316 3.1.2. Algorithm Identifiers
318 PKINIT does not define, but does permit, the algorithm identifiers
321 3.1.2.1. Signature Algorithm Identifiers
323 The following signature algorithm identifiers specified in [11] and
324 in [15] shall be used with PKINIT:
326 id-dsa-with-sha1 (DSA with SHA1)
327 md5WithRSAEncryption (RSA with MD5)
328 sha-1WithRSAEncryption (RSA with SHA1)
330 3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier
332 The following algorithm identifier shall be used within the
333 SubjectPublicKeyInfo data structure: dhpublicnumber
335 This identifier and the associated algorithm parameters are
336 specified in RFC 2459 [15].
338 3.1.2.3. Algorithm Identifiers for RSA Encryption
340 These algorithm identifiers are used inside the EnvelopedData data
341 structure, for encrypting the temporary key with a public key:
343 rsaEncryption (RSA encryption, PKCS#1 v1.5)
344 id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0)
346 Both of the above RSA encryption schemes are specified in [16].
347 Currently, only PKCS#1 v1.5 is specified by CMS [11], although the
348 CMS specification says that it will likely include PKCS#1 v2.0 in
349 the future. (PKCS#1 v2.0 addresses adaptive chosen ciphertext
350 vulnerability discovered in PKCS#1 v1.5.)
352 3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys
354 These algorithm identifiers are used inside the EnvelopedData data
355 structure in the PKINIT Reply, for encrypting the reply key with the
357 des-ede3-cbc (3-key 3-DES, CBC mode)
358 rc2-cbc (RC2, CBC mode)
360 The full definition of the above algorithm identifiers and their
361 corresponding parameters (an IV for block chaining) is provided in
362 the CMS specification [11].
364 3.2. Public Key Authentication
366 Implementation of the changes in this section is REQUIRED for
367 compliance with PKINIT.
369 3.2.1. Client Request
371 Public keys may be signed by some certification authority (CA), or
372 they may be maintained by the KDC in which case the KDC is the
373 trusted authority. Note that the latter mode does not require the
376 The initial authentication request is sent as per RFC 1510, except
377 that a preauthentication field containing data signed by the user's
378 private key accompanies the request:
380 PA-PK-AS-REQ ::= SEQUENCE {
382 signedAuthPack [0] SignedData
383 -- Defined in CMS [11];
384 -- AuthPack (below) defines the
385 -- data that is signed.
386 trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL,
387 -- This is a list of CAs that the
388 -- client trusts and that certify
390 kdcCert [2] IssuerAndSerialNumber OPTIONAL
391 -- As defined in CMS [11];
392 -- specifies a particular KDC
393 -- certificate if the client
395 encryptionCert [3] IssuerAndSerialNumber OPTIONAL
396 -- For example, this may be the
397 -- client's Diffie-Hellman
398 -- certificate, or it may be the
399 -- client's RSA encryption
403 TrustedCas ::= CHOICE {
404 principalName [0] KerberosName,
407 -- fully qualified X.500 name
408 -- as defined by X.509
409 issuerAndSerial [2] IssuerAndSerialNumber
410 -- Since a CA may have a number of
411 -- certificates, only one of which
417 The SignedData data type is specified in the Cryptographic
418 Message Syntax, a product of the S/MIME working group of the
419 IETF. The following describes how to fill in the fields of
422 1. The encapContentInfo field must contain the PKAuthenticator
423 and, optionally, the client's Diffie Hellman public value.
425 a. The eContentType field shall contain the OID value for
426 pkauthdata: iso (1) org (3) dod (6) internet (1)
427 security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)
429 b. The eContent field is data of the type AuthPack (below).
431 2. The signerInfos field contains the signature of AuthPack.
433 3. The Certificates field, when non-empty, contains the client's
434 certificate chain. If present, the KDC uses the public key
435 from the client's certificate to verify the signature in the
436 request. Note that the client may pass different certificate
437 chains that are used for signing or for encrypting. Thus,
438 the KDC may utilize a different client certificate for
439 signature verification than the one it uses to encrypt the
440 reply to the client. For example, the client may place a
441 Diffie-Hellman certificate in this field in order to convey
442 its static Diffie Hellman certificate to the KDC to enable
443 static-ephemeral Diffie-Hellman mode for the reply; in this
444 case, the client does NOT place its public value in the
445 AuthPack (defined below). As another example, the client may
446 place an RSA encryption certificate in this field. However,
447 there must always be (at least) a signature certificate.
449 AuthPack ::= SEQUENCE {
450 pkAuthenticator [0] PKAuthenticator,
451 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL
452 -- if client is using Diffie-Hellman
453 -- (ephemeral-ephemeral only)
456 PKAuthenticator ::= SEQUENCE {
458 -- for replay prevention as in RFC1510
459 ctime [1] KerberosTime,
460 -- for replay prevention as in RFC1510
462 pachecksum [3] Checksum
463 -- Checksum over KDC-REQ-BODY
464 -- Defined by Kerberos spec
467 SubjectPublicKeyInfo ::= SEQUENCE {
468 algorithm AlgorithmIdentifier,
470 subjectPublicKey BIT STRING
472 -- public exponent (INTEGER encoded
473 -- as payload of BIT STRING)
474 } -- as specified by the X.509 recommendation [10]
476 AlgorithmIdentifier ::= SEQUENCE {
477 algorithm OBJECT IDENTIFIER,
478 -- for dhKeyAgreement, this is
479 -- { iso (1) member-body (2) US (840)
480 -- rsadsi (113459) pkcs (1) 3 1 }
482 parameters ANY DEFINED by algorithm OPTIONAL
483 -- for dhKeyAgreement, this is
485 } -- as specified by the X.509 recommendation [10]
487 DHParameter ::= SEQUENCE {
492 privateValueLength INTEGER OPTIONAL
494 } -- as defined in PKCS #3 [20]
496 If the client passes an issuer and serial number in the request,
497 the KDC is requested to use the referred-to certificate. If none
498 exists, then the KDC returns an error of type
499 KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the
500 other hand, the client does not pass any trustedCertifiers,
501 believing that it has the KDC's certificate, but the KDC has more
502 than one certificate. The KDC should include information in the
503 KRB-ERROR message that indicates the KDC certificate(s) that a
504 client may utilize. This data is specified in the e-data, which
505 is defined in RFC 1510 revisions as a SEQUENCE of TypedData:
507 TypedData ::= SEQUENCE {
508 data-type [0] INTEGER,
509 data-value [1] OCTET STRING,
510 } -- per Kerberos RFC 1510 revisions
513 data-type = TD-PKINIT-CMS-CERTIFICATES = 101
514 data-value = CertificateSet // as specified by CMS [11]
516 The PKAuthenticator carries information to foil replay attacks, to
517 bind the pre-authentication data to the KDC-REQ-BODY, and to bind the
518 request and response. The PKAuthenticator is signed with the client's
523 Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
524 type, the KDC attempts to verify the user's certificate chain
525 (userCert), if one is provided in the request. This is done by
526 verifying the certification path against the KDC's policy of
527 legitimate certifiers. This may be based on a certification
528 hierarchy, or it may be simply a list of recognized certifiers in a
531 If the client's certificate chain contains no certificate signed by
532 a CA trusted by the KDC, then the KDC sends back an error message
533 of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data
534 is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104)
535 whose data-value is an OCTET STRING which is the DER encoding of
537 TrustedCertifiers ::= SEQUENCE OF PrincipalName
538 -- X.500 name encoded as a principal name
541 If while verifying a certificate chain the KDC determines that the
542 signature on one of the certificates in the CertificateSet from
543 the signedAuthPack fails verification, then the KDC returns an
544 error of type KDC_ERR_INVALID_CERTIFICATE. The accompanying
545 e-data is a SEQUENCE of one TypedData (with type
546 TD-CERTIFICATE-INDEX=105) whose data-value is an OCTET STRING
547 which is the DER encoding of the index into the CertificateSet
548 ordered as sent by the client.
550 CertificateIndex ::= INTEGER
551 -- 0 = 1st certificate,
552 -- (in order of encoding)
553 -- 1 = 2nd certificate, etc
555 The KDC may also check whether any of the certificates in the
556 client's chain has been revoked. If one of the certificates has
557 been revoked, then the KDC returns an error of type
558 KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that
559 the certificate's revocation status is unknown or not
560 available, then if required by policy, the KDC returns the
561 appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or
562 KDC_ERR_REVOCATION_STATUS_UNAVAILABLE. In any of these three
563 cases, the affected certificate is identified by the accompanying
564 e-data, which contains a CertificateIndex as described for
565 KDC_ERR_INVALID_CERTIFICATE.
567 If the certificate chain can be verified, but the name of the
568 client in the certificate does not match the client's name in the
569 request, then the KDC returns an error of type
570 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data
573 Finally, if the certificate chain is verified, but the KDC's name
574 or realm as given in the PKAuthenticator does not match the KDC's
575 actual principal name, then the KDC returns an error of type
576 KDC_ERR_KDC_NAME_MISMATCH. The accompanying e-data field is again
577 a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or
578 TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET
579 STRING whose data-value is the DER encoding of a PrincipalName or
580 Realm as defined in RFC 1510 revisions.
582 Even if all succeeds, the KDC may--for policy reasons--decide not
583 to trust the client. In this case, the KDC returns an error message
584 of type KDC_ERR_CLIENT_NOT_TRUSTED. One specific case of this is
585 the presence or absence of an Enhanced Key Usage (EKU) OID within
586 the certificate extensions. The rules regarding acceptability of
587 an EKU sequence (or the absence of any sequence) are a matter of
588 local policy. For the benefit of implementers, we define a PKINIT
589 EKU OID as the following: iso (1) org (3) dod (6) internet (1)
590 security (5) kerberosv5 (2) pkinit (3) pkekuoid (2).
592 If a trust relationship exists, the KDC then verifies the client's
593 signature on AuthPack. If that fails, the KDC returns an error
594 message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the
595 timestamp (ctime and cusec) in the PKAuthenticator to assure that
596 the request is not a replay. The KDC also verifies that its name
597 is specified in the PKAuthenticator.
599 If the clientPublicValue field is filled in, indicating that the
600 client wishes to use Diffie-Hellman key agreement, then the KDC
601 checks to see that the parameters satisfy its policy. If they do
602 not (e.g., the prime size is insufficient for the expected
603 encryption type), then the KDC sends back an error message of type
604 KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and
605 private values for the response.
607 The KDC also checks that the timestamp in the PKAuthenticator is
608 within the allowable window and that the principal name and realm
609 are correct. If the local (server) time and the client time in the
610 authenticator differ by more than the allowable clock skew, then the
611 KDC returns an error message of type KRB_AP_ERR_SKEW as defined in 1510.
613 Assuming no errors, the KDC replies as per RFC 1510, except as
614 follows. The user's name in the ticket is determined by the
615 following decision algorithm:
617 1. If the KDC has a mapping from the name in the certificate
618 to a Kerberos name, then use that name.
620 2. If the certificate contains the SubjectAltName extention
621 and the local KDC policy defines a mapping from the
622 SubjectAltName to a Kerberos name, then use that name.
624 3. Use the name as represented in the certificate, mapping
625 mapping as necessary (e.g., as per RFC 2253 for X.500
626 names). In this case the realm in the ticket shall be the
627 name of the certifier that issued the user's certificate.
629 Note that a principal name may be carried in the subject alt name
630 field of a certificate. This name may be mapped to a principal
631 record in a security database based on local policy, for example
632 the subject alt name may be kerberos/principal@realm format. In
633 this case the realm name is not that of the CA but that of the
634 local realm doing the mapping (or some realm name chosen by that
637 If a non-KDC X.509 certificate contains the principal name within
638 the subjectAltName version 3 extension , that name may utilize
639 KerberosName as defined below, or, in the case of an S/MIME
640 certificate [17], may utilize the email address. If the KDC
641 is presented with an S/MIME certificate, then the email address
642 within subjectAltName will be interpreted as a principal and realm
643 separated by the "@" sign, or as a name that needs to be
644 canonicalized. If the resulting name does not correspond to a
645 registered principal name, then the principal name is formed as
646 defined in section 3.1.
648 The trustedCertifiers field contains a list of certification
649 authorities trusted by the client, in the case that the client does
650 not possess the KDC's public key certificate. If the KDC has no
651 certificate signed by any of the trustedCertifiers, then it returns
652 an error of type KDC_ERR_KDC_NOT_TRUSTED.
654 KDCs should try to (in order of preference):
655 1. Use the KDC certificate identified by the serialNumber included
656 in the client's request.
657 2. Use a certificate issued to the KDC by the client's CA (if in the
658 middle of a CA key roll-over, use the KDC cert issued under same
659 CA key as user cert used to verify request).
660 3. Use a certificate issued to the KDC by one of the client's
662 If the KDC is unable to comply with any of these options, then the
663 KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the
666 The KDC encrypts the reply not with the user's long-term key, but
667 with the Diffie Hellman derived key or a random key generated
668 for this particular response which is carried in the padata field of
671 PA-PK-AS-REP ::= CHOICE {
673 dhSignedData [0] SignedData,
674 -- Defined in CMS and used only with
675 -- Diffie-Hellman key exchange (if the
676 -- client public value was present in the
678 -- This choice MUST be supported
679 -- by compliant implementations.
680 encKeyPack [1] EnvelopedData,
682 -- The temporary key is encrypted
683 -- using the client public key
685 -- SignedReplyKeyPack, encrypted
686 -- with the temporary key, is also
692 When the Diffie-Hellman option is used, dhSignedData in
693 PA-PK-AS-REP provides authenticated Diffie-Hellman parameters
694 of the KDC. The reply key used to encrypt part of the KDC reply
695 message is derived from the Diffie-Hellman exchange:
697 1. Both the KDC and the client calculate a secret value
698 (g^ab mod p), where a is the client's private exponent and
699 b is the KDC's private exponent.
701 2. Both the KDC and the client take the first N bits of this
702 secret value and convert it into a reply key. N depends on
705 3. If the reply key is DES, N=64 bits, where some of the bits
706 are replaced with parity bits, according to FIPS PUB 74.
708 4. If the reply key is (3-key) 3-DES, N=192 bits, where some
709 of the bits are replaced with parity bits, according to
712 5. The encapContentInfo field must contain the KdcDHKeyInfo as
715 a. The eContentType field shall contain the OID value for
716 pkdhkeydata: iso (1) org (3) dod (6) internet (1)
717 security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2)
719 b. The eContent field is data of the type KdcDHKeyInfo
722 6. The certificates field must contain the certificates
723 necessary for the client to establish trust in the KDC's
724 certificate based on the list of trusted certifiers sent by
725 the client in the PA-PK-AS-REQ. This field may be empty if
726 the client did not send to the KDC a list of trusted
727 certifiers (the trustedCertifiers field was empty, meaning
728 that the client already possesses the KDC's certificate).
730 7. The signerInfos field is a SET that must contain at least
731 one member, since it contains the actual signature.
733 KdcDHKeyInfo ::= SEQUENCE {
734 -- used only when utilizing Diffie-Hellman
736 -- binds responce to the request
737 subjectPublicKey [2] BIT STRING
738 -- Equals public exponent (g^a mod p)
739 -- INTEGER encoded as payload of
743 Usage of EnvelopedData:
745 The EnvelopedData data type is specified in the Cryptographic
746 Message Syntax, a product of the S/MIME working group of the
747 IETF. It contains a temporary key encrypted with the PKINIT
748 client's public key. It also contains a signed and encrypted
751 1. The originatorInfo field is not required, since that
752 information may be presented in the signedData structure
753 that is encrypted within the encryptedContentInfo field.
755 2. The optional unprotectedAttrs field is not required for
758 3. The recipientInfos field is a SET which must contain exactly
759 one member of the KeyTransRecipientInfo type for encryption
760 with an RSA public key.
762 a. The encryptedKey field (in KeyTransRecipientInfo)
763 contains the temporary key which is encrypted with the
764 PKINIT client's public key.
766 4. The encryptedContentInfo field contains the signed and
769 a. The contentType field shall contain the OID value for
770 id-signedData: iso (1) member-body (2) us (840)
771 rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2)
773 b. The encryptedContent field is encrypted data of the CMS
774 type signedData as specified below.
776 i. The encapContentInfo field must contains the
779 * The eContentType field shall contain the OID value
780 for pkrkeydata: iso (1) org (3) dod (6) internet (1)
781 security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3)
783 * The eContent field is data of the type ReplyKeyPack
786 ii. The certificates field must contain the certificates
787 necessary for the client to establish trust in the
788 KDC's certificate based on the list of trusted
789 certifiers sent by the client in the PA-PK-AS-REQ.
790 This field may be empty if the client did not send
791 to the KDC a list of trusted certifiers (the
792 trustedCertifiers field was empty, meaning that the
793 client already possesses the KDC's certificate).
795 iii. The signerInfos field is a SET that must contain at
796 least one member, since it contains the actual
799 ReplyKeyPack ::= SEQUENCE {
800 -- not used for Diffie-Hellman
801 replyKey [0] EncryptionKey,
802 -- used to encrypt main reply
803 -- ENCTYPE is at least as strong as
804 -- ENCTYPE of session key
806 -- binds response to the request
807 -- must be same as the nonce
808 -- passed in the PKAuthenticator
811 Since each certifier in the certification path of a user's
812 certificate is equivalent to a separate Kerberos realm, the name
813 of each certifier in the certificate chain must be added to the
814 transited field of the ticket. The format of these realm names is
815 defined in Section 3.1 of this document. If applicable, the
816 transit-policy-checked flag should be set in the issued ticket.
818 The KDC's certificate(s) must bind the public key(s) of the KDC to
819 a name derivable from the name of the realm for that KDC. X.509
820 certificates shall contain the principal name of the KDC
821 (defined in section 8.2 of RFC 1510) as the SubjectAltName version
822 3 extension. Below is the definition of this version 3 extension,
823 as specified by the X.509 standard:
825 subjectAltName EXTENSION ::= {
827 IDENTIFIED BY id-ce-subjectAltName
830 GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName
832 GeneralName ::= CHOICE {
833 otherName [0] OtherName,
837 OtherName ::= SEQUENCE {
838 type-id OBJECT IDENTIFIER,
839 value [0] EXPLICIT ANY DEFINED BY type-id
842 For the purpose of specifying a Kerberos principal name, the value
843 in OtherName shall be a KerberosName as defined in RFC 1510, but with
844 the PrincipalName replaced by CertPrincipalName as mentioned in
847 KerberosName ::= SEQUENCE {
849 principalName [1] CertPrincipalName -- defined above
852 This specific syntax is identified within subjectAltName by setting
853 the type-id in OtherName to krb5PrincipalName, where (from the
854 Kerberos specification) we have
856 krb5 OBJECT IDENTIFIER ::= { iso (1)
863 krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }
865 (This specification may also be used to specify a Kerberos name
866 within the user's certificate.) The KDC's certificate may be signed
867 directly by a CA, or there may be intermediaries if the server resides
868 within a large organization, or it may be unsigned if the client
869 indicates possession (and trust) of the KDC's certificate.
871 The client then extracts the random key used to encrypt the main
872 reply. This random key (in encPaReply) is encrypted with either the
873 client's public key or with a key derived from the DH values
874 exchanged between the client and the KDC. The client uses this
875 random key to decrypt the main reply, and subsequently proceeds as
876 described in RFC 1510.
878 3.2.3. Required Algorithms
880 Not all of the algorithms in the PKINIT protocol specification have
881 to be implemented in order to comply with the proposed standard.
882 Below is a list of the required algorithms:
884 * Diffie-Hellman public/private key pairs
885 * utilizing Diffie-Hellman ephemeral-ephemeral mode
886 * SHA1 digest and DSA for signatures
887 * SHA1 digest also for the Checksum in the PKAuthenticator
888 * 3-key triple DES keys derived from the Diffie-Hellman Exchange
889 * 3-key triple DES Temporary and Reply keys
891 4. Logistics and Policy
893 This section describes a way to define the policy on the use of
894 PKINIT for each principal and request.
896 The KDC is not required to contain a database record for users
897 who use public key authentication. However, if these users are
898 registered with the KDC, it is recommended that the database record
899 for these users be modified to an additional flag in the attributes
900 field to indicate that the user should authenticate using PKINIT.
901 If this flag is set and a request message does not contain the
902 PKINIT preauthentication field, then the KDC sends back as error of
903 type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication
904 field of type PA-PK-AS-REQ must be included in the request.
906 5. Security Considerations
908 PKINIT raises a few security considerations, which we will address
911 First of all, PKINIT introduces a new trust model, where KDCs do not
912 (necessarily) certify the identity of those for whom they issue
913 tickets. PKINIT does allow KDCs to act as their own CAs, in the
914 limited capacity of self-signing their certificates, but one of the
915 additional benefits is to align Kerberos authentication with a global
916 public key infrastructure. Anyone using PKINIT in this way must be
917 aware of how the certification infrastructure they are linking to
920 Secondly, PKINIT also introduces the possibility of interactions
921 between different cryptosystems, which may be of widely varying
922 strengths. Many systems, for instance, allow the use of 512-bit
923 public keys. Using such keys to wrap data encrypted under strong
924 conventional cryptosystems, such as triple-DES, is inappropriate;
925 it adds a weak link to a strong one at extra cost. Implementors
926 and administrators should take care to avoid such wasteful and
927 deceptive interactions.
929 Lastly, PKINIT calls for randomly generated keys for conventional
930 cryptosystems. Many such systems contain systematically "weak"
931 keys. PKINIT implementations MUST avoid use of these keys, either
932 by discarding those keys when they are generated, or by fixing them
933 in some way (e.g., by XORing them with a given mask). These
934 precautions vary from system to system; it is not our intention to
935 give an explicit recipe for them here.
939 Certificate chains can potentially grow quite large and span several
940 UDP packets; this in turn increases the probability that a Kerberos
941 message involving PKINIT extensions will be broken in transit. In
942 light of the possibility that the Kerberos specification will
943 require KDCs to accept requests using TCP as a transport mechanism,
944 we make the same recommendation with respect to the PKINIT
949 [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service
950 (V5). Request for Comments 1510.
952 [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
953 for Computer Networks, IEEE Communications, 32(9):33-38. September
956 [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld,
957 A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm
958 Authentication in Kerberos. draft-ietf-cat-kerberos-pk-cross-04.txt
960 [4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in
961 Kerberos. draft-ietf-cat-kerberos-anoncred-00.txt
963 [5] Ari Medvinsky, M. Hur, Alexander Medvinsky, B. Clifford Neuman.
964 Public Key Utilizing Tickets for Application Servers (PKTAPP).
965 draft-ietf-cat-pktapp-02.txt
967 [6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos
968 Using Public Key Cryptography. Symposium On Network and Distributed
969 System Security, 1997.
971 [7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction
972 Protocol. In Proceedings of the USENIX Workshop on Electronic
975 [8] T. Dierks, C. Allen. The TLS Protocol, Version 1.0
976 Request for Comments 2246, January 1999.
978 [9] B.C. Neuman, Proxy-Based Authorization and Accounting for
979 Distributed Systems. In Proceedings of the 13th International
980 Conference on Distributed Computing Systems, May 1993.
982 [10] ITU-T (formerly CCITT) Information technology - Open Systems
983 Interconnection - The Directory: Authentication Framework
984 Recommendation X.509 ISO/IEC 9594-8
986 [11] R. Housley. Cryptographic Message Syntax.
987 draft-ietf-smime-cms-13.txt, April 1999, approved for publication
990 [12] PKCS #7: Cryptographic Message Syntax Standard,
991 An RSA Laboratories Technical Note Version 1.5
992 Revised November 1, 1993
994 [13] R. Rivest, MIT Laboratory for Computer Science and RSA Data
995 Security, Inc. A Description of the RC2(r) Encryption Algorithm
997 Request for Comments 2268.
999 [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
1000 Protocol (v3): UTF-8 String Representation of Distinguished Names.
1001 Request for Comments 2253.
1003 [15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
1004 Key Infrastructure, Certificate and CRL Profile, January 1999.
1005 Request for Comments 2459.
1007 [16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
1008 Specifications, October 1998. Request for Comments 2437.
1010 [17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. S/MIME
1011 Version 2 Certificate Handling, March 1998. Request for
1014 [18] M. Wahl, T. Howes, S. Kille. Lightweight Directory Access
1015 Protocol (v3), December 1997. Request for Comments 2251.
1017 [19] ITU-T (formerly CCITT) Information Processing Systems - Open
1018 Systems Interconnection - Specification of Abstract Syntax Notation
1019 One (ASN.1) Rec. X.680 ISO/IEC 8824-1
1021 [20] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA
1022 Laboratories Technical Note, Version 1.4, Revised November 1, 1993.
1026 Some of the ideas on which this proposal is based arose during
1027 discussions over several years between members of the SAAG, the IETF
1028 CAT working group, and the PSRG, regarding integration of Kerberos
1029 and SPX. Some ideas have also been drawn from the DASS system.
1030 These changes are by no means endorsed by these groups. This is an
1031 attempt to revive some of the goals of those groups, and this
1032 proposal approaches those goals primarily from the Kerberos
1033 perspective. Lastly, comments from groups working on similar ideas
1034 in DCE have been invaluable.
1038 This draft expires January 15, 2001.
1044 USC Information Sciences Institute
1045 4676 Admiralty Way Suite 1001
1046 Marina del Rey CA 90292-6695
1047 Phone: +1 310 822 1511
1048 E-mail: {brian, bcn}@isi.edu
1051 CyberSafe Corporation
1052 1605 NW Sammamish Road
1053 Issaquah WA 98027-5378
1054 Phone: +1 425 391 6000
1055 E-mail: matt.hur@cybersafe.com
1059 150 Independence Drive
1061 Phone: +1 650 289 3134
1062 E-mail: ari@keen.com
1069 E-mail: smedvinsky@gi.com
1072 Iris Associates, Inc.
1073 5 Technology Park Dr.
1075 E-mail: John_Wray@iris.com
1080 E-mail: jtrostle@cisco.com