1INTERNET-DRAFT Brian Tung 2draft-ietf-cat-kerberos-pk-init-05.txt Clifford Neuman 3Updates: RFC 1510 ISI 4expires May 26, 1998 John Wray 5 Digital Equipment Corporation 6 Ari Medvinsky 7 Matthew Hur 8 CyberSafe Corporation 9 Jonathan Trostle 10 Novell 11 12 13 Public Key Cryptography for Initial Authentication in Kerberos 14 15 160. Status Of This Memo 17 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. 22 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 27 progress." 28 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). 34 35 The distribution of this memo is unlimited. It is filed as 36 draft-ietf-cat-kerberos-pk-init-05.txt, and expires May 26, 1998. 37 Please send comments to the authors. 38 39 401. Abstract 41 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 47 public key data. 48 49 502. Introduction 51 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. 57 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. 64 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. 71 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 80 fields. 81 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. 85 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 95 delegation (see [8]). 96 97 983. Proposed Extensions 99 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). 103 104 In summary, the following changes to RFC 1510 are proposed: 105 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. 112 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. 120 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. 126 127 1283.1. Definitions 129 130 The extensions involve new encryption methods; we propose the 131 addition of the following types: 132 133 dsa-sign 8 134 rsa-priv 9 135 rsa-pub 10 136 rsa-pub-md5 11 137 rsa-pub-sha1 12 138 139 The proposal of these encryption types notwithstanding, we do not 140 mandate the use of any particular public key encryption method. 141 142 The extensions involve new preauthentication fields; we propose the 143 addition of the following types: 144 145 PA-PK-AS-REQ 14 146 PA-PK-AS-REP 15 147 PA-PK-AS-SIGN 16 148 PA-PK-KEY-REQ 17 149 PA-PK-KEY-REP 18 150 151 The extensions also involve new error types; we propose the addition 152 of the following types: 153 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 159 160 In many cases, PKINIT requires the encoding of an X.500 name as a 161 Realm. In these cases, the realm will be represented using a 162 different style, specified in RFC 1510 with the following example: 163 164 NAMETYPE:rest/of.name=without-restrictions 165 166 For a realm derived from an X.500 name, NAMETYPE will have the value 167 X500-RFC1779. The full realm name will appear as follows: 168 169 X500-RFC1779:RFC1779Encode(DistinguishedName) 170 171 where DistinguishedName is an X.500 name, and RFC1779Encode is a 172 readable ASCII encoding of an X.500 name, as defined by RFC 1779. 173 To ensure that this encoding is unique, we add the following rules 174 to those specified by RFC 1779: 175 176 * The optional spaces specified in RFC 1779 are not allowed. 177 * The character that separates relative distinguished names 178 must be ',' (i.e., it must never be ';'). 179 * Attribute values must not be enclosed in double quotes. 180 * Attribute values must not be specified as hexadecimal 181 numbers. 182 * When an attribute name is specified in the form of an OID, 183 it must start with the 'OID.' prefix, and not the 'oid.' 184 prefix. 185 * The order in which the attributes appear in the RFC 1779 186 encoding must be the reverse of the order in the ASN.1 187 encoding of the X.500 name that appears in the public key 188 certificate, because RFC 1779 requires that the least 189 significant relative distinguished name appear first. The 190 order of the relative distinguished names, as well as the 191 order of the attributes within each relative distinguished 192 name, will be reversed. 193 194 Similarly, PKINIT may require the encoding of an X.500 name as a 195 PrincipalName. In these cases, the name-type of the principal name 196 shall be set to NT-X500-PRINCIPAL. This new name type is defined 197 as: 198 #define CSFC5c_NT_X500_PRINCIPAL 6 199 200 The name-string shall be set as follows: 201 202 RFC1779Encode(DistinguishedName) 203 204 as described above. 205 206 2073.1.1. Encryption and Key Formats 208 209 In the exposition below, we use the terms public key and private 210 key generically. It should be understood that the term "public 211 key" may be used to refer to either a public encryption key or a 212 signature verification key, and that the term "private key" may be 213 used to refer to either a private decryption key or a signature 214 generation key. The fact that these are logically distinct does 215 not preclude the assignment of bitwise identical keys. 216 217 All additional symmetric keys specified in this draft shall use the 218 same encryption type as the session key in the response from the 219 KDC. These include the temporary keys used to encrypt the signed 220 random key encrypting the response, as well as the key derived from 221 Diffie-Hellman agreement. In the case of Diffie-Hellman, the key 222 shall be produced from the agreed bit string as follows: 223 224 * Truncate the bit string to the appropriate length. 225 * Rectify parity in each byte (if necessary) to obtain the key. 226 227 For instance, in the case of a DES key, we take the first eight 228 bytes of the bit stream, and then adjust the least significant bit 229 of each byte to ensure that each byte has odd parity. 230 231 RFC 1510, Section 6.1, defines EncryptedData as follows: 232 233 EncryptedData ::= SEQUENCE { 234 etype [0] INTEGER, 235 kvno [1] INTEGER OPTIONAL, 236 cipher [2] OCTET STRING 237 -- is CipherText 238 } 239 240 RFC 1510 also defines how CipherText is to be composed. It is not 241 an ASN.1 data structure, but rather an octet string which is the 242 encryption of a plaintext string. This plaintext string is in turn 243 a concatenation of the following octet strings: a confounder, a 244 checksum, the message, and padding. Details of how these components 245 are arranged can be found in RFC 1510. 246 247 The PKINIT protocol introduces several new types of encryption. 248 Data that is encrypted with a public key will allow only the check 249 optional field, as it is defined above. This type of the checksum 250 will be specified in the etype field, together with the encryption 251 type. 252 253 In order to identify the checksum type, etype will have the 254 following values: 255 256 rsa-pub-MD5 257 rsa-pub-SHA1 258 259 In the case that etype is set to rsa-pub, the optional 'check' 260 field will not be provided. 261 262 Data that is encrypted with a private key will not use any optional 263 fields. PKINIT uses private key encryption only for signatures, 264 which are encrypted checksums. Therefore, the optional check field 265 is not needed. 266 267 2683.2. Standard Public Key Authentication 269 270 Implementation of the changes in this section is REQUIRED for 271 compliance with PKINIT. 272 273 It is assumed that all public keys are signed by some certification 274 authority (CA). The initial authentication request is sent as per 275 RFC 1510, except that a preauthentication field containing data 276 signed by the user's private key accompanies the request: 277 278 PA-PK-AS-REQ ::= SEQUENCE { 279 -- PA TYPE 14 280 signedAuthPack [0] SignedAuthPack 281 userCert [1] SEQUENCE OF Certificate OPTIONAL, 282 -- the user's certificate chain 283 trustedCertifiers [2] SEQUENCE OF PrincipalName OPTIONAL, 284 -- CAs that the client trusts 285 serialNumber [3] CertificateSerialNumber OPTIONAL 286 -- specifying a particular 287 -- certificate if the client 288 -- already has it; 289 -- must be accompanied by 290 -- a single trustedCertifier 291 } 292 293 CertificateSerialNumber ::= INTEGER 294 -- as specified by PKCS 6 295 296 SignedAuthPack ::= SEQUENCE { 297 authPack [0] AuthPack, 298 authPackSig [1] Signature, 299 -- of authPack 300 -- using user's private key 301 } 302 303 AuthPack ::= SEQUENCE { 304 pkAuthenticator [0] PKAuthenticator, 305 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL 306 -- if client is using Diffie-Hellman 307 } 308 309 PKAuthenticator ::= SEQUENCE { 310 kdcName [0] PrincipalName, 311 kdcRealm [1] Realm, 312 cusec [2] INTEGER, 313 -- for replay prevention 314 ctime [3] KerberosTime, 315 -- for replay prevention 316 nonce [4] INTEGER 317 } 318 319 Signature ::= SEQUENCE { 320 signedHash [0] EncryptedData 321 -- of type Checksum 322 } 323 324 Checksum ::= SEQUENCE { 325 cksumtype [0] INTEGER, 326 checksum [1] OCTET STRING 327 } -- as specified by RFC 1510 328 329 SubjectPublicKeyInfo ::= SEQUENCE { 330 algorithm [0] AlgorithmIdentifier, 331 subjectPublicKey [1] BIT STRING 332 -- for DH, equals 333 -- public exponent (INTEGER encoded 334 -- as payload of BIT STRING) 335 } -- as specified by the X.509 recommendation [9] 336 337 AlgorithmIdentifier ::= SEQUENCE { 338 algorithm [0] ALGORITHM.&id, 339 -- for DH, equals 340 -- dhKeyAgreement 341 -- ({iso(1) member-body(2) US(840) 342 -- rsadsi(113549) pkcs(1) pkcs-3(3) 343 -- 1}) 344 parameters [1] ALGORITHM.&type 345 -- for DH, is DHParameter 346 } -- as specified by the X.509 recommendation [9] 347 348 DHParameter ::= SEQUENCE { 349 prime [0] INTEGER, 350 -- p 351 base [1] INTEGER, 352 -- g 353 privateValueLength [2] INTEGER OPTIONAL 354 } 355 356 Certificate ::= SEQUENCE { 357 certType [0] INTEGER, 358 -- type of certificate 359 -- 1 = X.509v3 (DER encoding) 360 -- 2 = PGP (per PGP specification) 361 certData [1] OCTET STRING 362 -- actual certificate 363 -- type determined by certType 364 } 365 366 If the client passes a certificate serial number in the request, 367 the KDC is requested to use the referred-to certificate. If none 368 exists, then the KDC returns an error of type 369 KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the 370 other hand, the client does not pass any trustedCertifiers, 371 believing that it has the KDC's certificate, but the KDC has more 372 than one certificate. 373 374 The PKAuthenticator carries information to foil replay attacks, 375 to bind the request and response, and to optionally pass the 376 client's Diffie-Hellman public value (i.e. for using DSA in 377 combination with Diffie-Hellman). The PKAuthenticator is signed 378 with the private key corresponding to the public key in the 379 certificate found in userCert (or cached by the KDC). 380 381 In the PKAuthenticator, the client may specify the KDC name in one 382 of two ways: 383 384 * The Kerberos principal name krbtgt/<realm_name>@<realm_name>, 385 where <realm_name> is replaced by the applicable realm name. 386 * The name in the KDC's certificate (e.g., an X.500 name, or a 387 PGP name). 388 389 Note that the first case requires that the certificate name and the 390 Kerberos principal name be bound together (e.g., via an X.509v3 391 extension). 392 393 The userCert field is a sequence of certificates, the first of which 394 must be the user's public key certificate. Any subsequent 395 certificates will be certificates of the certifiers of the user's 396 certificate. These cerificates may be used by the KDC to verify the 397 user's public key. This field may be left empty if the KDC already 398 has the user's certificate. 399 400 The trustedCertifiers field contains a list of certification 401 authorities trusted by the client, in the case that the client does 402 not possess the KDC's public key certificate. If the KDC has no 403 certificate signed by any of the trustedCertifiers, then it returns 404 an error of type KDC_ERR_CERTIFICATE_MISMATCH. 405 406 Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication 407 type, the KDC attempts to verify the user's certificate chain 408 (userCert), if one is provided in the request. This is done by 409 verifying the certification path against the KDC's policy of 410 legitimate certifiers. This may be based on a certification 411 hierarchy, or it may be simply a list of recognized certifiers in a 412 system like PGP. 413 414 If verification of the user's certificate fails, the KDC sends back 415 an error message of type KDC_ERR_CLIENT_NOT_TRUSTED. The e-data 416 field contains additional information pertaining to this error, and 417 is formatted as follows: 418 419 METHOD-DATA ::= SEQUENCE { 420 method-type [0] INTEGER, 421 -- 1 = cannot verify public key 422 -- 2 = invalid certificate 423 -- 3 = revoked certificate 424 -- 4 = invalid KDC name 425 -- 5 = client name mismatch 426 method-data [1] OCTET STRING OPTIONAL 427 } -- syntax as for KRB_AP_ERR_METHOD (RFC 1510) 428 429 The values for the method-type and method-data fields are described 430 in Section 3.2.1. 431 432 If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC 433 verifies that it has a certificate issued by one of the certifiers 434 trusted by the client. If it does not have a suitable certificate, 435 the KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to 436 the client. 437 438 If a trust relationship exists, the KDC then verifies the client's 439 signature on AuthPack. If that fails, the KDC returns an error 440 message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the 441 timestamp in the PKAuthenticator to assure that the request is not a 442 replay. The KDC also verifies that its name is specified in the 443 PKAuthenticator. 444 445 If the clientPublicValue field is filled in, indicating that the 446 client wishes to use Diffie-Hellman key agreement, then the KDC 447 checks to see that the parameters satisfy its policy. If they do 448 not (e.g., the prime size is insufficient for the expected 449 encryption type), then the KDC sends back an error message of type 450 KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and 451 private values for the response. 452 453 The KDC also checks that the timestamp in the PKAuthenticator is 454 within the allowable window. If the local (server) time and the 455 client time in the authenticator differ by more than the allowable 456 clock skew, then the KDC returns an error message of type 457 KRB_AP_ERR_SKEW. 458 459 Assuming no errors, the KDC replies as per RFC 1510, except as 460 follows: The user's name in the ticket is as represented in the 461 certificate, unless a Kerberos principal name is bound to the name 462 in the certificate (e.g., via an X.509v3 extension). The user's 463 realm in the ticket shall be the name of the Certification 464 Authority that issued the user's public key certificate. 465 466 The KDC encrypts the reply not with the user's long-term key, but 467 with a random key generated only for this particular response. This 468 random key is sealed in the preauthentication field: 469 470 PA-PK-AS-REP ::= SEQUENCE { 471 -- PA TYPE 15 472 encSignedReplyKeyPack [0] EncryptedData, 473 -- of type SignedReplyKeyPack 474 -- using the temporary key 475 -- in encTmpKey 476 encTmpKeyPack [1] EncryptedData, 477 -- of type TmpKeyPack 478 -- using either the client public 479 -- key or the Diffie-Hellman key 480 -- specified by SignedDHPublicValue 481 signedKDCPublicValue [2] SignedKDCPublicValue OPTIONAL 482 -- if one was passed in the request 483 kdcCert [3] SEQUENCE OF Certificate OPTIONAL, 484 -- the KDC's certificate chain 485 } 486 487 SignedReplyKeyPack ::= SEQUENCE { 488 replyKeyPack [0] ReplyKeyPack, 489 replyKeyPackSig [1] Signature, 490 -- of replyEncKeyPack 491 -- using KDC's private key 492 } 493 494 ReplyKeyPack ::= SEQUENCE { 495 replyKey [0] EncryptionKey, 496 -- used to encrypt main reply 497 -- of same ENCTYPE as session key 498 nonce [1] INTEGER 499 -- binds response to the request 500 -- must be same as the nonce 501 -- passed in the PKAuthenticator 502 } 503 504 TmpKeyPack ::= SEQUENCE { 505 tmpKey [0] EncryptionKey, 506 -- used to encrypt the 507 -- SignedReplyKeyPack 508 -- of same ENCTYPE as session key 509 } 510 511 SignedKDCPublicValue ::= SEQUENCE { 512 kdcPublicValue [0] SubjectPublicKeyInfo, 513 -- as described above 514 kdcPublicValueSig [1] Signature 515 -- of kdcPublicValue 516 -- using KDC's private key 517 } 518 519 The kdcCert field is a sequence of certificates, the first of which 520 must be the KDC's public key certificate. Any subsequent 521 certificates will be certificates of the certifiers of the KDC's 522 certificate. The last of these must have as its certifier one of 523 the certifiers sent to the KDC in the PA-PK-AS-REQ. These 524 cerificates may be used by the client to verify the KDC's public 525 key. This field is empty if the client did not send to the KDC a 526 list of trusted certifiers (the trustedCertifiers field was empty). 527 528 Since each certifier in the certification path of a user's 529 certificate is essentially a separate realm, the name of each 530 certifier shall be added to the transited field of the ticket. The 531 format of these realm names is defined in Section 3.1 of this 532 document. If applicable, the transit-policy-checked flag should be 533 set in the issued ticket. 534 535 The KDC's certificate must bind the public key to a name derivable 536 from the name of the realm for that KDC. For an X.509 certificate, 537 this is done as follows. The name of the KDC will be represented 538 as an OtherName, encoded as a GeneralString: 539 540 GeneralName ::= CHOICE { 541 otherName [0] KDCPrincipalName, 542 ... 543 } 544 545 KDCPrincipalNameTypes OTHER-NAME ::= { 546 { PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst } 547 } 548 549 KDCPrincipalName ::= SEQUENCE { 550 nameType OTHER-NAME.&id ( { KDCPrincipalNameTypes } ), 551 name OTHER-NAME.&type ( { KDCPrincipalNameTypes } 552 { @nameType } ) 553 } 554 555 PrincipalNameSrvInst ::= GeneralString 556 557 where (from the Kerberos specification) we have 558 559 krb5 OBJECT IDENTIFIER ::= { iso (1) 560 org (3) 561 dod (6) 562 internet (1) 563 security (5) 564 kerberosv5 (2) } 565 566 principalName OBJECT IDENTIFIER ::= { krb5 2 } 567 568 principalNameSrvInst OBJECT IDENTIFIER ::= { principalName 2 } 569 570 The client then extracts the random key used to encrypt the main 571 reply. This random key (in encPaReply) is encrypted with either the 572 client's public key or with a key derived from the DH values 573 exchanged between the client and the KDC. 574 575 5763.2.1. Additional Information for Errors 577 578 This section describes the interpretation of the method-type and 579 method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error. 580 581 If method-type=1, the client's public key certificate chain does not 582 contain a certificate that is signed by a certification authority 583 trusted by the KDC. The format of the method-data field will be an 584 ASN.1 encoding of a list of trusted certifiers, as defined above: 585 586 TrustedCertifiers ::= SEQUENCE OF PrincipalName 587 588 If method-type=2, the signature on one of the certificates in the 589 chain cannot be verified. The format of the method-data field will 590 be an ASN.1 encoding of the integer index of the certificate in 591 question: 592 593 CertificateIndex ::= INTEGER 594 -- 0 = 1st certificate, 595 -- 1 = 2nd certificate, etc 596 597 If method-type=3, one of the certificates in the chain has been 598 revoked. The format of the method-data field will be an ASN.1 599 encoding of the integer index of the certificate in question: 600 601 CertificateIndex ::= INTEGER 602 -- 0 = 1st certificate, 603 -- 1 = 2nd certificate, etc 604 605 If method-type=4, the KDC name or realm in the PKAuthenticator does 606 not match the principal name of the KDC. There is no method-data 607 field in this case. 608 609 If method-type=5, the client name or realm in the certificate does 610 not match the principal name of the client. There is no 611 method-data field in this case. 612 613 6143.3. Digital Signature 615 616 Implementation of the changes in this section are OPTIONAL for 617 compliance with PKINIT. 618 619 We offer this option with the warning that it requires the client to 620 generate a random key; the client may not be able to guarantee the 621 same level of randomness as the KDC. 622 623 If the user registered, or presents a certificate for, a digital 624 signature key with the KDC instead of an encryption key, then a 625 separate exchange must be used. The client sends a request for a 626 TGT as usual, except that it (rather than the KDC) generates the 627 random key that will be used to encrypt the KDC response. This key 628 is sent to the KDC along with the request in a preauthentication 629 field, encrypted with the KDC's public key: 630 631 PA-PK-AS-SIGN ::= SEQUENCE { 632 -- PA TYPE 16 633 encSignedRandomKeyPack [0] EncryptedData, 634 -- of type SignedRandomKeyPack 635 -- using the key in encTmpKeyPack 636 encTmpKeyPack [1] EncryptedData, 637 -- of type TmpKeyPack 638 -- using the KDC's public key 639 userCert [2] SEQUENCE OF Certificate OPTIONAL 640 -- the user's certificate chain 641 } 642 643 SignedRandomKeyPack ::= SEQUENCE { 644 randomkeyPack [0] RandomKeyPack, 645 randomkeyPackSig [1] Signature 646 -- of keyPack 647 -- using user's private key 648 } 649 650 RandomKeyPack ::= SEQUENCE { 651 randomKey [0] EncryptionKey, 652 -- will be used to encrypt reply 653 randomKeyAuth [1] PKAuthenticator 654 -- nonce copied from AS-REQ 655 } 656 657 If the KDC does not accept client-generated random keys as a matter 658 of policy, then it sends back an error message of type 659 KDC_ERR_KEY_TOO_WEAK. Otherwise, it extracts the random key as 660 follows. 661 662 Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies 663 the randomKey. It then replies as per RFC 1510, except that the 664 reply is encrypted not with a password-derived user key, but with 665 the randomKey sent in the request. Since the client already knows 666 this key, there is no need to accompany the reply with an extra 667 preauthentication field. The transited field of the ticket should 668 specify the certification path as described in Section 3.2. 669 670 6713.4. Retrieving the User's Private Key from the KDC 672 673 Implementation of the changes described in this section are OPTIONAL 674 for compliance with PKINIT. 675 676 When the user's private key is not stored local to the user, he may 677 choose to store the private key (normally encrypted using a 678 password-derived key) on the KDC. In this case, the client makes a 679 request as described above, except that instead of preauthenticating 680 with his private key, he uses a symmetric key shared with the KDC. 681 682 For simplicity's sake, this shared key is derived from the password- 683 derived key used to encrypt the private key, in such a way that the 684 KDC can authenticate the user with the shared key without being able 685 to extract the private key. 686 687 We provide this option to present the user with an alternative to 688 storing the private key on local disk at each machine where he 689 expects to authenticate himself using PKINIT. It should be noted 690 that it replaces the added risk of long-term storage of the private 691 key on possibly many workstations with the added risk of storing the 692 private key on the KDC in a form vulnerable to brute-force attack. 693 694 Denote by K1 the symmetric key used to encrypt the private key. 695 Then construct symmetric key K2 as follows: 696 697 * Perform a hash on K1. 698 * Truncate the digest to Length(K1) bytes. 699 * Rectify parity in each byte (if necessary) to obtain K2. 700 701 The KDC stores K2, the public key, and the encrypted private key. 702 This key pair is designated as the "primary" key pair for that user. 703 This primary key pair is the one used to perform initial 704 authentication using the PA-PK-AS-REP preauthentication field. If 705 he desires, he may also store additional key pairs on the KDC; these 706 may be requested in addition to the primary. When the client 707 requests initial authentication using public key cryptography, it 708 must then include in its request, instead of a PA-PK-AS-REQ, the 709 following preauthentication sequence: 710 711 PA-PK-KEY-REQ ::= SEQUENCE { 712 -- PA TYPE 17 713 signedPKAuth [0] SignedPKAuth, 714 trustedCertifiers [1] SEQUENCE OF PrincipalName OPTIONAL, 715 -- CAs that the client trusts 716 keyIDList [2] SEQUENCE OF Checksum OPTIONAL 717 -- payload is hash of public key 718 -- corresponding to desired 719 -- private key 720 -- if absent, KDC will return all 721 -- stored private keys 722 } 723 724 SignedPKAuth ::= SEQUENCE { 725 pkAuth [0] PKAuthenticator, 726 pkAuthSig [1] Signature 727 -- of pkAuth 728 -- using the symmetric key K2 729 } 730 731 If a keyIDList is present, the first identifier should indicate 732 the primary private key. No public key certificate is required, 733 since the KDC stores the public key along with the private key. 734 If there is no keyIDList, all the user's private keys are returned. 735 736 Upon receipt, the KDC verifies the signature using K2. If the 737 verification fails, the KDC sends back an error of type 738 KDC_ERR_INVALID_SIG. If the signature verifies, but the requested 739 keys are not found on the KDC, then the KDC sends back an error of 740 type KDC_ERR_PREAUTH_FAILED. If all checks out, the KDC responds as 741 described in Section 3.2, except that in addition, the KDC appends 742 the following preauthentication sequence: 743 744 PA-PK-KEY-REP ::= SEQUENCE { 745 -- PA TYPE 18 746 encKeyRep [0] EncryptedData 747 -- of type EncKeyReply 748 -- using the symmetric key K2 749 } 750 751 EncKeyReply ::= SEQUENCE { 752 keyPackList [0] SEQUENCE OF KeyPack, 753 -- the first KeyPair is 754 -- the primary key pair 755 nonce [1] INTEGER 756 -- binds reply to request 757 -- must be identical to the nonce 758 -- sent in the SignedAuthPack 759 } 760 761 KeyPack ::= SEQUENCE { 762 keyID [0] Checksum, 763 encPrivKey [1] OCTET STRING 764 } 765 766 Upon receipt of the reply, the client extracts the encrypted private 767 keys (and may store them, at the client's option). The primary 768 private key, which must be the first private key in the keyPack 769 SEQUENCE, is used to decrypt the random key in the PA-PK-AS-REP; 770 this key in turn is used to decrypt the main reply as described in 771 Section 3.2. 772 773 7744. Logistics and Policy 775 776 This section describes a way to define the policy on the use of 777 PKINIT for each principal and request. 778 779 The KDC is not required to contain a database record for users 780 that use either the Standard Public Key Authentication or Public Key 781 Authentication with a Digital Signature. However, if these users 782 are registered with the KDC, it is recommended that the database 783 record for these users be modified to include three additional flags 784 in the attributes field. 785 786 The first flag, use_standard_pk_init, indicates that the user should 787 authenticate using standard PKINIT as described in Section 3.2. The 788 second flag, use_digital_signature, indicates that the user should 789 authenticate using digital signature PKINIT as described in Section 790 3.3. The third flag, store_private_key, indicates that the user 791 has stored his private key on the KDC and should retrieve it using 792 the exchange described in Section 3.4. 793 794 If one of the preauthentication fields defined above is included in 795 the request, then the KDC shall respond as described in Sections 3.2 796 through 3.4, ignoring the aforementioned database flags. If more 797 than one of the preauthentication fields is present, the KDC shall 798 respond with an error of type KDC_ERR_PREAUTH_FAILED. 799 800 In the event that none of the preauthentication fields defined above 801 are included in the request, the KDC checks to see if any of the 802 above flags are set. If the first flag is set, then it sends back 803 an error of type KDC_ERR_PREAUTH_REQUIRED indicating that a 804 preauthentication field of type PA-PK-AS-REQ must be included in the 805 request. 806 807 Otherwise, if the first flag is clear, but the second flag is set, 808 then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED 809 indicating that a preauthentication field of type PA-PK-AS-SIGN must 810 be included in the request. 811 812 Lastly, if the first two flags are clear, but the third flag is set, 813 then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED 814 indicating that a preauthentication field of type PA-PK-KEY-REQ must 815 be included in the request. 816 817 8185. Transport Issues 819 820 Certificate chains can potentially grow quite large and span several 821 UDP packets; this in turn increases the probability that a Kerberos 822 message involving PKINIT extensions will be broken in transit. In 823 light of the possibility that the Kerberos specification will 824 require KDCs to accept requests using TCP as a transport mechanism, 825 we make the same recommendation with respect to the PKINIT 826 extensions as well. 827 828 8296. Bibliography 830 831 [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service 832 (V5). Request for Comments 1510. 833 834 [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service 835 for Computer Networks, IEEE Communications, 32(9):33-38. September 836 1994. 837 838 [3] A. Medvinsky, M. Hur. Addition of Kerberos Cipher Suites to 839 Transport Layer Security (TLS). 840 draft-ietf-tls-kerb-cipher-suites-00.txt 841 842 [4] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing 843 Tickets for Application Servers (PKTAPP). 844 draft-ietf-cat-pktapp-00.txt 845 846 [5] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos 847 Using Public Key Cryptography. Symposium On Network and Distributed 848 System Security, 1997. 849 850 [6] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction 851 Protocol. In Proceedings of the USENIX Workshop on Electronic 852 Commerce, July 1995. 853 854 [7] Alan O. Freier, Philip Karlton and Paul C. Kocher. The SSL 855 Protocol, Version 3.0 - IETF Draft. 856 857 [8] B.C. Neuman, Proxy-Based Authorization and Accounting for 858 Distributed Systems. In Proceedings of the 13th International 859 Conference on Distributed Computing Systems, May 1993. 860 861 [9] ITU-T (formerly CCITT) Information technology - Open Systems 862 Interconnection - The Directory: Authentication Framework 863 Recommendation X.509 ISO/IEC 9594-8 864 865 8667. Acknowledgements 867 868 Sasha Medvinsky contributed several ideas to the protocol changes 869 and specifications in this document. His additions have been most 870 appreciated. 871 872 Some of the ideas on which this proposal is based arose during 873 discussions over several years between members of the SAAG, the IETF 874 CAT working group, and the PSRG, regarding integration of Kerberos 875 and SPX. Some ideas have also been drawn from the DASS system. 876 These changes are by no means endorsed by these groups. This is an 877 attempt to revive some of the goals of those groups, and this 878 proposal approaches those goals primarily from the Kerberos 879 perspective. Lastly, comments from groups working on similar ideas 880 in DCE have been invaluable. 881 882 8838. Expiration Date 884 885 This draft expires May 26, 1998. 886 887 8889. Authors 889 890 Brian Tung 891 Clifford Neuman 892 USC Information Sciences Institute 893 4676 Admiralty Way Suite 1001 894 Marina del Rey CA 90292-6695 895 Phone: +1 310 822 1511 896 E-mail: {brian, bcn}@isi.edu 897 898 John Wray 899 Digital Equipment Corporation 900 550 King Street, LKG2-2/Z7 901 Littleton, MA 01460 902 Phone: +1 508 486 5210 903 E-mail: wray@tuxedo.enet.dec.com 904 905 Ari Medvinsky 906 Matthew Hur 907 CyberSafe Corporation 908 1605 NW Sammamish Road Suite 310 909 Issaquah WA 98027-5378 910 Phone: +1 206 391 6000 911 E-mail: {ari.medvinsky, matt.hur}@cybersafe.com 912 913 Jonathan Trostle 914 Novell Corporation 915 Provo UT 916 E-mail: jtrostle@novell.com 917