2 INTERNET-DRAFT Clifford Neuman
3 draft-ietf-cat-kerberos-pk-init-03.txt Brian Tung
5 expires September 30, 1997 John Wray
6 Digital Equipment Corporation
14 Public Key Cryptography for Initial Authentication in Kerberos
17 0. Status Of this Memo
19 This document is an Internet-Draft. Internet-Drafts are working
20 documents of the Internet Engineering Task Force (IETF), its
21 areas, and its working groups. Note that other groups may also
22 distribute working documents as Internet-Drafts.
24 Internet-Drafts are draft documents valid for a maximum of six
25 months and may be updated, replaced, or obsoleted by other
26 documents at any time. It is inappropriate to use Internet-Drafts
27 as reference material or to cite them other than as "work in
30 To learn the current status of any Internet-Draft, please check
31 the "1id-abstracts.txt" listing contained in the Internet-Drafts
32 Shadow Directories on ds.internic.net (US East Coast),
33 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
34 munnari.oz.au (Pacific Rim).
36 The distribution of this memo is unlimited. It is filed as
37 draft-ietf-cat-kerberos-pk-init-03.txt, and expires September 30,
38 1997. Please send comments to the authors.
43 This document defines extensions (PKINIT) to the Kerberos protocol
44 specification (RFC 1510 [1]) to provide a method for using public
45 key cryptography during initial authentication. The methods
46 defined specify the ways in which preauthentication data fields and
47 error data fields in Kerberos messages are to be used to transport
53 The popularity of public key cryptography has produced a desire for
54 its support in Kerberos [2]. The advantages provided by public key
55 cryptography include simplified key management (from the Kerberos
56 perspective) and the ability to leverage existing and developing
57 public key certification infrastructures.
59 Public key cryptography can be integrated into Kerberos in a number
60 of ways. One is to to associate a key pair with each realm, which
61 can then be used to facilitate cross-realm authentication; this is
62 the topic of another draft proposal. Another way is to allow users
63 with public key certificates to use them in initial authentication.
64 This is the concern of the current document.
66 One of the guiding principles in the design of PKINIT is that
67 changes should be as minimal as possible. As a result, the basic
68 mechanism of PKINIT is as follows: The user sends a request to the
69 KDC as before, except that if that user is to use public key
70 cryptography in the initial authentication step, his certificate
71 accompanies the initial request, in the preauthentication fields.
73 Upon receipt of this request, the KDC verifies the certificate and
74 issues a ticket granting ticket (TGT) as before, except that instead
75 of being encrypted in the user's long-term key (which is derived
76 from a password), it is encrypted in a randomly-generated key. This
77 random key is in turn encrypted using the public key certificate
78 that came with the request and signed using the KDC's signature key,
79 and accompanies the reply, in the preauthentication fields.
81 PKINIT also allows for users with only digital signature keys to
82 authenticate using those keys, and for users to store and retrieve
83 private keys on the KDC.
85 The PKINIT specification may also be used for direct peer to peer
86 authentication without contacting a central KDC. This application
87 of PKINIT is described in PKTAPP [4] and is based on concepts
88 introduced in [5, 6]. For direct client-to-server authentication,
89 the client uses PKINIT to authenticate to the end server (instead
90 of a central KDC), which then issues a ticket for itself. This
91 approach has an advantage over SSL [7] in that the server does not
92 need to save state (cache session keys). Furthermore, an
93 additional benefit is that Kerberos tickets can facilitate
97 3. Proposed Extensions
99 This section describes extensions to RFC 1510 for supporting the
100 use of public key cryptography in the initial request for a ticket
101 granting ticket (TGT).
103 In summary, the following changes to RFC 1510 are proposed:
105 --> Users may authenticate using either a public key pair or a
106 conventional (symmetric) key. If public key cryptography is
107 used, public key data is transported in preauthentication
108 data fields to help establish identity.
109 --> Users may store private keys on the KDC for retrieval during
110 Kerberos initial authentication.
112 This proposal addresses two ways that users may use public key
113 cryptography for initial authentication. Users may present public
114 key certificates, or they may generate their own session key,
115 signed by their digital signature key. In either case, the end
116 result is that the user obtains an ordinary TGT that may be used for
117 subsequent authentication, with such authentication using only
118 conventional cryptography.
120 Section 3.1 provides definitions to help specify message formats.
121 Section 3.2 and 3.3 describe the extensions for the two initial
122 authentication methods. Section 3.3 describes a way for the user to
123 store and retrieve his private key on the KDC.
128 Hash and encryption types will be specified using ENCTYPE tags; we
129 propose the addition of the following types:
131 #define ENCTYPE_SIGN_DSA_GENERATE 0x0011
132 #define ENCTYPE_SIGN_DSA_VERIFY 0x0012
133 #define ENCTYPE_ENCRYPT_RSA_PRIV 0x0021
134 #define ENCTYPE_ENCRYPT_RSA_PUB 0x0022
136 allowing further signature types to be defined in the range 0x0011
137 through 0x001f, and further encryption types to be defined in the
138 range 0x0021 through 0x002f.
140 The extensions involve new preauthentication fields. The
141 preauthentication data types are in the range 17 through 21.
142 These values are also specified along with their corresponding
145 #define PA-PK-AS-REQ 17
146 #define PA-PK-AS-REP 18
147 #define PA-PK-AS-SIGN 19
148 #define PA-PK-KEY-REQ 20
149 #define PA-PK-KEY-REP 21
151 The extensions also involve new error types. The new error types
152 are in the range 227 through 229. They are:
154 #define KDC_ERROR_CLIENT_NOT_TRUSTED 227
155 #define KDC_ERROR_KDC_NOT_TRUSTED 228
156 #define KDC_ERROR_INVALID_SIG 229
158 In the exposition below, we use the following terms: encryption key,
159 decryption key, signature key, verification key. It should be
160 understood that encryption and verification keys are essentially
161 public keys, and decryption and signature keys are essentially
162 private keys. The fact that they are logically distinct does
163 not preclude the assignment of bitwise identical keys.
166 3.2. Standard Public Key Authentication
168 Implementation of the changes in this section is REQUIRED for
169 compliance with pk-init.
171 It is assumed that all public keys are signed by some certification
172 authority (CA). The initial authentication request is sent as per
173 RFC 1510, except that a preauthentication field containing data
174 signed by the user's signature key accompanies the request:
176 PA-PK-AS-REQ ::- SEQUENCE {
178 signedPKAuth [0] SignedPKAuthenticator,
179 userCert [1] SEQUENCE OF Certificate OPTIONAL,
180 -- the user's certificate
181 -- optionally followed by that
182 -- certificate's certifier chain
183 trustedCertifiers [2] SEQUENCE OF PrincipalName OPTIONAL
184 -- CAs that the client trusts
187 SignedPKAuthenticator ::= SEQUENCE {
188 pkAuth [0] PKAuthenticator,
189 pkAuthSig [1] Signature,
191 -- using user's signature key
194 PKAuthenticator ::= SEQUENCE {
196 -- for replay prevention
197 ctime [1] KerberosTime,
198 -- for replay prevention
200 -- binds response to this request
201 kdcName [3] PrincipalName,
202 clientPubValue [4] SubjectPublicKeyInfo OPTIONAL,
203 -- for Diffie-Hellman algorithm
206 Signature ::= SEQUENCE {
207 signedHash [0] EncryptedData
209 -- encrypted under signature key
212 Checksum ::= SEQUENCE {
213 cksumtype [0] INTEGER,
214 checksum [1] OCTET STRING
215 } -- as specified by RFC 1510
217 SubjectPublicKeyInfo ::= SEQUENCE {
218 algorithm [0] algorithmIdentifier,
219 subjectPublicKey [1] BIT STRING
220 } -- as specified by the X.509 recommendation [9]
222 Certificate ::= SEQUENCE {
223 CertType [0] INTEGER,
224 -- type of certificate
225 -- 1 = X.509v3 (DER encoding)
226 -- 2 = PGP (per PGP draft)
227 CertData [1] OCTET STRING
228 -- actual certificate
229 -- type determined by CertType
232 Note: If the signature uses RSA keys, then it is to be performed
235 The PKAuthenticator carries information to foil replay attacks,
236 to bind the request and response, and to optionally pass the
237 client's Diffie-Hellman public value (i.e. for using DSA in
238 combination with Diffie-Hellman). The PKAuthenticator is signed
239 with the private key corresponding to the public key in the
240 certificate found in userCert (or cached by the KDC).
242 In the PKAuthenticator, the client may specify the KDC name in one
243 of two ways: 1) a Kerberos principal name, or 2) the name in the
244 KDC's certificate (e.g., an X.500 name, or a PGP name). Note that
245 case #1 requires that the certificate name and the Kerberos principal
246 name be bound together (e.g., via an X.509v3 extension).
248 The userCert field is a sequence of certificates, the first of which
249 must be the user's public key certificate. Any subsequent
250 certificates will be certificates of the certifiers of the user's
251 certificate. These cerificates may be used by the KDC to verify the
252 user's public key. This field is empty if the KDC already has the
255 The trustedCertifiers field contains a list of certification
256 authorities trusted by the client, in the case that the client does
257 not possess the KDC's public key certificate.
259 Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
260 type, the KDC attempts to verify the user's certificate chain
261 (userCert), if one is provided in the request. This is done by
262 verifying the certification path against the KDC's policy of
263 legitimate certifiers. This may be based on a certification
264 hierarchy, or it may be simply a list of recognized certifiers in a
265 system like PGP. If the certification path does not match one of
266 the KDC's trusted certifiers, the KDC sends back an error message of
267 type KDC_ERROR_CLIENT_NOT_TRUSTED, and it includes in the error data
268 field a list of its own trusted certifiers, upon which the client
271 If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC
272 verifies that it has a certificate issued by one of the certifiers
273 trusted by the client. If it does not have a suitable certificate,
274 the KDC returns an error message of type KDC_ERROR_KDC_NOT_TRUSTED
277 If a trust relationship exists, the KDC then verifies the client's
278 signature on PKAuthenticator. If that fails, the KDC returns an
279 error message of type KDC_ERROR_INVALID_SIG. Otherwise, the KDC
280 uses the timestamp in the PKAuthenticator to assure that the request
281 is not a replay. The KDC also verifies that its name is specified
284 Assuming no errors, the KDC replies as per RFC 1510, except that it
285 encrypts the reply not with the user's key, but with a random key
286 generated only for this particular response. This random key
287 is sealed in the preauthentication field:
289 PA-PK-AS-REP ::= SEQUENCE {
291 kdcCert [0] SEQUENCE OF Certificate OPTIONAL,
292 -- the KDC's certificate
293 -- optionally followed by that
294 -- certificate's certifier chain
295 encPaReply [1] EncryptedData,
297 -- using either the client public
298 -- key or the Diffie-Hellman key
299 -- specified by SignedDHPublicValue
300 signedDHPublicValue [2] SignedDHPublicValue OPTIONAL
304 PaReply ::= SEQUENCE {
305 replyEncKeyPack [0] ReplyEncKeyPack,
306 replyEncKeyPackSig [1] Signature,
307 -- of replyEncKeyPack
308 -- using KDC's signature key
311 ReplyEncKeyPack ::= SEQUENCE {
312 replyEncKey [0] EncryptionKey,
313 -- used to encrypt main reply
315 -- binds response to the request
316 -- passed in the PKAuthenticator
319 SignedDHPublicValue ::= SEQUENCE {
320 dhPublicValue [0] SubjectPublicKeyInfo,
321 dhPublicValueSig [1] Signature
323 -- using KDC's signature key
326 The kdcCert field is a sequence of certificates, the first of which
327 must have as its root certifier one of the certifiers sent to the
328 KDC in the PA-PK-AS-REQ. Any subsequent certificates will be
329 certificates of the certifiers of the KDC's certificate. These
330 cerificates may be used by the client to verify the KDC's public
331 key. This field is empty if the client did not send to the KDC a
332 list of trusted certifiers (the trustedCertifiers field was empty).
334 Since each certifier in the certification path of a user's
335 certificate is essentially a separate realm, the name of each
336 certifier shall be added to the transited field of the ticket. The
337 format of these realm names shall follow the naming constraints set
338 forth in RFC 1510 (sections 7.1 and 3.3.3.1). Note that this will
339 require new nametypes to be defined for PGP certifiers and other
340 types of realms as they arise.
342 The KDC's certificate must bind the public key to a name derivable
343 from the name of the realm for that KDC. The client then extracts
344 the random key used to encrypt the main reply. This random key (in
345 encPaReply) is encrypted with either the client's public key or
346 with a key derived from the DH values exchanged between the client
350 3.3. Digital Signature
352 Implementation of the changes in this section are OPTIONAL for
353 compliance with pk-init.
355 We offer this option with the warning that it requires the client to
356 generate a random key; the client may not be able to guarantee the
357 same level of randomness as the KDC.
359 If the user registered a digital signature key with the KDC instead
360 of an encryption key, then a separate exchange must be used. The
361 client sends a request for a TGT as usual, except that it (rather
362 than the KDC) generates the random key that will be used to encrypt
363 the KDC response. This key is sent to the KDC along with the
364 request in a preauthentication field:
366 PA-PK-AS-SIGN ::= SEQUENCE {
368 encSignedKeyPack [0] EncryptedData
370 -- using the KDC's public key
373 SignedKeyPack ::= SEQUENCE {
374 signedKey [0] KeyPack,
375 signedKeyAuth [1] PKAuthenticator,
376 signedKeySig [2] Signature
377 -- of signedKey.signedKeyAuth
378 -- using user's signature key
381 KeyPack ::= SEQUENCE {
382 randomKey [0] EncryptionKey,
383 -- will be used to encrypt reply
387 where the nonce is copied from the request.
389 Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies
390 the randomKey. It then replies as per RFC 1510, except that the
391 reply is encrypted not with a password-derived user key, but with
392 the randomKey sent in the request. Since the client already knows
393 this key, there is no need to accompany the reply with an extra
394 preauthentication field. The transited field of the ticket should
395 specify the certification path as described in Section 3.2.
398 3.4. Retrieving the Private Key From the KDC
400 Implementation of the changes in this section is RECOMMENDED for
401 compliance with pk-init.
403 When the user's private key is not stored local to the user, he may
404 choose to store the private key (normally encrypted using a
405 password-derived key) on the KDC. We provide this option to present
406 the user with an alternative to storing the private key on local
407 disk at each machine where he expects to authenticate himself using
408 pk-init. It should be noted that it replaces the added risk of
409 long-term storage of the private key on possibly many workstations
410 with the added risk of storing the private key on the KDC in a
411 form vulnerable to brute-force attack.
413 In order to obtain a private key, the client includes a
414 preauthentication field with the AS-REQ message:
416 PA-PK-KEY-REQ ::= SEQUENCE {
418 patimestamp [0] KerberosTime OPTIONAL,
419 -- used to address replay attacks.
420 pausec [1] INTEGER OPTIONAL,
421 -- used to address replay attacks.
423 -- binds the reply to this request
424 privkeyID [3] SEQUENCE OF KeyID OPTIONAL
425 -- constructed as a hash of
426 -- public key corresponding to
427 -- desired private key
431 KeyIdentifier [0] OCTET STRING
434 The client may request a specific private key by sending the
435 corresponding ID. If this field is left empty, then all
436 private keys are returned.
438 If all checks out, the KDC responds as described in the above
439 sections, except that an additional preauthentication field,
440 containing the user's private key, accompanies the reply:
442 PA-PK-KEY-REP ::= SEQUENCE {
445 -- binds the reply to the request
446 KeyData [1] SEQUENCE OF KeyPair
449 KeyPair ::= SEQUENCE {
450 privKeyID [0] OCTET STRING,
451 -- corresponding to encPrivKey
452 encPrivKey [1] OCTET STRING
456 3.4.1. Additional Protection of Retrieved Private Keys
458 We solicit discussion on the following proposal: that the client may
459 optionally include in its request additional data to encrypt the
460 private key, which is currently only protected by the user's
461 password. One possibility is that the client might generate a
462 random string of bits, encrypt it with the public key of the KDC (as
463 in the SignedKeyPack, but with an ordinary OCTET STRING in place of
464 an EncryptionKey), and include this with the request. The KDC then
465 XORs each returned key with this random bit string. (If the bit
466 string is too short, the KDC could either return an error, or XOR
467 the returned key with a repetition of the bit string.)
469 In order to make this work, additional means of preauthentication
470 need to be devised in order to prevent attackers from simply
471 inserting their own bit string. One way to do this is to store
472 a hash of the password-derived key (the one used to encrypt the
473 private key). This hash is then used in turn to derive a second
474 key (called the hash-key); the hash-key is used to encrypt an ASN.1
475 structure containing the generated bit string and a nonce value
476 that binds it to the request.
478 Since the KDC possesses the hash, it can generate the hash-key and
479 verify this (weaker) preauthentication, and yet cannot reproduce
480 the private key itself, since the hash is a one-way function.
483 4. Logistics and Policy Issues
485 We solicit discussion on how clients and KDCs should be configured
486 in order to determine which of the options described above (if any)
487 should be used. One possibility is to set the user's database
488 record to indicate that authentication is to use public key
489 cryptography; this will not work, however, in the event that the
490 client needs to know before making the initial request.
492 5. Compatibility with One-Time Passcodes
494 We solicit discussion on how the protocol changes proposed in this
495 draft will interact with the proposed use of one-time passcodes
496 discussed in draft-ietf-cat-kerberos-passwords-00.txt.
499 6. Strength of Cryptographic Schemes
501 In light of recent findings on the strength of MD5 and DES,
502 we solicit discussion on which encryption types to incorporate
503 into the protocol changes.
508 [1] J. Kohl, C. Neuman. The Kerberos Network Authentication
509 Service (V5). Request for Comments: 1510
511 [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
512 for Computer Networks, IEEE Communications, 32(9):33-38.
515 [3] A. Medvinsky, M. Hur. Addition of Kerberos Cipher Suites to
516 Transport Layer Security (TLS).
517 draft-ietf-tls-kerb-cipher-suites-00.txt
519 [4] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing
520 Tickets for Application Servers (PKTAPP).
521 draft-ietf-cat-pktapp-00.txt
523 [5] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos Using
524 Public Key Cryptography. Symposium On Network and Distributed System
527 [6] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction
528 Protocol. In Proceedings of the USENIX Workshop on Electronic Commerce,
531 [7] Alan O. Freier, Philip Karlton and Paul C. Kocher.
532 The SSL Protocol, Version 3.0 - IETF Draft.
534 [8] B.C. Neuman, Proxy-Based Authorization and Accounting for
535 Distributed Systems. In Proceedings of the 13th International
536 Conference on Distributed Computing Systems, May 1993
538 [9] ITU-T (formerly CCITT)
539 Information technology - Open Systems Interconnection -
540 The Directory: Authentication Framework Recommendation X.509
546 Some of the ideas on which this proposal is based arose during
547 discussions over several years between members of the SAAG, the IETF
548 CAT working group, and the PSRG, regarding integration of Kerberos
549 and SPX. Some ideas have also been drawn from the DASS system.
550 These changes are by no means endorsed by these groups. This is an
551 attempt to revive some of the goals of those groups, and this
552 proposal approaches those goals primarily from the Kerberos
553 perspective. Lastly, comments from groups working on similar ideas
554 in DCE have been invaluable.
559 This draft expires September 30, 1997.
566 USC Information Sciences Institute
567 4676 Admiralty Way Suite 1001
568 Marina del Rey CA 90292-6695
569 Phone: +1 310 822 1511
570 E-mail: {bcn, brian}@isi.edu
573 Digital Equipment Corporation
574 550 King Street, LKG2-2/Z7
576 Phone: +1 508 486 5210
577 E-mail: wray@tuxedo.enet.dec.com
581 CyberSafe Corporation
582 1605 NW Sammamish Road Suite 310
583 Issaquah WA 98027-5378
584 Phone: +1 206 391 6000
585 E-mail: {ari.medvinsky, matt.hur}@cybersafe.com
589 E-mail: jonathan.trostle@novell.com