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