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