1 INTERNET-DRAFT Clifford Neuman
2 draft-ietf-cat-kerberos-pk-init-03.txt Brian Tung
4 expires September 30, 1997 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-03.txt, and expires September 30,
37 1997. 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 to associate a key pair with each realm, which
60 can then be used to facilitate cross-realm authentication; this is
61 the topic of another draft proposal. Another way is to allow users
62 with public key certificates to use them in initial authentication.
63 This 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 instead
74 of being encrypted in the user's long-term key (which is derived
75 from a password), it is encrypted in a randomly-generated key. This
76 random key is in turn encrypted using the public key certificate
77 that came with the request and signed using the KDC's signature key,
78 and accompanies the reply, in the preauthentication fields.
80 PKINIT also allows for users with only digital signature keys to
81 authenticate using those keys, and for users to store and retrieve
82 private keys on the KDC.
84 The PKINIT specification may also be used for direct peer to peer
85 authentication without contacting a central KDC. This application
86 of PKINIT is described in PKTAPP [4] and is based on concepts
87 introduced in [5, 6]. For direct client-to-server authentication,
88 the client uses PKINIT to authenticate to the end server (instead
89 of a central KDC), which then issues a ticket for itself. This
90 approach has an advantage over SSL [7] in that the server does not
91 need to save state (cache session keys). Furthermore, an
92 additional benefit is that Kerberos tickets can facilitate
96 3. Proposed Extensions
98 This section describes extensions to RFC 1510 for supporting the
99 use of public key cryptography in the initial request for a ticket
100 granting ticket (TGT).
102 In summary, the following changes to RFC 1510 are proposed:
104 --> Users may authenticate using either a public key pair or a
105 conventional (symmetric) key. If public key cryptography is
106 used, public key data is transported in preauthentication
107 data fields to help establish identity.
108 --> Users may store private keys on the KDC for retrieval during
109 Kerberos initial authentication.
111 This proposal addresses two ways that users may use public key
112 cryptography for initial authentication. Users may present public
113 key certificates, or they may generate their own session key,
114 signed by their digital signature key. In either case, the end
115 result is that the user obtains an ordinary TGT that may be used for
116 subsequent authentication, with such authentication using only
117 conventional cryptography.
119 Section 3.1 provides definitions to help specify message formats.
120 Section 3.2 and 3.3 describe the extensions for the two initial
121 authentication methods. Section 3.3 describes a way for the user to
122 store and retrieve his private key on the KDC.
127 Hash and encryption types will be specified using ENCTYPE tags; we
128 propose the addition of the following types:
130 #define ENCTYPE_SIGN_DSA_GENERATE 0x0011
131 #define ENCTYPE_SIGN_DSA_VERIFY 0x0012
132 #define ENCTYPE_ENCRYPT_RSA_PRIV 0x0021
133 #define ENCTYPE_ENCRYPT_RSA_PUB 0x0022
135 allowing further signature types to be defined in the range 0x0011
136 through 0x001f, and further encryption types to be defined in the
137 range 0x0021 through 0x002f.
139 The extensions involve new preauthentication fields. The
140 preauthentication data types are in the range 17 through 21.
141 These values are also specified along with their corresponding
144 #define PA-PK-AS-REQ 17
145 #define PA-PK-AS-REP 18
146 #define PA-PK-AS-SIGN 19
147 #define PA-PK-KEY-REQ 20
148 #define PA-PK-KEY-REP 21
150 The extensions also involve new error types. The new error types
151 are in the range 227 through 229. They are:
153 #define KDC_ERROR_CLIENT_NOT_TRUSTED 227
154 #define KDC_ERROR_KDC_NOT_TRUSTED 228
155 #define KDC_ERROR_INVALID_SIG 229
157 In the exposition below, we use the following terms: encryption key,
158 decryption key, signature key, verification key. It should be
159 understood that encryption and verification keys are essentially
160 public keys, and decryption and signature keys are essentially
161 private keys. The fact that they are logically distinct does
162 not preclude the assignment of bitwise identical keys.
165 3.2. Standard Public Key Authentication
167 Implementation of the changes in this section is REQUIRED for
168 compliance with pk-init.
170 It is assumed that all public keys are signed by some certification
171 authority (CA). The initial authentication request is sent as per
172 RFC 1510, except that a preauthentication field containing data
173 signed by the user's signature key accompanies the request:
175 PA-PK-AS-REQ ::- SEQUENCE {
177 signedPKAuth [0] SignedPKAuthenticator,
178 userCert [1] SEQUENCE OF Certificate OPTIONAL,
179 -- the user's certificate
180 -- optionally followed by that
181 -- certificate's certifier chain
182 trustedCertifiers [2] SEQUENCE OF PrincipalName OPTIONAL
183 -- CAs that the client trusts
186 SignedPKAuthenticator ::= SEQUENCE {
187 pkAuth [0] PKAuthenticator,
188 pkAuthSig [1] Signature,
190 -- using user's signature key
193 PKAuthenticator ::= SEQUENCE {
195 -- for replay prevention
196 ctime [1] KerberosTime,
197 -- for replay prevention
199 -- binds response to this request
200 kdcName [3] PrincipalName,
201 clientPubValue [4] SubjectPublicKeyInfo OPTIONAL,
202 -- for Diffie-Hellman algorithm
205 Signature ::= SEQUENCE {
206 signedHash [0] EncryptedData
208 -- encrypted under signature key
211 Checksum ::= SEQUENCE {
212 cksumtype [0] INTEGER,
213 checksum [1] OCTET STRING
214 } -- as specified by RFC 1510
216 SubjectPublicKeyInfo ::= SEQUENCE {
217 algorithm [0] algorithmIdentifier,
218 subjectPublicKey [1] BIT STRING
219 } -- as specified by the X.509 recommendation [9]
221 Certificate ::= SEQUENCE {
222 CertType [0] INTEGER,
223 -- type of certificate
224 -- 1 = X.509v3 (DER encoding)
225 -- 2 = PGP (per PGP draft)
226 CertData [1] OCTET STRING
227 -- actual certificate
228 -- type determined by CertType
231 Note: If the signature uses RSA keys, then it is to be performed
234 The PKAuthenticator carries information to foil replay attacks,
235 to bind the request and response, and to optionally pass the
236 client's Diffie-Hellman public value (i.e. for using DSA in
237 combination with Diffie-Hellman). The PKAuthenticator is signed
238 with the private key corresponding to the public key in the
239 certificate found in userCert (or cached by the KDC).
241 In the PKAuthenticator, the client may specify the KDC name in one
242 of two ways: 1) a Kerberos principal name, or 2) the name in the
243 KDC's certificate (e.g., an X.500 name, or a PGP name). Note that
244 case #1 requires that the certificate name and the Kerberos principal
245 name be bound together (e.g., via an X.509v3 extension).
247 The userCert field is a sequence of certificates, the first of which
248 must be the user's public key certificate. Any subsequent
249 certificates will be certificates of the certifiers of the user's
250 certificate. These cerificates may be used by the KDC to verify the
251 user's public key. This field is empty if the KDC already has the
254 The trustedCertifiers field contains a list of certification
255 authorities trusted by the client, in the case that the client does
256 not possess the KDC's public key certificate.
258 Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
259 type, the KDC attempts to verify the user's certificate chain
260 (userCert), if one is provided in the request. This is done by
261 verifying the certification path against the KDC's policy of
262 legitimate certifiers. This may be based on a certification
263 hierarchy, or it may be simply a list of recognized certifiers in a
264 system like PGP. If the certification path does not match one of
265 the KDC's trusted certifiers, the KDC sends back an error message of
266 type KDC_ERROR_CLIENT_NOT_TRUSTED, and it includes in the error data
267 field a list of its own trusted certifiers, upon which the client
270 If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC
271 verifies that it has a certificate issued by one of the certifiers
272 trusted by the client. If it does not have a suitable certificate,
273 the KDC returns an error message of type KDC_ERROR_KDC_NOT_TRUSTED
276 If a trust relationship exists, the KDC then verifies the client's
277 signature on PKAuthenticator. If that fails, the KDC returns an
278 error message of type KDC_ERROR_INVALID_SIG. Otherwise, the KDC
279 uses the timestamp in the PKAuthenticator to assure that the request
280 is not a replay. The KDC also verifies that its name is specified
283 Assuming no errors, the KDC replies as per RFC 1510, except that it
284 encrypts the reply not with the user's key, but with a random key
285 generated only for this particular response. This random key
286 is sealed in the preauthentication field:
288 PA-PK-AS-REP ::= SEQUENCE {
290 kdcCert [0] SEQUENCE OF Certificate OPTIONAL,
291 -- the KDC's certificate
292 -- optionally followed by that
293 -- certificate's certifier chain
294 encPaReply [1] EncryptedData,
296 -- using either the client public
297 -- key or the Diffie-Hellman key
298 -- specified by SignedDHPublicValue
299 signedDHPublicValue [2] SignedDHPublicValue OPTIONAL
303 PaReply ::= SEQUENCE {
304 replyEncKeyPack [0] ReplyEncKeyPack,
305 replyEncKeyPackSig [1] Signature,
306 -- of replyEncKeyPack
307 -- using KDC's signature key
310 ReplyEncKeyPack ::= SEQUENCE {
311 replyEncKey [0] EncryptionKey,
312 -- used to encrypt main reply
314 -- binds response to the request
315 -- passed in the PKAuthenticator
318 SignedDHPublicValue ::= SEQUENCE {
319 dhPublicValue [0] SubjectPublicKeyInfo,
320 dhPublicValueSig [1] Signature
322 -- using KDC's signature key
325 The kdcCert field is a sequence of certificates, the first of which
326 must have as its root certifier one of the certifiers sent to the
327 KDC in the PA-PK-AS-REQ. Any subsequent certificates will be
328 certificates of the certifiers of the KDC's certificate. These
329 cerificates may be used by the client to verify the KDC's public
330 key. This field is empty if the client did not send to the KDC a
331 list of trusted certifiers (the trustedCertifiers field was empty).
333 Since each certifier in the certification path of a user's
334 certificate is essentially a separate realm, the name of each
335 certifier shall be added to the transited field of the ticket. The
336 format of these realm names shall follow the naming constraints set
337 forth in RFC 1510 (sections 7.1 and 3.3.3.1). Note that this will
338 require new nametypes to be defined for PGP certifiers and other
339 types of realms as they arise.
341 The KDC's certificate must bind the public key to a name derivable
342 from the name of the realm for that KDC. The client then extracts
343 the random key used to encrypt the main reply. This random key (in
344 encPaReply) is encrypted with either the client's public key or
345 with a key derived from the DH values exchanged between the client
349 3.3. Digital Signature
351 Implementation of the changes in this section are OPTIONAL for
352 compliance with pk-init.
354 We offer this option with the warning that it requires the client to
355 generate a random key; the client may not be able to guarantee the
356 same level of randomness as the KDC.
358 If the user registered a digital signature key with the KDC instead
359 of an encryption key, then a separate exchange must be used. The
360 client sends a request for a TGT as usual, except that it (rather
361 than the KDC) generates the random key that will be used to encrypt
362 the KDC response. This key is sent to the KDC along with the
363 request in a preauthentication field:
365 PA-PK-AS-SIGN ::= SEQUENCE {
367 encSignedKeyPack [0] EncryptedData
369 -- using the KDC's public key
372 SignedKeyPack ::= SEQUENCE {
373 signedKey [0] KeyPack,
374 signedKeyAuth [1] PKAuthenticator,
375 signedKeySig [2] Signature
376 -- of signedKey.signedKeyAuth
377 -- using user's signature key
380 KeyPack ::= SEQUENCE {
381 randomKey [0] EncryptionKey,
382 -- will be used to encrypt reply
386 where the nonce is copied from the request.
388 Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies
389 the randomKey. It then replies as per RFC 1510, except that the
390 reply is encrypted not with a password-derived user key, but with
391 the randomKey sent in the request. Since the client already knows
392 this key, there is no need to accompany the reply with an extra
393 preauthentication field. The transited field of the ticket should
394 specify the certification path as described in Section 3.2.
397 3.4. Retrieving the Private Key From the KDC
399 Implementation of the changes in this section is RECOMMENDED for
400 compliance with pk-init.
402 When the user's private key is not stored local to the user, he may
403 choose to store the private key (normally encrypted using a
404 password-derived key) on the KDC. We provide this option to present
405 the user with an alternative to storing the private key on local
406 disk at each machine where he expects to authenticate himself using
407 pk-init. It should be noted that it replaces the added risk of
408 long-term storage of the private key on possibly many workstations
409 with the added risk of storing the private key on the KDC in a
410 form vulnerable to brute-force attack.
412 In order to obtain a private key, the client includes a
413 preauthentication field with the AS-REQ message:
415 PA-PK-KEY-REQ ::= SEQUENCE {
417 patimestamp [0] KerberosTime OPTIONAL,
418 -- used to address replay attacks.
419 pausec [1] INTEGER OPTIONAL,
420 -- used to address replay attacks.
422 -- binds the reply to this request
423 privkeyID [3] SEQUENCE OF KeyID OPTIONAL
424 -- constructed as a hash of
425 -- public key corresponding to
426 -- desired private key
430 KeyIdentifier [0] OCTET STRING
433 The client may request a specific private key by sending the
434 corresponding ID. If this field is left empty, then all
435 private keys are returned.
437 If all checks out, the KDC responds as described in the above
438 sections, except that an additional preauthentication field,
439 containing the user's private key, accompanies the reply:
441 PA-PK-KEY-REP ::= SEQUENCE {
444 -- binds the reply to the request
445 KeyData [1] SEQUENCE OF KeyPair
448 KeyPair ::= SEQUENCE {
449 privKeyID [0] OCTET STRING,
450 -- corresponding to encPrivKey
451 encPrivKey [1] OCTET STRING
455 3.4.1. Additional Protection of Retrieved Private Keys
457 We solicit discussion on the following proposal: that the client may
458 optionally include in its request additional data to encrypt the
459 private key, which is currently only protected by the user's
460 password. One possibility is that the client might generate a
461 random string of bits, encrypt it with the public key of the KDC (as
462 in the SignedKeyPack, but with an ordinary OCTET STRING in place of
463 an EncryptionKey), and include this with the request. The KDC then
464 XORs each returned key with this random bit string. (If the bit
465 string is too short, the KDC could either return an error, or XOR
466 the returned key with a repetition of the bit string.)
468 In order to make this work, additional means of preauthentication
469 need to be devised in order to prevent attackers from simply
470 inserting their own bit string. One way to do this is to store
471 a hash of the password-derived key (the one used to encrypt the
472 private key). This hash is then used in turn to derive a second
473 key (called the hash-key); the hash-key is used to encrypt an ASN.1
474 structure containing the generated bit string and a nonce value
475 that binds it to the request.
477 Since the KDC possesses the hash, it can generate the hash-key and
478 verify this (weaker) preauthentication, and yet cannot reproduce
479 the private key itself, since the hash is a one-way function.
482 4. Logistics and Policy Issues
484 We solicit discussion on how clients and KDCs should be configured
485 in order to determine which of the options described above (if any)
486 should be used. One possibility is to set the user's database
487 record to indicate that authentication is to use public key
488 cryptography; this will not work, however, in the event that the
489 client needs to know before making the initial request.
491 5. Compatibility with One-Time Passcodes
493 We solicit discussion on how the protocol changes proposed in this
494 draft will interact with the proposed use of one-time passcodes
495 discussed in draft-ietf-cat-kerberos-passwords-00.txt.
498 6. Strength of Cryptographic Schemes
500 In light of recent findings on the strength of MD5 and DES,
501 we solicit discussion on which encryption types to incorporate
502 into the protocol changes.
507 [1] J. Kohl, C. Neuman. The Kerberos Network Authentication
508 Service (V5). Request for Comments: 1510
510 [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
511 for Computer Networks, IEEE Communications, 32(9):33-38.
514 [3] A. Medvinsky, M. Hur. Addition of Kerberos Cipher Suites to
515 Transport Layer Security (TLS).
516 draft-ietf-tls-kerb-cipher-suites-00.txt
518 [4] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing
519 Tickets for Application Servers (PKTAPP).
520 draft-ietf-cat-pktapp-00.txt
522 [5] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos Using
523 Public Key Cryptography. Symposium On Network and Distributed System
526 [6] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction
527 Protocol. In Proceedings of the USENIX Workshop on Electronic Commerce,
530 [7] Alan O. Freier, Philip Karlton and Paul C. Kocher.
531 The SSL Protocol, Version 3.0 - IETF Draft.
533 [8] B.C. Neuman, Proxy-Based Authorization and Accounting for
534 Distributed Systems. In Proceedings of the 13th International
535 Conference on Distributed Computing Systems, May 1993
537 [9] ITU-T (formerly CCITT)
538 Information technology - Open Systems Interconnection -
539 The Directory: Authentication Framework Recommendation X.509
545 Some of the ideas on which this proposal is based arose during
546 discussions over several years between members of the SAAG, the IETF
547 CAT working group, and the PSRG, regarding integration of Kerberos
548 and SPX. Some ideas have also been drawn from the DASS system.
549 These changes are by no means endorsed by these groups. This is an
550 attempt to revive some of the goals of those groups, and this
551 proposal approaches those goals primarily from the Kerberos
552 perspective. Lastly, comments from groups working on similar ideas
553 in DCE have been invaluable.
558 This draft expires September 30, 1997.
565 USC Information Sciences Institute
566 4676 Admiralty Way Suite 1001
567 Marina del Rey CA 90292-6695
568 Phone: +1 310 822 1511
569 E-mail: {bcn, brian}@isi.edu
572 Digital Equipment Corporation
573 550 King Street, LKG2-2/Z7
575 Phone: +1 508 486 5210
576 E-mail: wray@tuxedo.enet.dec.com
580 CyberSafe Corporation
581 1605 NW Sammamish Road Suite 310
582 Issaquah WA 98027-5378
583 Phone: +1 206 391 6000
584 E-mail: {ari.medvinsky, matt.hur}@cybersafe.com
588 E-mail: jonathan.trostle@novell.com