idnits 2.17.1 draft-ietf-cat-kerberos-pk-init-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 615 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 34 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 224: '... cksum[0] Checksum OPTIONAL,...' RFC 2119 keyword, line 234: '... kvno[1] INTEGER OPTIONAL,...' RFC 2119 keyword, line 324: '... issuerUniqueID[8] IMPLICIT UniqueIdentifier OPTIONAL,...' RFC 2119 keyword, line 325: '... subjectUniqueID[9] IMPLICIT UniqueIdentifier OPTIONAL,...' RFC 2119 keyword, line 350: '...e changes in this section is OPTIONAL....' (2 more instances...) == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC1510, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 11 has weird spacing: '...-Drafts are ...' == Line 17 has weird spacing: '... months and ...' == Line 18 has weird spacing: '...-Drafts as...' == Line 19 has weird spacing: '...ference mater...' == Line 28 has weird spacing: '...tion of this ...' == (1 more instance...) (Using the creation date from RFC1510, updated by this document, for RFC5378 checks: 1993-09-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '0' on line 525 looks like a reference -- Missing reference section? '1' on line 526 looks like a reference -- Missing reference section? '2' on line 318 looks like a reference -- Missing reference section? '3' on line 319 looks like a reference -- Missing reference section? '4' on line 320 looks like a reference -- Missing reference section? '5' on line 321 looks like a reference -- Missing reference section? '6' on line 322 looks like a reference -- Missing reference section? '7' on line 323 looks like a reference -- Missing reference section? '8' on line 324 looks like a reference -- Missing reference section? '9' on line 325 looks like a reference -- Missing reference section? '10' on line 326 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 9 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Clifford Neuman 2 draft-ietf-cat-kerberos-pk-init-01.txt Brian Tung 3 Updates: RFC 1510 ISI 4 expires December 7, 1996 John Wray 5 Digital Equipment Corporation 7 Public Key Cryptography for Initial Authentication in Kerberos 9 0. Status Of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other docu- 18 ments at any time. It is inappropriate to use Internet-Drafts as 19 reference material or to cite them other than as ``work in pro- 20 gress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Sha- 24 dow Directories on ds.internic.net (US East Coast), nic.nordu.net 25 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 26 Rim). 28 The distribution of this memo is unlimited. It is filed as 29 draft-ietf-cat-kerberos-pk-init-01.txt, and expires December 7, 1996. 30 Please send comments to the authors. 32 1. Abstract 34 This document defines extensions to the Kerberos protocol specifi- 35 cation (RFC 1510, "The Kerberos Network Authentication Service 36 (V5)", September 1993) to provide a method for using public key 37 cryptography during initial authentication. The method defined 38 specifies the way in which preauthentication data fields and error 39 data fields in Kerberos messages are to be used to transport public 40 key data. 42 2. Motivation 44 Public key cryptography presents a means by which a principal may 45 demonstrate possession of a key, without ever having divulged this 46 key to anyone else. In conventional cryptography, the encryption key 47 and decryption key are either identical or can easily be derived from 48 one another. In public key cryptography, however, neither the public 49 key nor the private key can be derived from the other (although the 50 private key RECORD may include the information required to generate 51 BOTH keys). Hence, a message encrypted with a public key is private, 52 since only the person possessing the private key can decrypt it; 53 similarly, someone possessing the private key can also encrypt a 54 message, thus providing a digital signature. 56 Furthermore, conventional keys are often derived from passwords, so 57 messages encrypted with these keys are susceptible to dictionary 58 attacks, whereas public key pairs are generated from a pseudo-random 59 number sequence. While it is true that messages encrypted using 60 public key cryptography are actually encrypted with a conventional 61 secret key, which is in turn encrypted using the public key pair, 62 the secret key is also randomly generated and is hence not vulnerable 63 to a dictionary attack. 65 The advantages provided by public key cryptography have produced a 66 demand for its integration into the Kerberos authentication protocol. 67 The primary advantage of registering public keys with the KDC lies in 68 the ease of recovery in case the KDC is compromised. With Kerberos as 69 it currently stands, compromise of the KDC is disastrous. All 70 keys become known by the attacker and all keys must be changed. 72 If users register public keys, compromise of the KDC does not divulge 73 their private key. Compromise of security on the KDC is still a 74 problem, since an attacker can impersonate any user by certifying a 75 bogus key with the KDC's private key. However, all bogus 76 certificates can be invalidated by revoking and changing the 77 KDC's public key. Legitimate users have to re-certify their public 78 keys with the new KDC key, but the users's keys themselves do not 79 need to be changed. Keys for application servers are conventional 80 symmetric keys and must be changed. 82 Note: If a user stores his private key, in an encrypted form, on the 83 KDC, then he does have to change the key pair, since the private key 84 is encrypted using a symmetric key derived from a password (as 85 described below), and is therefore vulnerable to dictionary attack. 86 Assuming good password policy, however, legitimate users may be 87 allowed to use the old password for a limited time, solely for the 88 purpose of changing the key pair. The realm administrator is then 89 not forced to re-key all users. 91 There are two important areas where public key cryptography will have 92 immediate use: in the initial authentication of users registered with 93 the KDC or using public key certificates from outside authorities, 94 and to establish inter-realm keys for cross-realm authentication. 95 This memo describes a method by which the first of these can be done. 96 The second case will be the topic for a separate proposal. 98 Some of the ideas on which this proposal is based arose during 99 discussions over several years between members of the SAAG, the 100 IETF-CAT working group, and the PSRG, regarding integration of 101 Kerberos and SPX. Some ideas are drawn from the DASS system, and 102 similar extensions have been discussed for use in DCE. These changes 103 are by no means endorsed by these groups. This is an attempt to 104 revive some of the goals of that group, and the proposal approaches 105 those goals primarily from the Kerberos perspective. 107 3. Initial authentication of users with public keys 109 This section describes the extensions to Version 5 of the Kerberos 110 protocol that will support the use of public key cryptography by 111 users in the initial request for a ticket granting ticket. This 112 proposal is based on the implementation already made available; 113 nevertheless, we solicit any comments on modifications or additions 114 to the protocol description below. 116 Roughly speaking, the following changes to RFC 1510 are proposed: 117 a. The KDC's response is encrypted using a random nonce key, 118 rather than the user's secret key. 119 b. This random key accompanies the response in a 120 preauthentication field, encrypted and signed using the 121 public key pairs of the user and the KDC. 122 Certificate and message formats are also defined in this section. 124 This proposal will allow users either to use keys registered directly 125 with the KDC, or to use keys already registered for use with X.509, 126 PEM, or PGP, to obtain Kerberos credentials. These credentials can 127 then be used, as before, with application servers supporting Kerberos. 128 Use of public key cryptography will not be a requirement for Kerberos, 129 but if one's organization runs a KDC supporting public key, then users 130 may choose to be registered with a public key pair, instead of the 131 current secret key. 133 The application request and response between Kerberos clients and 134 application servers will continue to be based on conventional 135 cryptography, or will be converted to use user-to-user 136 authentication. There are performance issues and other reasons 137 that servers may be better off using conventional cryptography. 138 For this proposal, we feel that 80 percent of the benefits of 139 integrating public key with Kerberos can be attained for 20 percent 140 of the effort, by addressing only initial authentication. This 141 proposal does not preclude separate extensions. 143 With these changes, users will be able to register public keys, only 144 in realms that support public key, and they will then only be able 145 to perform initial authentication from a client that supports public key, 146 although they will be able to use services registered in any realm. 147 Furthermore, users registered with conventional keys will be able 148 to use any client. 150 This proposal addresses three ways in which users may use public key 151 cryptography for initial authentication with Kerberos, with minimal 152 change to the existing protocol. Users may register keys directly 153 with the KDC, or they may present certificates by outside certification 154 authorities (or certifications by other users) attesting to the 155 association of the public key with the named user. In both cases, 156 the end result is that the user obtains a conventional ticket 157 granting ticket or conventional server ticket that may be used for 158 subsequent authentication, with such subsequent authentication using 159 only conventional cryptography. 161 Additionally, users may also register a digital signature key with 162 the KDC. We provide this option for the licensing benefits, as well 163 as a simpler variant of the initial authentication exchange. However, 164 this option relies on the client to generate random keys. 166 We first consider the case where the user's key is registered with 167 the KDC. 169 3.1 Definitions 171 Before we proceed, we will lay some groundwork definitions for 172 encryption and signatures. We propose the following definitions 173 of signature and encryption modes (and their corresponding values 174 on the wire): 176 #define ENCTYPE_SIGN_MD5_RSA 0x0011 178 #define ENCTYPE_ENCRYPT_RSA_PRIV 0x0021 179 #define ENCTYPE_ENCRYPT_RSA_PUB 0x0022 181 allowing further modes to be defined accordingly. 183 In the exposition below, we will use the notation E (T, K) to denote 184 the encryption of data T, with key (or parameters) K. 186 If E is ENCTYPE_SIGN_MD5_RSA, then 188 E (T, K) = {T, RSAEncryptPrivate (MD5Hash (T), K)} 190 If E is ENCTYPE_ENCRYPT_RSA_PRIV, then 192 E (T, K) = RSAEncryptPrivate (T, K) 194 Correspondingly, if E is ENCTYPE_ENCRYPT_RSA_PUB, then 196 E (T, K) = RSAEncryptPublic (T, K) 198 3.2 Initial request for user registered with public key on KDC 200 In this scenario it is assumed that the user is registered with a 201 public key on the KDC. The user's private key may be held by the 202 user, or it may be stored on the KDC, encrypted so that it cannot be 203 used by the KDC. 205 3.2.1 User's private key is stored locally 207 If the user stores his private key locally, the initial request to 208 the KDC for a ticket granting ticket proceeds according to RFC 1510, 209 except that a preauthentication field containing a nonce signed by 210 the user's private key is included. The preauthentication field 211 may also include a list of the root certifiers trusted by the user. 213 PA-PK-AS-ROOT ::= SEQUENCE { 214 rootCert[0] SEQUENCE OF OCTET STRING, 215 signedAuth[1] SignedPKAuthenticator 216 } 218 SignedPKAuthenticator ::= SEQUENCE { 219 authent[0] PKAuthenticator, 220 authentSig[1] Signature 221 } 223 PKAuthenticator ::= SEQUENCE { 224 cksum[0] Checksum OPTIONAL, 225 cusec[1] INTEGER, 226 ctime[2] KerberosTime, 227 nonce[3] INTEGER, 228 kdcRealm[4] Realm, 229 kdcName[5] PrincipalName 230 } 232 Signature ::= SEQUENCE { 233 sigType[0] INTEGER, 234 kvno[1] INTEGER OPTIONAL, 235 sigHash[2] OCTET STRING 236 } 238 Notationally, sigHash is then 240 sigType (authent, userPrivateKey) 242 where userPrivateKey is the user's private key (corresponding to the 243 public key held in the user's database record). Valid sigTypes are 244 thus far limited to the above-listed ENCTYPE_SIGN_MD5_RSA; we expect 245 that other types may be listed (and given on-the-wire values between 246 0x0011 and 0x001f). 248 The format of each certificate depends on the particular 249 service used. (Alternatively, the KDC could send, with its reply, 250 a sequence of certifications (see below), but since the KDC is likely 251 to have more certifications than users have trusted root certifiers, 252 we have chosen the first method.) In the event that the client 253 believes it already possesses the current public key of the KDC, 254 a zero-length root-cert field is sent. 256 The fields in the signed authenticator are the same as those 257 in the Kerberos authenticator; in addition, we include a client- 258 generated nonce, and the name of the KDC. The structure is itself 259 signed using the user's private key corresponding to the public key 260 registered with the KDC. 262 Typically, preauthentication using a secret key would not be included, 263 but if included it may be ignored by the KDC. (We recommend that it 264 not be included: even if the KDC should ignore the preauthentication, 265 an attacker may not, and use an intercepted message to guess the 266 password off-line.) 268 The response from the KDC would be identical to the response in RFC 1510, 269 except that instead of being encrypted in the secret key shared by the 270 client and the KDC, it is encrypted in a random key freshly generated 271 by the KDC (of type ENCTYPE_ENC_CBC_CRC). A preauthentication field 272 (specified below) accompanies the response, optionally containing a 273 certificate with the public key for the KDC (since we do not assume 274 that the client knows this public key), and a package containing the 275 secret key in which the rest of the response is encrypted, along with 276 the same nonce used in the rest of the response, in order to prevent 277 replays. This package is itself encrypted with the private key of the 278 KDC, then encrypted with the public key of the user. 280 PA-PK-AS-REP ::= SEQUENCE { 281 kdcCert[0] SEQUENCE OF Certificate, 282 encryptShell[1] EncryptedData, -- EncPaPkAsRepPartShell 283 -- encrypted by encReplyTmpKey 284 encryptKey[2] EncryptedData -- EncPaPkAsRepTmpKey 285 -- encrypted by userPubliKey 286 } 288 EncPaPkAsRepPartShell ::= SEQUENCE { 289 encReplyPart[0] EncPaPkAsRepPart, 290 encReplyPartSig[1] Signature -- encReplyPart 291 -- signed by kdcPrivateKey 292 } 294 EncPaPkAsRepPart ::= SEQUENCE { 295 encReplyKey[0] EncryptionKey, 296 nonce[1] INTEGER 297 } 299 EncPaPkAsRepTmpKey ::= SEQUENCE { 300 encReplyTmpKey[0] EncryptionKey 301 } 303 Notationally, assume that encryptPack is encrypted (or signed) with 304 algorithm Ak, and that encryptShell is encrypted with algorithm Au. 305 Then, encryptShell is 307 Au (Ak ({encReplyKey, nonce}, kdcPrivateKey), userPublicKey) 309 where kdcPrivateKey is the KDC's private key, and userPublicKey is the 310 user's public key. 312 The kdc-cert specification is lifted, with slight modifications, 313 from v3 of the X.509 certificate specification: 315 Certificate ::= SEQUENCE { 316 version[0] Version DEFAULT v1 (1), 317 serialNumber[1] CertificateSerialNumber, 318 signature[2] AlgorithmIdentifier, 319 issuer[3] PrincipalName, 320 validity[4] Validity, 321 subjectRealm[5] Realm, 322 subject[6] PrincipalName, 323 subjectPublicKeyInfo[7] SubjectPublicKeyInfo, 324 issuerUniqueID[8] IMPLICIT UniqueIdentifier OPTIONAL, 325 subjectUniqueID[9] IMPLICIT UniqueIdentifier OPTIONAL, 326 authentSig[10] Signature 327 } 329 The kdc-cert must have as its root certification one of the certifiers 330 sent to the KDC with the original request. If the KDC has no such 331 certification, then it will instead reply with a KRB_ERROR of type 332 KDC_ERROR_PREAUTH_FAILED. If a zero-length root-cert was sent by the 333 client as part of the PA-PK-AS-ROOT, then a correspondingly zero-length 334 kdc-cert may be absent, in which case the client uses its copy of the 335 KDC's public key. 337 Upon receipt of the response from the KDC, the client will verify the 338 public key for the KDC from PA-PK-AS-REP preauthentication data field, 339 The certificate must certify the key as belonging to a principal whose 340 name can be derived from the realm name. If the certificate checks 341 out, the client then decrypts the EncPaPkAsRepPart using the private 342 key of the user, and verifies the signature of the KDC. It then uses 343 the random key contained therein to decrypt the rest of the response, 344 and continues as per RFC 1510. Because there is direct trust between 345 the user and the KDC, the transited field of the ticket returned by 346 the KDC should remain empty. (Cf. Section 3.3.) 348 3.2.2. Private key held by KDC 350 Implementation of the changes in this section is OPTIONAL. 352 When the user's private key is not carried with the user, the user may 353 encrypt the private key using conventional cryptography, and register 354 the encrypted private key with the KDC. The MD5 hash of the DES key 355 used to encrypt the private key must also be registered with the KDC. 357 We provide this option with the warning that storing the private key 358 on the KDC carries the risk of exposure in case the KDC is compromised. 359 If a suffiently good password is chosen to encrypt the key, then this 360 password can be used for a limited time to change the private key. 361 If the user wishes to authenticate himself without storing the private 362 key on each local disk, then a safer, albeit possibly less practical, 363 alternative is to use a smart card to store the keys. 365 When the user's private key is stored on the KDC, the KDC record 366 will also indicate whether preauthentication is required before 367 returning the key (we recommend that it be required). If such 368 preauthentication is required, when the initial request is received, 369 the KDC will respond with a KRB_ERROR message, with msg-type set 370 to KDC_ERR_PREAUTH_REQUIRED, and e-data set to: 372 PA-PK-AS-INFO ::= SEQUENCE { 373 kdcCert[0] SEQUENCE OF Certificate 374 } 376 The kdc-cert field is identical to that in the PA-PK-AS-REP 377 preauthentication data field returned with the KDC response, and must 378 be validated as belonging to the KDC in the same manner. 380 Upon receipt of the KRB_ERROR message with a PA-PK-AS-INFO field, the 381 client will prompt the user for the password that was used to 382 encrypt the private key, derive the DES key from that password, 383 and calculate the MD5 hash H1 of the DES key. The client then sends 384 a request to the KDC, which includes a timestamp and a 385 client-generated random secret key that will be used by the KDC 386 to super-encrypt the encrypted private key before it is returned 387 to the client. This information is sent to the KDC in a subsequent 388 AS_REQ message in a preauthentication data field: 390 PA-PK-AS-REQ ::= SEQUENCE { 391 encHashShell[0] EncryptedData -- EncPaPkAsReqShell 392 } 394 EncPaPkAsReqShell ::= SEQUENCE { 395 encHashPart[0] EncryptedData -- EncPaPkAsReqPart 396 } 398 EncPaPkAsReqPart ::= SEQUENCE { 399 encHashKey[0] EncryptionKey, 400 nonce[1] INTEGER 401 } 403 The EncPaPkAsReqPart is first encrypted with a DES key K1, derived 404 by string_to_key from the hash H1 (with null salt), then encrypted 405 again with the KDC's public key from the certificate in the 406 PA-PK-AS-INFO field of the error response. 408 Notationally, if encryption algorithm A is used for DES encryption, 409 and Ak is used for the public key encryption, then enc-shell is 411 Ak (A ({encHashKey, nonce}, K1), kdcPublicKey) 413 Upon receipt of the authentication request with the PA-PK-AS-REQ, the 414 KDC verifies the hash of the user's DES encryption key by attempting 415 to decrypt the EncPaPkAsReqPart of the PA-PK-AS-REQ. If decryption 416 is successful, the KDC generates the AS response as defined in 417 RFC 1510, but additionally includes a preauthentication field of type 418 PA-PK-USER-KEY. (This response will also be included in response to 419 the initial request without preauthentication if preauthentication is 420 not required for the user and the user's encrypted private key is 421 stored on the KDC.) 423 PA-PK-USER-KEY ::= SEQUENCE { 424 encUserKeyPart[0] EncryptedData -- EncPaPkUserKeyPart 425 } 427 EncPaPkUserKeyPart ::= SEQUENCE { 428 encUserKey[0] OCTET STRING, 429 nonce[1] INTEGER 430 } 432 Notationally, if encryption algorithm A is used, then enc-key-part is 434 A ({encUserKey, nonce}, enc-hash-key) 436 (where A could be null encryption). 438 This message contains the encrypted private key that has been 439 registered with the KDC by the user, as encrypted by the user, 440 optionally super-encrypted with the enc-hash-key from the PA-PK-AS-REQ 441 message if preauthentication using that method was provided (otherwise, 442 the EncryptedData should denote null encryption). Note that since 443 H1 is a one-way hash, it is not possible for one to decrypt the 444 message if one possesses H1 but not the DES key that H1 is derived 445 from. Because there is direct trust between the user and the 446 KDC, the transited field of the ticket returned by the KDC should 447 remain empty. (Cf. Section 3.3.) 449 3.3. Clients with a public key certified by an outside authority 451 Implementation of the changes in this section is OPTIONAL. 453 In the case where the client is not registered with the current KDC, 454 the client is responsible for obtaining the private key on its own. 455 The client will request initial tickets from the KDC using the TGS 456 exchange, but instead of performing pre-authentication using a 457 Kerberos ticket granting ticket, or with the PA-PK-AS-REQ that is used 458 when the public key is known to the KDC, the client performs 459 preauthentication using the preauthentication data field of type 460 PA-PK-AS-EXT-CERT: 462 PA-PK-AS-EXT-CERT ::= SEQUENCE { 463 userCert[0] SEQUENCE OF OCTET STRING, 464 signedAuth[1] SignedPKAuthenticator 465 } 467 where the user-cert specification depends on the type of certificate 468 that the user possesses. In cases where the service has separate 469 key pairs for digital signature and for encryption, we recommend 470 that the signature keys be used for the purposes of sending the 471 preauthentication (and deciphering the response). 473 The authenticator is the one used from the exchange in section 3.2.1, 474 except that it is signed using the private key corresponding to 475 the public key in the user-cert. 477 The KDC will verify the preauthentication authenticator, and check the 478 certification path against its own policy of legitimate certifiers. 479 This may be based on a certification hierarchy, or simply a list of 480 recognized certifiers in a system like PGP. 482 If all checks out, the KDC will issue Kerberos credentials, as in 3.2, 483 but with the names of all the certifiers in the certification path 484 added to the transited field of the ticket, with a principal name 485 taken from the certificate (this might be a long path for X.509, or a 486 string like "John Q. Public " if the certificate 487 was a PGP certificate. The realm will identify the kind of 488 certificate and the final certifier as follows: 490 cert_type/final_certifier 492 as in PGP/. 494 3.4. Digital Signature 496 Implementation of the changes in this section is OPTIONAL. 498 We offer this option with the warning that it requires the client 499 process to generate a random DES key; this generation may not 500 be able to guarantee the same level of randomness as the KDC. 502 If a user registered a digital signature key pair with the KDC, 503 a separate exchange may be used. The client sends a KRB_AS_REQ as 504 described in section 3.2.2. If the user's database record 505 indicates that a digital signature key is to be used, then the 506 KDC sends back a KRB_ERROR as in section 3.2.2. 508 It is assumed here that the signature key is stored on local disk. 509 The client generates a random key of enctype ENCTYPE_DES_CBC_CRC, 510 signs it using the signature key (otherwise the signature is 511 performed as described in section 3.2.1), then encrypts the whole with 512 the public key of the KDC. This is returned with a separate KRB_AS_REQ 513 in a preauthentication of type 515 PA-PK-AS-SIGNED ::= SEQUENCE { 516 signedKey[0] EncryptedData -- PaPkAsSignedData 517 } 519 PaPkAsSignedData ::= SEQUENCE { 520 signedKeyPart[0] SignedKeyPart, 521 signedKeyAuth[1] PKAuthenticator 522 } 524 SignedKeyPart ::= SEQUENCE { 525 encSignedKey[0] EncryptionKey, 526 nonce[1] INTEGER 527 } 529 where the nonce is the one from the request. Upon receipt of the 530 request, the KDC decrypts, then verifies the random key. It then 531 replies as per RFC 1510, except that instead of being encrypted 532 with the password-derived DES key, the reply is encrypted using 533 the randomKey sent by the client. Since the client already knows 534 this key, there is no need to accompany the reply with an extra 535 preauthentication field. Because there is direct trust between 536 the user and the KDC, the transited field of the ticket returned 537 by the KDC should remain empty. (Cf. Section 3.3.) 539 4. Preauthentication Data Types 541 We propose that the following preauthentication types be allocated 542 for the preauthentication data packages described in this draft: 544 #define KRB5_PADATA_ROOT_CERT 17 /* PA-PK-AS-ROOT */ 545 #define KRB5_PADATA_PUBLIC_REP 18 /* PA-PK-AS-REP */ 546 #define KRB5_PADATA_PUBLIC_REQ 19 /* PA-PK-AS-REQ */ 547 #define KRB5_PADATA_PRIVATE_REP 20 /* PA-PK-USER-KEY */ 548 #define KRB5_PADATA_PUBLIC_EXT 21 /* PA-PK-AS-EXT-CERT */ 549 #define KRB5_PADATA_PUBLIC_SIGN 22 /* PA-PK-AS-SIGNED */ 551 5. Encryption Information 553 For the public key cryptography used in direct registration, we used 554 (in our implementation) the RSAREF library supplied with the PGP 2.6.2 555 release. Encryption and decryption functions were implemented directly 556 on top of the primitives made available therein, rather than the 557 fully sealing operations in the API. 559 6. Compatibility with One-Time Passcodes 561 We solicit discussion on how the use of public key cryptography for initial 562 authentication will interact with the proposed use of one time passwords 563 discussed in Internet Draft . 565 7. Strength of Encryption and Signature Mechanisms 567 In light of recent findings on the strengths of MD5 and various DES 568 modes, we solicit discussion on which modes to incorporate into the 569 protocol changes. 571 8. Expiration 573 This Internet-Draft expires on December 7, 1996. 575 9. Authors' Addresses 577 B. Clifford Neuman 578 USC/Information Sciences Institute 579 4676 Admiralty Way Suite 1001 580 Marina del Rey, CA 90292-6695 582 Phone: 310-822-1511 583 EMail: bcn@isi.edu 585 Brian Tung 586 USC/Information Sciences Institute 587 4676 Admiralty Way Suite 1001 588 Marina del Rey, CA 90292-6695 590 Phone: 310-822-1511 591 EMail: brian@isi.edu 593 John Wray 594 Digital Equipment Corporation 595 550 King Street, LKG2-2/Z7 596 Littleton, MA 01460 598 Phone: 508-486-5210 599 EMail: wray@tuxedo.enet.dec.com