1 INTERNET-DRAFT Brian Tung
2 draft-ietf-cat-kerberos-pk-init-06.txt Clifford Neuman
4 expires September 15, 1998 John Wray
5 Digital Equipment Corporation
13 Public Key Cryptography for Initial Authentication in Kerberos
16 0. Status Of This Memo
18 This document is an Internet-Draft. Internet-Drafts are working
19 documents of the Internet Engineering Task Force (IETF), its
20 areas, and its working groups. Note that other groups may also
21 distribute working documents as Internet-Drafts.
23 Internet-Drafts are draft documents valid for a maximum of six
24 months and may be updated, replaced, or obsoleted by other
25 documents at any time. It is inappropriate to use Internet-Drafts
26 as reference material or to cite them other than as "work in
29 To learn the current status of any Internet-Draft, please check
30 the "1id-abstracts.txt" listing contained in the Internet-Drafts
31 Shadow Directories on ds.internic.net (US East Coast),
32 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
33 munnari.oz.au (Pacific Rim).
35 The distribution of this memo is unlimited. It is filed as
36 draft-ietf-cat-kerberos-pk-init-05.txt, and expires September 15,
37 1998. Please send comments to the authors.
42 This document defines extensions (PKINIT) to the Kerberos protocol
43 specification (RFC 1510 [1]) to provide a method for using public
44 key cryptography during initial authentication. The methods
45 defined specify the ways in which preauthentication data fields and
46 error data fields in Kerberos messages are to be used to transport
52 The popularity of public key cryptography has produced a desire for
53 its support in Kerberos [2]. The advantages provided by public key
54 cryptography include simplified key management (from the Kerberos
55 perspective) and the ability to leverage existing and developing
56 public key certification infrastructures.
58 Public key cryptography can be integrated into Kerberos in a number
59 of ways. One is to associate a key pair with each realm, which can
60 then be used to facilitate cross-realm authentication; this is the
61 topic of another draft proposal. Another way is to allow users with
62 public key certificates to use them in initial authentication. This
63 is the concern of the current document.
65 One of the guiding principles in the design of PKINIT is that
66 changes should be as minimal as possible. As a result, the basic
67 mechanism of PKINIT is as follows: The user sends a request to the
68 KDC as before, except that if that user is to use public key
69 cryptography in the initial authentication step, his certificate
70 accompanies the initial request, in the preauthentication fields.
72 Upon receipt of this request, the KDC verifies the certificate and
73 issues a ticket granting ticket (TGT) as before, except that
74 the encPart from the AS-REP message carrying the TGT is now
75 encrypted in a randomly-generated key, instead of the user's
76 long-term key (which is derived from a password). This
77 random key is in turn encrypted using the public key from the
78 certificate that came with the request and signed using the KDC's
79 private key, and accompanies the reply, in the preauthentication
82 PKINIT also allows for users with only digital signature keys to
83 authenticate using those keys, and for users to store and retrieve
84 private keys on the KDC.
86 The PKINIT specification may also be used for direct peer to peer
87 authentication without contacting a central KDC. This application
88 of PKINIT is described in PKTAPP [4] and is based on concepts
89 introduced in [5, 6]. For direct client-to-server authentication,
90 the client uses PKINIT to authenticate to the end server (instead
91 of a central KDC), which then issues a ticket for itself. This
92 approach has an advantage over SSL [7] in that the server does not
93 need to save state (cache session keys). Furthermore, an
94 additional benefit is that Kerberos tickets can facilitate
98 3. Proposed Extensions
100 This section describes extensions to RFC 1510 for supporting the
101 use of public key cryptography in the initial request for a ticket
102 granting ticket (TGT).
104 In summary, the following changes to RFC 1510 are proposed:
106 * Users may authenticate using either a public key pair or a
107 conventional (symmetric) key. If public key cryptography is
108 used, public key data is transported in preauthentication
109 data fields to help establish identity.
110 * Users may store private keys on the KDC for retrieval during
111 Kerberos initial authentication.
113 This proposal addresses two ways that users may use public key
114 cryptography for initial authentication. Users may present public
115 key certificates, or they may generate their own session key,
116 signed by their digital signature key. In either case, the end
117 result is that the user obtains an ordinary TGT that may be used for
118 subsequent authentication, with such authentication using only
119 conventional cryptography.
121 Section 3.1 provides definitions to help specify message formats.
122 Section 3.2 and 3.3 describe the extensions for the two initial
123 authentication methods. Section 3.4 describes a way for the user to
124 store and retrieve his private key on the KDC, as an adjunct to the
125 initial authentication.
130 The extensions involve new encryption methods; we propose the
131 addition of the following types:
139 The proposal of these encryption types notwithstanding, we do not
140 mandate the use of any particular public key encryption method.
142 The extensions involve new preauthentication fields; we propose the
143 addition of the following types:
151 The extensions also involve new error types; we propose the addition
152 of the following types:
154 KDC_ERR_CLIENT_NOT_TRUSTED 62
155 KDC_ERR_KDC_NOT_TRUSTED 63
156 KDC_ERR_INVALID_SIG 64
157 KDC_ERR_KEY_TOO_WEAK 65
158 KDC_ERR_CERTIFICATE_MISMATCH 66
160 In addition, PKINIT does not define, but does permit, the following
161 algorithm identifiers for use with the Signature data structure:
163 md4WithRSAEncryption (as defined in PKCS 1)
164 md5WithRSAEncryption (as defined in PKCS 1)
165 sha-1WithRSAEncryption ::= { iso(1) member-body(2) us(840)
166 rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
167 dsaWithSHA1 ::= { OIW oIWSecSig(3) oIWSecAlgorithm(2)
172 OIW ::= iso(1) identifiedOrganization(3) oIW(14)
174 In many cases, PKINIT requires the encoding of an X.500 name as a
175 Realm. In these cases, the realm will be represented using a
176 different style, specified in RFC 1510 with the following example:
178 NAMETYPE:rest/of.name=without-restrictions
180 For a realm derived from an X.500 name, NAMETYPE will have the value
181 X500-RFC1779. The full realm name will appear as follows:
183 X500-RFC1779:RFC1779Encode(DistinguishedName)
185 where DistinguishedName is an X.500 name, and RFC1779Encode is a
186 readable ASCII encoding of an X.500 name, as defined by RFC 1779.
187 To ensure that this encoding is unique, we add the following rules
188 to those specified by RFC 1779:
190 * The optional spaces specified in RFC 1779 are not allowed.
191 * The character that separates relative distinguished names
192 must be ',' (i.e., it must never be ';').
193 * Attribute values must not be enclosed in double quotes.
194 * Attribute values must not be specified as hexadecimal
196 * When an attribute name is specified in the form of an OID,
197 it must start with the 'OID.' prefix, and not the 'oid.'
199 * The order in which the attributes appear in the RFC 1779
200 encoding must be the reverse of the order in the ASN.1
201 encoding of the X.500 name that appears in the public key
202 certificate, because RFC 1779 requires that the least
203 significant relative distinguished name appear first. The
204 order of the relative distinguished names, as well as the
205 order of the attributes within each relative distinguished
206 name, will be reversed.
208 Similarly, PKINIT may require the encoding of an X.500 name as a
209 PrincipalName. In these cases, the name-type of the principal name
210 shall be set to NT-X500-PRINCIPAL. This new name type is defined
213 #define CSFC5c_NT_X500_PRINCIPAL 6
215 The name-string shall be set as follows:
217 RFC1779Encode(DistinguishedName)
222 3.1.1. Encryption and Key Formats
224 In the exposition below, we use the terms public key and private
225 key generically. It should be understood that the term "public
226 key" may be used to refer to either a public encryption key or a
227 signature verification key, and that the term "private key" may be
228 used to refer to either a private decryption key or a signature
229 generation key. The fact that these are logically distinct does
230 not preclude the assignment of bitwise identical keys.
232 All additional symmetric keys specified in this draft shall use the
233 same encryption type as the session key in the response from the
234 KDC. These include the temporary keys used to encrypt the signed
235 random key encrypting the response, as well as the key derived from
236 Diffie-Hellman agreement. In the case of Diffie-Hellman, the key
237 shall be produced from the agreed bit string as follows:
239 * Truncate the bit string to the appropriate length.
240 * Rectify parity in each byte (if necessary) to obtain the key.
242 For instance, in the case of a DES key, we take the first eight
243 bytes of the bit stream, and then adjust the least significant bit
244 of each byte to ensure that each byte has odd parity.
246 RFC 1510, Section 6.1, defines EncryptedData as follows:
248 EncryptedData ::= SEQUENCE {
250 kvno [1] INTEGER OPTIONAL,
251 cipher [2] OCTET STRING
255 RFC 1510 also defines how CipherText is to be composed. It is not
256 an ASN.1 data structure, but rather an octet string which is the
257 encryption of a plaintext string. This plaintext string is in turn
258 a concatenation of the following octet strings: a confounder, a
259 checksum, the message, and padding. Details of how these components
260 are arranged can be found in RFC 1510.
262 The PKINIT protocol introduces several new types of encryption.
263 Data that is encrypted with a public key will allow only the check
264 optional field, as it is defined above. This type of the checksum
265 will be specified in the etype field, together with the encryption
268 In order to identify the checksum type, etype will have the
274 In the case that etype is set to rsa-pub, the optional 'check'
275 field will not be provided.
277 Data that is encrypted with a private key will not use any optional
278 fields. PKINIT uses private key encryption only for signatures,
279 which are encrypted checksums. Therefore, the optional check field
283 3.2. Standard Public Key Authentication
285 Implementation of the changes in this section is REQUIRED for
286 compliance with PKINIT.
288 It is assumed that all public keys are signed by some certification
289 authority (CA). The initial authentication request is sent as per
290 RFC 1510, except that a preauthentication field containing data
291 signed by the user's private key accompanies the request:
293 PA-PK-AS-REQ ::= SEQUENCE {
295 signedAuthPack [0] SignedAuthPack
296 userCert [1] SEQUENCE OF Certificate OPTIONAL,
297 -- the user's certificate chain
298 trustedCertifiers [2] SEQUENCE OF PrincipalName OPTIONAL,
299 -- CAs that the client trusts
300 serialNumber [3] CertificateSerialNumber OPTIONAL
301 -- specifying a particular
302 -- certificate if the client
304 -- must be accompanied by
305 -- a single trustedCertifier
308 CertificateSerialNumber ::= INTEGER
309 -- as specified by PKCS 6
311 SignedAuthPack ::= SEQUENCE {
312 authPack [0] AuthPack,
313 authPackSig [1] Signature,
315 -- using user's private key
318 AuthPack ::= SEQUENCE {
319 pkAuthenticator [0] PKAuthenticator,
320 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL
321 -- if client is using Diffie-Hellman
324 PKAuthenticator ::= SEQUENCE {
325 kdcName [0] PrincipalName,
328 -- for replay prevention
329 ctime [3] KerberosTime,
330 -- for replay prevention
334 Signature ::= SEQUENCE {
335 signatureAlgorithm [0] SignatureAlgorithmIdentifier,
336 pkcsSignature [1] BIT STRING
337 -- octet-aligned big-endian bit
338 -- string (encrypted with signer's
342 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
344 AlgorithmIdentifier ::= SEQUENCE {
345 algorithm ALGORITHM.&id,
348 -- ({iso(1) member-body(2) US(840)
349 -- rsadsi(113549) pkcs(1) pkcs-3(3)
351 parameters ALGORITHM.&type
352 -- for DH, is DHParameter
353 } -- as specified by the X.509 recommendation [9]
355 SubjectPublicKeyInfo ::= SEQUENCE {
356 algorithm AlgorithmIdentifier,
357 subjectPublicKey BIT STRING
359 -- public exponent (INTEGER encoded
360 -- as payload of BIT STRING)
361 } -- as specified by the X.509 recommendation [9]
363 DHParameter ::= SEQUENCE {
368 privateValueLength INTEGER OPTIONAL
369 } -- as specified by the X.509 recommendation [9]
371 Certificate ::= SEQUENCE {
372 certType [0] INTEGER,
373 -- type of certificate
374 -- 1 = X.509v3 (DER encoding)
375 -- 2 = PGP (per PGP specification)
376 certData [1] OCTET STRING
377 -- actual certificate
378 -- type determined by certType
381 If the client passes a certificate serial number in the request,
382 the KDC is requested to use the referred-to certificate. If none
383 exists, then the KDC returns an error of type
384 KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the
385 other hand, the client does not pass any trustedCertifiers,
386 believing that it has the KDC's certificate, but the KDC has more
387 than one certificate.
389 The PKAuthenticator carries information to foil replay attacks,
390 to bind the request and response, and to optionally pass the
391 client's Diffie-Hellman public value (i.e. for using DSA in
392 combination with Diffie-Hellman). The PKAuthenticator is signed
393 with the private key corresponding to the public key in the
394 certificate found in userCert (or cached by the KDC).
396 In the PKAuthenticator, the client may specify the KDC name in one
399 * The Kerberos principal name krbtgt/<realm_name>@<realm_name>,
400 where <realm_name> is replaced by the applicable realm name.
401 * The name in the KDC's certificate (e.g., an X.500 name, or a
404 Note that the first case requires that the certificate name and the
405 Kerberos principal name be bound together (e.g., via an X.509v3
408 The userCert field is a sequence of certificates, the first of which
409 must be the user's public key certificate. Any subsequent
410 certificates will be certificates of the certifiers of the user's
411 certificate. These cerificates may be used by the KDC to verify the
412 user's public key. This field may be left empty if the KDC already
413 has the user's certificate.
415 The trustedCertifiers field contains a list of certification
416 authorities trusted by the client, in the case that the client does
417 not possess the KDC's public key certificate. If the KDC has no
418 certificate signed by any of the trustedCertifiers, then it returns
419 an error of type KDC_ERR_CERTIFICATE_MISMATCH.
421 Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
422 type, the KDC attempts to verify the user's certificate chain
423 (userCert), if one is provided in the request. This is done by
424 verifying the certification path against the KDC's policy of
425 legitimate certifiers. This may be based on a certification
426 hierarchy, or it may be simply a list of recognized certifiers in a
429 If verification of the user's certificate fails, the KDC sends back
430 an error message of type KDC_ERR_CLIENT_NOT_TRUSTED. The e-data
431 field contains additional information pertaining to this error, and
432 is formatted as follows:
434 METHOD-DATA ::= SEQUENCE {
435 method-type [0] INTEGER,
436 -- 1 = cannot verify public key
437 -- 2 = invalid certificate
438 -- 3 = revoked certificate
439 -- 4 = invalid KDC name
440 -- 5 = client name mismatch
441 method-data [1] OCTET STRING OPTIONAL
442 } -- syntax as for KRB_AP_ERR_METHOD (RFC 1510)
444 The values for the method-type and method-data fields are described
447 If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC
448 verifies that it has a certificate issued by one of the certifiers
449 trusted by the client. If it does not have a suitable certificate,
450 the KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to
453 If a trust relationship exists, the KDC then verifies the client's
454 signature on AuthPack. If that fails, the KDC returns an error
455 message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the
456 timestamp in the PKAuthenticator to assure that the request is not a
457 replay. The KDC also verifies that its name is specified in the
460 If the clientPublicValue field is filled in, indicating that the
461 client wishes to use Diffie-Hellman key agreement, then the KDC
462 checks to see that the parameters satisfy its policy. If they do
463 not (e.g., the prime size is insufficient for the expected
464 encryption type), then the KDC sends back an error message of type
465 KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and
466 private values for the response.
468 The KDC also checks that the timestamp in the PKAuthenticator is
469 within the allowable window. If the local (server) time and the
470 client time in the authenticator differ by more than the allowable
471 clock skew, then the KDC returns an error message of type
474 Assuming no errors, the KDC replies as per RFC 1510, except as
475 follows: The user's name in the ticket is as represented in the
476 certificate, unless a Kerberos principal name is bound to the name
477 in the certificate (e.g., via an X.509v3 extension). The user's
478 realm in the ticket shall be the name of the Certification
479 Authority that issued the user's public key certificate.
481 The KDC encrypts the reply not with the user's long-term key, but
482 with a random key generated only for this particular response. This
483 random key is sealed in the preauthentication field:
485 PA-PK-AS-REP ::= SEQUENCE {
487 encSignedReplyKeyPack [0] EncryptedData,
488 -- of type SignedReplyKeyPack
489 -- using the temporary key
491 encTmpKeyPack [1] EncryptedData,
492 -- of type TmpKeyPack
493 -- using either the client public
494 -- key or the Diffie-Hellman key
495 -- specified by SignedDHPublicValue
496 signedKDCPublicValue [2] SignedKDCPublicValue OPTIONAL
497 -- if one was passed in the request
498 kdcCert [3] SEQUENCE OF Certificate OPTIONAL,
499 -- the KDC's certificate chain
502 SignedReplyKeyPack ::= SEQUENCE {
503 replyKeyPack [0] ReplyKeyPack,
504 replyKeyPackSig [1] Signature,
505 -- of replyEncKeyPack
506 -- using KDC's private key
509 ReplyKeyPack ::= SEQUENCE {
510 replyKey [0] EncryptionKey,
511 -- used to encrypt main reply
512 -- of same ENCTYPE as session key
514 -- binds response to the request
515 -- must be same as the nonce
516 -- passed in the PKAuthenticator
519 TmpKeyPack ::= SEQUENCE {
520 tmpKey [0] EncryptionKey,
521 -- used to encrypt the
522 -- SignedReplyKeyPack
523 -- of same ENCTYPE as session key
526 SignedKDCPublicValue ::= SEQUENCE {
527 kdcPublicValue [0] SubjectPublicKeyInfo,
528 -- as described above
529 kdcPublicValueSig [1] Signature
531 -- using KDC's private key
534 The kdcCert field is a sequence of certificates, the first of which
535 must be the KDC's public key certificate. Any subsequent
536 certificates will be certificates of the certifiers of the KDC's
537 certificate. The last of these must have as its certifier one of
538 the certifiers sent to the KDC in the PA-PK-AS-REQ. These
539 cerificates may be used by the client to verify the KDC's public
540 key. This field is empty if the client did not send to the KDC a
541 list of trusted certifiers (the trustedCertifiers field was empty).
543 Since each certifier in the certification path of a user's
544 certificate is essentially a separate realm, the name of each
545 certifier shall be added to the transited field of the ticket. The
546 format of these realm names is defined in Section 3.1 of this
547 document. If applicable, the transit-policy-checked flag should be
548 set in the issued ticket.
550 The KDC's certificate must bind the public key to a name derivable
551 from the name of the realm for that KDC. For an X.509 certificate,
552 this is done as follows. The name of the KDC will be represented
553 as an OtherName, encoded as a GeneralString:
555 GeneralName ::= CHOICE {
556 otherName [0] KDCPrincipalName,
560 KDCPrincipalNameTypes OTHER-NAME ::= {
561 { PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst }
564 KDCPrincipalName ::= SEQUENCE {
565 nameType [0] OTHER-NAME.&id ( { KDCPrincipalNameTypes } ),
566 name [1] OTHER-NAME.&type ( { KDCPrincipalNameTypes }
570 PrincipalNameSrvInst ::= GeneralString
572 where (from the Kerberos specification) we have
574 krb5 OBJECT IDENTIFIER ::= { iso (1)
581 principalName OBJECT IDENTIFIER ::= { krb5 2 }
583 principalNameSrvInst OBJECT IDENTIFIER ::= { principalName 2 }
585 The client then extracts the random key used to encrypt the main
586 reply. This random key (in encPaReply) is encrypted with either the
587 client's public key or with a key derived from the DH values
588 exchanged between the client and the KDC.
591 3.2.1. Additional Information for Errors
593 This section describes the interpretation of the method-type and
594 method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error.
596 If method-type=1, the client's public key certificate chain does not
597 contain a certificate that is signed by a certification authority
598 trusted by the KDC. The format of the method-data field will be an
599 ASN.1 encoding of a list of trusted certifiers, as defined above:
601 TrustedCertifiers ::= SEQUENCE OF PrincipalName
603 If method-type=2, the signature on one of the certificates in the
604 chain cannot be verified. The format of the method-data field will
605 be an ASN.1 encoding of the integer index of the certificate in
608 CertificateIndex ::= INTEGER
609 -- 0 = 1st certificate,
610 -- 1 = 2nd certificate, etc
612 If method-type=3, one of the certificates in the chain has been
613 revoked. The format of the method-data field will be an ASN.1
614 encoding of the integer index of the certificate in question:
616 CertificateIndex ::= INTEGER
617 -- 0 = 1st certificate,
618 -- 1 = 2nd certificate, etc
620 If method-type=4, the KDC name or realm in the PKAuthenticator does
621 not match the principal name of the KDC. There is no method-data
624 If method-type=5, the client name or realm in the certificate does
625 not match the principal name of the client. There is no
626 method-data field in this case.
629 3.3. Digital Signature
631 Implementation of the changes in this section are OPTIONAL for
632 compliance with PKINIT.
634 We offer this option with the warning that it requires the client to
635 generate a random key; the client may not be able to guarantee the
636 same level of randomness as the KDC.
638 If the user registered, or presents a certificate for, a digital
639 signature key with the KDC instead of an encryption key, then a
640 separate exchange must be used. The client sends a request for a
641 TGT as usual, except that it (rather than the KDC) generates the
642 random key that will be used to encrypt the KDC response. This key
643 is sent to the KDC along with the request in a preauthentication
644 field, encrypted with the KDC's public key:
646 PA-PK-AS-SIGN ::= SEQUENCE {
648 encSignedRandomKeyPack [0] EncryptedData,
649 -- of type SignedRandomKeyPack
650 -- using the key in encTmpKeyPack
651 encTmpKeyPack [1] EncryptedData,
652 -- of type TmpKeyPack
653 -- using the KDC's public key
654 userCert [2] SEQUENCE OF Certificate OPTIONAL
655 -- the user's certificate chain
658 SignedRandomKeyPack ::= SEQUENCE {
659 randomkeyPack [0] RandomKeyPack,
660 randomkeyPackSig [1] Signature
662 -- using user's private key
665 RandomKeyPack ::= SEQUENCE {
666 randomKey [0] EncryptionKey,
667 -- will be used to encrypt reply
668 randomKeyAuth [1] PKAuthenticator
669 -- nonce copied from AS-REQ
672 If the KDC does not accept client-generated random keys as a matter
673 of policy, then it sends back an error message of type
674 KDC_ERR_KEY_TOO_WEAK. Otherwise, it extracts the random key as
677 Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies
678 the randomKey. It then replies as per RFC 1510, except that the
679 reply is encrypted not with a password-derived user key, but with
680 the randomKey sent in the request. Since the client already knows
681 this key, there is no need to accompany the reply with an extra
682 preauthentication field. The transited field of the ticket should
683 specify the certification path as described in Section 3.2.
686 3.4. Retrieving the User's Private Key from the KDC
688 Implementation of the changes described in this section are OPTIONAL
689 for compliance with PKINIT.
691 When the user's private key is not stored local to the user, he may
692 choose to store the private key (normally encrypted using a
693 password-derived key) on the KDC. In this case, the client makes a
694 request as described above, except that instead of preauthenticating
695 with his private key, he uses a symmetric key shared with the KDC.
697 For simplicity's sake, this shared key is derived from the password-
698 derived key used to encrypt the private key, in such a way that the
699 KDC can authenticate the user with the shared key without being able
700 to extract the private key.
702 We provide this option to present the user with an alternative to
703 storing the private key on local disk at each machine where he
704 expects to authenticate himself using PKINIT. It should be noted
705 that it replaces the added risk of long-term storage of the private
706 key on possibly many workstations with the added risk of storing the
707 private key on the KDC in a form vulnerable to brute-force attack.
709 Denote by K1 the symmetric key used to encrypt the private key.
710 Then construct symmetric key K2 as follows:
712 * Perform a hash on K1.
713 * Truncate the digest to Length(K1) bytes.
714 * Rectify parity in each byte (if necessary) to obtain K2.
716 The KDC stores K2, the public key, and the encrypted private key.
717 This key pair is designated as the "primary" key pair for that user.
718 This primary key pair is the one used to perform initial
719 authentication using the PA-PK-AS-REP preauthentication field. If
720 he desires, he may also store additional key pairs on the KDC; these
721 may be requested in addition to the primary. When the client
722 requests initial authentication using public key cryptography, it
723 must then include in its request, instead of a PA-PK-AS-REQ, the
724 following preauthentication sequence:
726 PA-PK-KEY-REQ ::= SEQUENCE {
728 signedPKAuth [0] SignedPKAuth,
729 trustedCertifiers [1] SEQUENCE OF PrincipalName OPTIONAL,
730 -- CAs that the client trusts
731 keyIDList [2] SEQUENCE OF Checksum OPTIONAL
732 -- payload is hash of public key
733 -- corresponding to desired
735 -- if absent, KDC will return all
736 -- stored private keys
739 Checksum ::= SEQUENCE {
740 cksumtype [0] INTEGER,
741 checksum [1] OCTET STRING
742 } -- as specified by RFC 1510
744 SignedPKAuth ::= SEQUENCE {
745 pkAuth [0] PKAuthenticator,
746 pkAuthSig [1] Signature
748 -- using the symmetric key K2
751 If a keyIDList is present, the first identifier should indicate
752 the primary private key. No public key certificate is required,
753 since the KDC stores the public key along with the private key.
754 If there is no keyIDList, all the user's private keys are returned.
756 Upon receipt, the KDC verifies the signature using K2. If the
757 verification fails, the KDC sends back an error of type
758 KDC_ERR_INVALID_SIG. If the signature verifies, but the requested
759 keys are not found on the KDC, then the KDC sends back an error of
760 type KDC_ERR_PREAUTH_FAILED. If all checks out, the KDC responds as
761 described in Section 3.2, except that in addition, the KDC appends
762 the following preauthentication sequence:
764 PA-PK-KEY-REP ::= SEQUENCE {
766 encKeyRep [0] EncryptedData
767 -- of type EncKeyReply
768 -- using the symmetric key K2
771 EncKeyReply ::= SEQUENCE {
772 keyPackList [0] SEQUENCE OF KeyPack,
773 -- the first KeyPair is
774 -- the primary key pair
776 -- binds reply to request
777 -- must be identical to the nonce
778 -- sent in the SignedAuthPack
781 KeyPack ::= SEQUENCE {
783 encPrivKey [1] OCTET STRING
786 Upon receipt of the reply, the client extracts the encrypted private
787 keys (and may store them, at the client's option). The primary
788 private key, which must be the first private key in the keyPack
789 SEQUENCE, is used to decrypt the random key in the PA-PK-AS-REP;
790 this key in turn is used to decrypt the main reply as described in
794 4. Logistics and Policy
796 This section describes a way to define the policy on the use of
797 PKINIT for each principal and request.
799 The KDC is not required to contain a database record for users
800 that use either the Standard Public Key Authentication or Public Key
801 Authentication with a Digital Signature. However, if these users
802 are registered with the KDC, it is recommended that the database
803 record for these users be modified to include three additional flags
804 in the attributes field.
806 The first flag, use_standard_pk_init, indicates that the user should
807 authenticate using standard PKINIT as described in Section 3.2. The
808 second flag, use_digital_signature, indicates that the user should
809 authenticate using digital signature PKINIT as described in Section
810 3.3. The third flag, store_private_key, indicates that the user
811 has stored his private key on the KDC and should retrieve it using
812 the exchange described in Section 3.4.
814 If one of the preauthentication fields defined above is included in
815 the request, then the KDC shall respond as described in Sections 3.2
816 through 3.4, ignoring the aforementioned database flags. If more
817 than one of the preauthentication fields is present, the KDC shall
818 respond with an error of type KDC_ERR_PREAUTH_FAILED.
820 In the event that none of the preauthentication fields defined above
821 are included in the request, the KDC checks to see if any of the
822 above flags are set. If the first flag is set, then it sends back
823 an error of type KDC_ERR_PREAUTH_REQUIRED indicating that a
824 preauthentication field of type PA-PK-AS-REQ must be included in the
827 Otherwise, if the first flag is clear, but the second flag is set,
828 then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
829 indicating that a preauthentication field of type PA-PK-AS-SIGN must
830 be included in the request.
832 Lastly, if the first two flags are clear, but the third flag is set,
833 then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
834 indicating that a preauthentication field of type PA-PK-KEY-REQ must
835 be included in the request.
838 5. Security Considerations
840 PKINIT raises a few security considerations, which we will address
843 First of all, PKINIT introduces a new trust model, where KDCs do not
844 (necessarily) certify the identity of those for whom they issue
845 tickets. PKINIT does allow KDCs to act as their own CAs, in order
846 to simplify key management, but one of the additional benefits is to
847 align Kerberos authentication with a global public key
848 infrastructure. Anyone using PKINIT in this way must be aware of
849 how the certification infrastructure they are linking to works.
851 Secondly, PKINIT also introduces the possibility of interactions
852 between different cryptosystems, which may be of widely varying
853 strengths. Many systems, for instance, allow the use of 512-bit
854 public keys. Using such keys to wrap data encrypted under strong
855 conventional cryptosystems, such as triple-DES, is inappropriate;
856 it adds a weak link to a strong one at extra cost. Implementors
857 and administrators should take care to avoid such wasteful and
858 deceptive interactions.
863 Certificate chains can potentially grow quite large and span several
864 UDP packets; this in turn increases the probability that a Kerberos
865 message involving PKINIT extensions will be broken in transit. In
866 light of the possibility that the Kerberos specification will
867 require KDCs to accept requests using TCP as a transport mechanism,
868 we make the same recommendation with respect to the PKINIT
874 [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service
875 (V5). Request for Comments 1510.
877 [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
878 for Computer Networks, IEEE Communications, 32(9):33-38. September
881 [3] A. Medvinsky, M. Hur. Addition of Kerberos Cipher Suites to
882 Transport Layer Security (TLS).
883 draft-ietf-tls-kerb-cipher-suites-00.txt
885 [4] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing
886 Tickets for Application Servers (PKTAPP).
887 draft-ietf-cat-pktapp-00.txt
889 [5] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos
890 Using Public Key Cryptography. Symposium On Network and Distributed
891 System Security, 1997.
893 [6] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction
894 Protocol. In Proceedings of the USENIX Workshop on Electronic
897 [7] Alan O. Freier, Philip Karlton and Paul C. Kocher. The SSL
898 Protocol, Version 3.0 - IETF Draft.
900 [8] B.C. Neuman, Proxy-Based Authorization and Accounting for
901 Distributed Systems. In Proceedings of the 13th International
902 Conference on Distributed Computing Systems, May 1993.
904 [9] ITU-T (formerly CCITT) Information technology - Open Systems
905 Interconnection - The Directory: Authentication Framework
906 Recommendation X.509 ISO/IEC 9594-8
911 Sasha Medvinsky contributed several ideas to the protocol changes
912 and specifications in this document. His additions have been most
915 Some of the ideas on which this proposal is based arose during
916 discussions over several years between members of the SAAG, the IETF
917 CAT working group, and the PSRG, regarding integration of Kerberos
918 and SPX. Some ideas have also been drawn from the DASS system.
919 These changes are by no means endorsed by these groups. This is an
920 attempt to revive some of the goals of those groups, and this
921 proposal approaches those goals primarily from the Kerberos
922 perspective. Lastly, comments from groups working on similar ideas
923 in DCE have been invaluable.
928 This draft expires September 15, 1998.
935 USC Information Sciences Institute
936 4676 Admiralty Way Suite 1001
937 Marina del Rey CA 90292-6695
938 Phone: +1 310 822 1511
939 E-mail: {brian, bcn}@isi.edu
942 Digital Equipment Corporation
943 550 King Street, LKG2-2/Z7
945 Phone: +1 508 486 5210
946 E-mail: wray@tuxedo.enet.dec.com
950 CyberSafe Corporation
951 1605 NW Sammamish Road Suite 310
952 Issaquah WA 98027-5378
953 Phone: +1 206 391 6000
954 E-mail: {ari.medvinsky, matt.hur}@cybersafe.com
959 E-mail: jtrostle@novell.com