idnits 2.17.1 draft-ietf-cat-kerberos-pk-init-04.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 869 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 207: '... kvno [1] INTEGER OPTIONAL,...' RFC 2119 keyword, line 216: '... OPTIONAL,...' RFC 2119 keyword, line 218: '... OPTIONAL,...' RFC 2119 keyword, line 221: '... OPTIONAL...' RFC 2119 keyword, line 246: '...hanges in this section is REQUIRED for...' (12 more instances...) == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC1510, but the abstract doesn't seem to directly say this. It does mention RFC1510 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- (Using the creation date from RFC1510, updated by this document, for RFC5378 checks: 1993-09-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 769 looks like a reference -- Missing reference section? '2' on line 772 looks like a reference -- Missing reference section? '4' on line 780 looks like a reference -- Missing reference section? '5' on line 784 looks like a reference -- Missing reference section? '6' on line 788 looks like a reference -- Missing reference section? '7' on line 792 looks like a reference -- Missing reference section? '8' on line 795 looks like a reference -- Missing reference section? '0' on line 704 looks like a reference -- Missing reference section? '3' on line 776 looks like a reference -- Missing reference section? '9' on line 799 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Brian Tung 2 draft-ietf-cat-kerberos-pk-init-04.txt Clifford Neuman 3 Updates: RFC 1510 ISI 4 expires January 31, 1998 John Wray 5 Digital Equipment Corporation 6 Ari Medvinsky 7 Matthew Hur 8 CyberSafe Corporation 9 Jonathan Trostle 10 Novell 12 Public Key Cryptography for Initial Authentication in Kerberos 14 0. Status Of This Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its 18 areas, and its working groups. Note that other groups may also 19 distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 To learn the current status of any Internet-Draft, please check 28 the "1id-abstracts.txt" listing contained in the Internet-Drafts 29 Shadow Directories on ds.internic.net (US East Coast), 30 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 31 munnari.oz.au (Pacific Rim). 33 The distribution of this memo is unlimited. It is filed as 34 draft-ietf-cat-kerberos-pk-init-04.txt, and expires January 31, 35 1998. Please send comments to the authors. 37 1. Abstract 39 This document defines extensions (PKINIT) to the Kerberos protocol 40 specification (RFC 1510 [1]) to provide a method for using public 41 key cryptography during initial authentication. The methods 42 defined specify the ways in which preauthentication data fields and 43 error data fields in Kerberos messages are to be used to transport 44 public key data. 46 2. Introduction 48 The popularity of public key cryptography has produced a desire for 49 its support in Kerberos [2]. The advantages provided by public key 50 cryptography include simplified key management (from the Kerberos 51 perspective) and the ability to leverage existing and developing 52 public key certification infrastructures. 54 Public key cryptography can be integrated into Kerberos in a number 55 of ways. One is to associate a key pair with each realm, which can 56 then be used to facilitate cross-realm authentication; this is the 57 topic of another draft proposal. Another way is to allow users with 58 public key certificates to use them in initial authentication. This 59 is the concern of the current document. 61 One of the guiding principles in the design of PKINIT is that 62 changes should be as minimal as possible. As a result, the basic 63 mechanism of PKINIT is as follows: The user sends a request to the 64 KDC as before, except that if that user is to use public key 65 cryptography in the initial authentication step, his certificate 66 accompanies the initial request, in the preauthentication fields. 68 Upon receipt of this request, the KDC verifies the certificate and 69 issues a ticket granting ticket (TGT) as before, except that instead 70 of being encrypted in the user's long-term key (which is derived 71 from a password), it is encrypted in a randomly-generated key. This 72 random key is in turn encrypted using the public key from the 73 certificate that came with the request and signed using the KDC's 74 private key, and accompanies the reply, in the preauthentication 75 fields. 77 PKINIT also allows for users with only digital signature keys to 78 authenticate using those keys, and for users to store and retrieve 79 private keys on the KDC. 81 The PKINIT specification may also be used for direct peer to peer 82 authentication without contacting a central KDC. This application 83 of PKINIT is described in PKTAPP [4] and is based on concepts 84 introduced in [5, 6]. For direct client-to-server authentication, 85 the client uses PKINIT to authenticate to the end server (instead 86 of a central KDC), which then issues a ticket for itself. This 87 approach has an advantage over SSL [7] in that the server does not 88 need to save state (cache session keys). Furthermore, an 89 additional benefit is that Kerberos tickets can facilitate 90 delegation (see [8]). 92 3. Proposed Extensions 94 This section describes extensions to RFC 1510 for supporting the 95 use of public key cryptography in the initial request for a ticket 96 granting ticket (TGT). 98 In summary, the following changes to RFC 1510 are proposed: 100 --> Users may authenticate using either a public key pair or a 101 conventional (symmetric) key. If public key cryptography is 102 used, public key data is transported in preauthentication 103 data fields to help establish identity. 104 --> Users may store private keys on the KDC for retrieval during 105 Kerberos initial authentication. 107 This proposal addresses two ways that users may use public key 108 cryptography for initial authentication. Users may present public 109 key certificates, or they may generate their own session key, 110 signed by their digital signature key. In either case, the end 111 result is that the user obtains an ordinary TGT that may be used for 112 subsequent authentication, with such authentication using only 113 conventional cryptography. 115 Section 3.1 provides definitions to help specify message formats. 116 Section 3.2 and 3.3 describe the extensions for the two initial 117 authentication methods. Section 3.4 describes a way for the user to 118 store and retrieve his private key on the KDC, as an adjunct to the 119 initial authentication. 121 3.1. Definitions 123 The extensions involve new encryption methods; we propose the 124 addition of the following types: 126 dsa-sign 8 127 rsa-priv 9 128 rsa-pub 10 129 rsa-pub-md5 11 130 rsa-pub-sha1 12 132 The proposal of these encryption types notwithstanding, we do not 133 mandate the use of any particular public key encryption method. 135 The extensions involve new preauthentication fields; we propose the 136 addition of the following types: 138 PA-PK-AS-REQ 14 139 PA-PK-AS-REP 15 140 PA-PK-AS-SIGN 16 141 PA-PK-KEY-REQ 17 142 PA-PK-KEY-REP 18 144 The extensions also involve new error types; we propose the addition 145 of the following types: 147 KDC_ERR_CLIENT_NOT_TRUSTED 62 148 KDC_ERR_KDC_NOT_TRUSTED 63 149 KDC_ERR_INVALID_SIG 64 150 KDC_ERR_KEY_TOO_WEAK 65 152 In many cases, PKINIT requires the encoding of an X.500 name as a 153 Realm. In these cases, the realm will be represented using a 154 different style, specified in RFC 1510 with the following example: 156 NAMETYPE:rest/of.name=without-restrictions 158 For a realm derived from an X.500 name, NAMETYPE will have the value 159 X500-ASN1-BASE64. The full realm name will appear as follows: 161 X500-ASN1-BASE64:Base64Encode(DistinguishedName) 163 where Base64 is an ASCII encoding of binary data as per RFC 1521, 164 and DistinguishedName is the ASN.1 encoding of the X.500 165 Distinguished Name from the X.509 certificate. 167 Similarly, PKINIT may require the encoding of an X.500 name as a 168 PrincipalName. In these cases, the name-type of the principal name 169 shall be set to NT-X500-PRINCIPAL, and the name-string shall be set 170 as follows: 172 Base64Encode(DistinguishedName) 174 as described above. 176 [Similar description needed on how realm names and principal names 177 are to be derived from PGP names.] 179 3.1.1. Encryption and Key Formats 181 In the exposition below, we use the terms public key and private 182 key generically. It should be understood that the term "public 183 key" may be used to refer to either a public encryption key or a 184 signature verification key, and that the term "private key" may be 185 used to refer to either a private decryption key or a signature 186 generation key. The fact that these are logically distinct does 187 not preclude the assignment of bitwise identical keys. 189 All additional symmetric keys specified in this draft shall use the 190 same encryption type as the session key in the response from the 191 KDC. These include the temporary keys used to encrypt the signed 192 random key encrypting the response, as well as the key derived from 193 Diffie-Hellman agreement. In the case of Diffie-Hellman, the key 194 shall be produced from the agreed bit string as follows: 196 * Truncate the bit string to the appropriate length. 197 * Rectify parity in each byte (if necessary) to obtain the key. 199 For instance, in the case of a DES key, we take the first eight 200 bytes of the bit stream, and then adjust the least significant bit 201 of each byte to ensure that each byte has odd parity. 203 RFC 1510, Section 6.1, defines EncryptedData as follows: 205 EncryptedData ::= SEQUENCE { 206 etype [0] INTEGER, 207 kvno [1] INTEGER OPTIONAL, 208 cipher [2] OCTET STRING 209 -- is CipherText 210 } 212 RFC 1510 suggests that ciphertext is coded as follows: 214 CipherText ::= ENCRYPTED SEQUENCE { 215 confounder [0] UNTAGGED OCTET STRING(conf_length) 216 OPTIONAL, 217 check [1] UNTAGGED OCTET STRING(checksum_length) 218 OPTIONAL, 219 msg-seq [2] MsgSequence, 220 pad [3] UNTAGGED OCTET STRING(pad_length) 221 OPTIONAL 222 } 224 The PKINIT protocol introduces several new types of encryption. 225 Data that is encrypted with a public key will allow only the check 226 optional field, as it is defined above. This type of the checksum 227 will be specified in the etype field, together with the encryption 228 type. 230 In order to identify the checksum type, etype will have the 231 following values: 233 rsa-pub-MD5 234 rsa-pub-SHA1 236 In the case that etype is set to rsa-pub, the optional 'check' 237 field will not be provided. 239 Data that is encrypted with a private key will not use any optional 240 fields. PKINIT uses private key encryption only for signatures, 241 which are encrypted checksums. Therefore, the optional check field 242 is not needed. 244 3.2. Standard Public Key Authentication 246 Implementation of the changes in this section is REQUIRED for 247 compliance with PKINIT. 249 It is assumed that all public keys are signed by some certification 250 authority (CA). The initial authentication request is sent as per 251 RFC 1510, except that a preauthentication field containing data 252 signed by the user's private key accompanies the request: 254 PA-PK-AS-REQ ::= SEQUENCE { 255 -- PA TYPE 14 256 signedAuthPack [0] SignedAuthPack 257 userCert [1] SEQUENCE OF Certificate OPTIONAL, 258 -- the user's certificate chain 259 trustedCertifiers [2] SEQUENCE OF PrincipalName OPTIONAL 260 -- CAs that the client trusts 261 } 263 SignedAuthPack ::= SEQUENCE { 264 authPack [0] AuthPack, 265 authPackSig [1] Signature, 266 -- of authPack 267 -- using user's private key 268 } 270 AuthPack ::= SEQUENCE { 271 pkAuthenticator [0] PKAuthenticator, 272 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL 273 -- if client is using Diffie-Hellman 274 } 276 PKAuthenticator ::= SEQUENCE { 277 kdcName [0] PrincipalName, 278 kdcRealm [1] Realm, 279 cusec [2] INTEGER, 280 -- for replay prevention 281 ctime [3] KerberosTime, 282 -- for replay prevention 283 nonce [4] INTEGER 284 } 286 Signature ::= SEQUENCE { 287 signedHash [0] EncryptedData 288 -- of type Checksum 289 } 291 Checksum ::= SEQUENCE { 292 cksumtype [0] INTEGER, 293 checksum [1] OCTET STRING 294 } -- as specified by RFC 1510 296 SubjectPublicKeyInfo ::= SEQUENCE { 297 algorithm [0] AlgorithmIdentifier, 298 subjectPublicKey [1] BIT STRING 299 -- for DH, equals 300 -- public exponent (INTEGER encoded 301 -- as payload of BIT STRING) 302 } -- as specified by the X.509 recommendation [9] 304 AlgorithmIdentifier ::= SEQUENCE { 305 algorithm [0] ALGORITHM.&id, 306 -- for DH, equals 307 -- dhKeyAgreement 308 -- ({iso(1) member-body(2) US(840) 309 -- rsadsi(113549) pkcs(1) pkcs-3(3) 310 -- 1}) 311 parameters [1] ALGORITHM.&type 312 -- for DH, is DHParameter 313 } -- as specified by the X.509 recommendation [9] 315 DHParameter ::= SEQUENCE { 316 prime [0] INTEGER, 317 -- p 318 base [1] INTEGER, 319 -- g 320 privateValueLength [2] INTEGER OPTIONAL 321 } 323 Certificate ::= SEQUENCE { 324 certType [0] INTEGER, 325 -- type of certificate 326 -- 1 = X.509v3 (DER encoding) 327 -- 2 = PGP (per PGP specification) 328 certData [1] OCTET STRING 329 -- actual certificate 330 -- type determined by certType 331 } 333 The PKAuthenticator carries information to foil replay attacks, 334 to bind the request and response, and to optionally pass the 335 client's Diffie-Hellman public value (i.e. for using DSA in 336 combination with Diffie-Hellman). The PKAuthenticator is signed 337 with the private key corresponding to the public key in the 338 certificate found in userCert (or cached by the KDC). 340 In the PKAuthenticator, the client may specify the KDC name in one 341 of two ways: 343 * The Kerberos principal name krbtgt/@, 344 where is replaced by the applicable realm name. 345 * The name in the KDC's certificate (e.g., an X.500 name, or a 346 PGP name). 348 Note that the first case requires that the certificate name and the 349 Kerberos principal name be bound together (e.g., via an X.509v3 350 extension). 352 The userCert field is a sequence of certificates, the first of which 353 must be the user's public key certificate. Any subsequent 354 certificates will be certificates of the certifiers of the user's 355 certificate. These cerificates may be used by the KDC to verify the 356 user's public key. This field may be left empty if the KDC already 357 has the user's certificate. 359 The trustedCertifiers field contains a list of certification 360 authorities trusted by the client, in the case that the client does 361 not possess the KDC's public key certificate. 363 Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication 364 type, the KDC attempts to verify the user's certificate chain 365 (userCert), if one is provided in the request. This is done by 366 verifying the certification path against the KDC's policy of 367 legitimate certifiers. This may be based on a certification 368 hierarchy, or it may be simply a list of recognized certifiers in a 369 system like PGP. 371 If verification of the user's certificate fails, the KDC sends back 372 an error message of type KDC_ERR_CLIENT_NOT_TRUSTED. The e-data 373 field contains additional information pertaining to this error, and 374 is formatted as follows: 376 METHOD-DATA ::= SEQUENCE { 377 method-type [0] INTEGER, 378 -- 1 = cannot verify public key 379 -- 2 = invalid certificate 380 -- 3 = revoked certificate 381 -- 4 = invalid KDC name 382 method-data [1] OCTET STRING OPTIONAL 383 } -- syntax as for KRB_AP_ERR_METHOD (RFC 1510) 385 The values for the method-type and method-data fields are described 386 in Section 3.2.1. 388 If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC 389 verifies that it has a certificate issued by one of the certifiers 390 trusted by the client. If it does not have a suitable certificate, 391 the KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to 392 the client. 394 If a trust relationship exists, the KDC then verifies the client's 395 signature on PKAuthenticator. If that fails, the KDC returns an 396 error message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses 397 the timestamp in the PKAuthenticator to assure that the request is 398 not a replay. The KDC also verifies that its name is specified in 399 the PKAuthenticator. 401 If the clientPublicValue field is filled in, indicating that the 402 client wishes to use Diffie-Hellman key agreement, then the KDC 403 checks to see that the parameters satisfy its policy. If they do 404 not (e.g., the prime size is insufficient for the expected 405 encryption type), then the KDC sends back an error message of type 406 KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and 407 private values for the response. 409 The KDC also checks that the timestamp in the PKAuthenticator is 410 within the allowable window. If the local (server) time and the 411 client time in the authenticator differ by more than the allowable 412 clock skew, then the KDC returns an error message of type 413 KRB_AP_ERR_SKEW. 415 Assuming no errors, the KDC replies as per RFC 1510, except as 416 follows: The user's name in the ticket is as represented in the 417 certificate, unless a Kerberos principal name is bound to the name 418 in the certificate (e.g., via an X.509v3 extension). The user's 419 realm in the ticket shall be the name of the Certification 420 Authority that issued the user's public key certificate. 422 The KDC encrypts the reply not with the user's long-term key, but 423 with a random key generated only for this particular response. This 424 random key is sealed in the preauthentication field: 426 PA-PK-AS-REP ::= SEQUENCE { 427 -- PA TYPE 15 428 encSignedReplyKeyPack [0] EncryptedData, 429 -- of type SignedReplyKeyPack 430 -- using the temporary key 431 -- in encTmpKey 432 encTmpKeyPack [1] EncryptedData, 433 -- of type TmpKeyPack 434 -- using either the client public 435 -- key or the Diffie-Hellman key 436 -- specified by SignedDHPublicValue 437 signedKDCPublicValue [2] SignedKDCPublicValue OPTIONAL 438 -- if one was passed in the request 439 kdcCert [3] SEQUENCE OF Certificate OPTIONAL, 440 -- the KDC's certificate chain 441 } 443 SignedReplyKeyPack ::= SEQUENCE { 444 replyKeyPack [0] ReplyKeyPack, 445 replyKeyPackSig [1] Signature, 446 -- of replyEncKeyPack 447 -- using KDC's private key 448 } 450 ReplyKeyPack ::= SEQUENCE { 451 replyKey [0] EncryptionKey, 452 -- used to encrypt main reply 453 nonce [1] INTEGER 454 -- binds response to the request 455 -- must be same as the nonce 456 -- passed in the PKAuthenticator 457 } 459 TmpKeyPack ::= SEQUENCE { 460 tmpKey [0] EncryptionKey, 461 -- used to encrypt the 462 -- SignedReplyKeyPack 463 } 465 SignedKDCPublicValue ::= SEQUENCE { 466 kdcPublicValue [0] SubjectPublicKeyInfo, 467 -- as described above 468 kdcPublicValueSig [1] Signature 469 -- of kdcPublicValue 470 -- using KDC's private key 471 } 473 The kdcCert field is a sequence of certificates, the first of which 474 must be the KDC's public key certificate. Any subsequent 475 certificates will be certificates of the certifiers of the KDC's 476 certificate. The last of these must have as its certifier one of 477 the certifiers sent to the KDC in the PA-PK-AS-REQ. These 478 cerificates may be used by the client to verify the KDC's public 479 key. This field is empty if the client did not send to the KDC a 480 list of trusted certifiers (the trustedCertifiers field was empty). 482 Since each certifier in the certification path of a user's 483 certificate is essentially a separate realm, the name of each 484 certifier shall be added to the transited field of the ticket. The 485 format of these realm names is defined in Section 3.1 of this 486 document. If applicable, the transit-policy-checked flag should be 487 set in the issued ticket. 489 The KDC's certificate must bind the public key to a name derivable 490 from the name of the realm for that KDC. For an X.509 certificate, 491 this is done as follows. The certificate will contain a 492 distinguished X.500 name contains, in addition to other attributes, 493 an extended attribute, called principalName, with the KDC's 494 principal name as its value (as the text string 495 krbtgt/@, where is the realm 496 name of the KDC): 498 principalName ATTRIBUTE ::= { 499 WITH SYNTAX PrintableString(SIZE(1..ub-prinicipalName)) 500 EQUALITY MATCHING RULE caseExactMatch 501 ORDERING MATCHING RULE caseExactOrderingMatch 502 SINGLE VALUE TRUE 503 ID id-at-principalName 504 } 506 ub-principalName INTEGER ::= 1024 508 id-at OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4} 510 id-at-principalName OBJECT IDENTIFIER ::= {id-at 60} 512 where ATTRIBUTE is as defined in X.501, and the matching rules are 513 as defined in X.520. 515 [Still need to register principalName.] 517 [Still need to discuss what is done for a PGP certificate.] 519 The client then extracts the random key used to encrypt the main 520 reply. This random key (in encPaReply) is encrypted with either the 521 client's public key or with a key derived from the DH values 522 exchanged between the client and the KDC. 524 3.2.1. Additional Information for Errors 526 This section describes the interpretation of the method-type and 527 method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error. 529 If method-type=1, the client's public key certificate chain does not 530 contain a certificate that is signed by a certification authority 531 trusted by the KDC. The format of the method-data field will be an 532 ASN.1 encoding of a list of trusted certifiers, as defined above: 534 TrustedCertifiers ::= SEQUENCE OF PrincipalName 536 If method-type=2, the signature on one of the certificates in the 537 chain cannot be verified. The format of the method-data field will 538 be an ASN.1 encoding of the integer index of the certificate in 539 question: 541 CertificateIndex ::= INTEGER 542 -- 0 = 1st certificate, 543 -- 1 = 2nd certificate, etc 545 If method-type=3, one of the certificates in the chain has been 546 revoked. The format of the method-data field will be an ASN.1 547 encoding of the integer index of the certificate in question: 549 CertificateIndex ::= INTEGER 550 -- 0 = 1st certificate, 551 -- 1 = 2nd certificate, etc 553 If method-type=4, the KDC name or realm in the PKAuthenticator does 554 not match the principal name of the KDC. There is no method-data 555 field in this case. 557 3.3. Digital Signature 559 Implementation of the changes in this section are OPTIONAL for 560 compliance with PKINIT. 562 We offer this option with the warning that it requires the client to 563 generate a random key; the client may not be able to guarantee the 564 same level of randomness as the KDC. 566 If the user registered, or presents a certificate for, a digital 567 signature key with the KDC instead of an encryption key, then a 568 separate exchange must be used. The client sends a request for a 569 TGT as usual, except that it (rather than the KDC) generates the 570 random key that will be used to encrypt the KDC response. This key 571 is sent to the KDC along with the request in a preauthentication 572 field, encrypted with the KDC's public key: 574 PA-PK-AS-SIGN ::= SEQUENCE { 575 -- PA TYPE 16 576 encSignedRandomKeyPack [0] EncryptedData, 577 -- of type SignedRandomKeyPack 578 -- using the key in encTmpKeyPack 579 encTmpKeyPack [1] EncryptedData, 580 -- of type TmpKeyPack 581 -- using the KDC's public key 582 userCert [2] SEQUENCE OF Certificate OPTIONAL 583 -- the user's certificate chain 584 } 586 SignedRandomKeyPack ::= SEQUENCE { 587 randomkeyPack [0] RandomKeyPack, 588 randomkeyPackSig [1] Signature 589 -- of keyPack 590 -- using user's private key 591 } 593 RandomKeyPack ::= SEQUENCE { 594 randomKey [0] EncryptionKey, 595 -- will be used to encrypt reply 596 randomKeyAuth [1] PKAuthenticator 597 -- nonce copied from AS-REQ 598 } 600 If the KDC does not accept client-generated random keys as a matter 601 of policy, then it sends back an error message of type 602 KDC_ERR_KEY_TOO_WEAK. Otherwise, it extracts the random key as 603 follows. 605 Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies 606 the randomKey. It then replies as per RFC 1510, except that the 607 reply is encrypted not with a password-derived user key, but with 608 the randomKey sent in the request. Since the client already knows 609 this key, there is no need to accompany the reply with an extra 610 preauthentication field. The transited field of the ticket should 611 specify the certification path as described in Section 3.2. 613 3.4. Retrieving the User's Private Key from the KDC 615 Implementation of the changes described in this section are OPTIONAL 616 for compliance with PKINIT. 618 When the user's private key is not stored local to the user, he may 619 choose to store the private key (normally encrypted using a 620 password-derived key) on the KDC. In this case, the client makes a 621 request as described above, except that instead of preauthenticating 622 with his private key, he uses a symmetric key shared with the KDC. 624 For simplicity's sake, this shared key is derived from the password- 625 derived key used to encrypt the private key, in such a way that the 626 KDC can authenticate the user with the shared key without being able 627 to extract the private key. 629 We provide this option to present the user with an alternative to 630 storing the private key on local disk at each machine where he 631 expects to authenticate himself using PKINIT. It should be noted 632 that it replaces the added risk of long-term storage of the private 633 key on possibly many workstations with the added risk of storing the 634 private key on the KDC in a form vulnerable to brute-force attack. 636 Denote by K1 the symmetric key used to encrypt the private key. 637 Then construct symmetric key K2 as follows: 639 * Perform a hash on K1. 640 * Truncate the digest to Length(K1) bytes. 641 * Rectify parity in each byte (if necessary) to obtain K2. 643 The KDC stores K2, the public key, and the encrypted private key. 644 This key pair is designated as the "primary" key pair for that user. 645 This primary key pair is the one used to perform initial 646 authentication using the PA-PK-AS-REP preauthentication field. If 647 he desires, he may also store additional key pairs on the KDC; these 648 may be requested in addition to the primary. When the client 649 requests initial authentication using public key cryptography, it 650 must then include in its request, instead of a PA-PK-AS-REQ, the 651 following preauthentication sequence: 653 PA-PK-KEY-REQ ::= SEQUENCE { 654 -- PA TYPE 17 655 signedPKAuth [0] SignedPKAuth, 656 trustedCertifiers [1] SEQUENCE OF PrincipalName OPTIONAL, 657 -- CAs that the client trusts 658 keyIDList [2] SEQUENCE OF Checksum OPTIONAL 659 -- payload is hash of public key 660 -- corresponding to desired 661 -- private key 662 -- if absent, KDC will return all 663 -- stored private keys 664 } 666 SignedPKAuth ::= SEQUENCE { 667 pkAuth [0] PKAuthenticator, 668 pkAuthSig [1] Signature 669 -- of pkAuth 670 -- using the symmetric key K2 671 } 673 If a keyIDList is present, the first identifier should indicate 674 the primary private key. No public key certificate is required, 675 since the KDC stores the public key along with the private key. 676 If there is no keyIDList, all the user's private keys are returned. 678 Upon receipt, the KDC verifies the signature using K2. If the 679 verification fails, the KDC sends back an error of type 680 KDC_ERR_INVALID_SIG. If the signature verifies, but the requested 681 keys are not found on the KDC, then the KDC sends back an error of 682 type KDC_ERR_PREAUTH_FAILED. If all checks out, the KDC responds as 683 described in Section 3.2, except that in addition, the KDC appends 684 the following preauthentication sequence: 686 PA-PK-KEY-REP ::= SEQUENCE { 687 -- PA TYPE 18 688 encKeyRep [0] EncryptedData 689 -- of type EncKeyReply 690 -- using the symmetric key K2 691 } 693 EncKeyReply ::= SEQUENCE { 694 keyPackList [0] SEQUENCE OF KeyPack, 695 -- the first KeyPair is 696 -- the primary key pair 697 nonce [1] INTEGER 698 -- binds reply to request 699 -- must be identical to the nonce 700 -- sent in the SignedAuthPack 701 } 703 KeyPack ::= SEQUENCE { 704 keyID [0] Checksum, 705 encPrivKey [1] OCTET STRING 706 } 708 Upon receipt of the reply, the client extracts the encrypted private 709 keys (and may store them, at the client's option). The primary 710 private key, which must be the first private key in the keyPack 711 SEQUENCE, is used to decrypt the random key in the PA-PK-AS-REP; 712 this key in turn is used to decrypt the main reply as described in 713 Section 3.2. 715 4. Logistics and Policy 717 This section describes a way to define the policy on the use of 718 PKINIT for each principal and request. 720 The KDC is not required to contain a database record for users 721 that use either the Standard Public Key Authentication or Public Key 722 Authentication with a Digital Signature. However, if these users 723 are registered with the KDC, it is recommended that the database 724 record for these users be modified to include three additional flags 725 in the attributes field. 727 The first flag, use_standard_pk_init, indicates that the user should 728 authenticate using standard PKINIT as described in Section 3.2. The 729 second flag, use_digital_signature, indicates that the user should 730 authenticate using digital signature PKINIT as described in Section 731 3.3. The third flag, store_private_key, indicates that the user 732 has stored his private key on the KDC and should retrieve it using 733 the exchange described in Section 3.4. 735 If one of the preauthentication fields defined above is included in 736 the request, then the KDC shall respond as described in Sections 3.2 737 through 3.4, ignoring the aforementioned database flags. If more 738 than one of the preauthentication fields is present, the KDC shall 739 respond with an error of type KDC_ERR_PREAUTH_FAILED. 741 In the event that none of the preauthentication fields defined above 742 are included in the request, the KDC checks to see if any of the 743 above flags are set. If the first flag is set, then it sends back 744 an error of type KDC_ERR_PREAUTH_REQUIRED indicating that a 745 preauthentication field of type PA-PK-AS-REQ must be included in the 746 request. 748 Otherwise, if the first flag is clear, but the second flag is set, 749 then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED 750 indicating that a preauthentication field of type PA-PK-AS-SIGN must 751 be included in the request. 753 Lastly, if the first two flags are clear, but the third flag is set, 754 then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED 755 indicating that a preauthentication field of type PA-PK-KEY-REQ must 756 be included in the request. 758 5. Dependence on Transport Mechanisms 760 Certificate chains can potentially grow quite large and span several 761 UDP packets; this in turn increases the probability that a Kerberos 762 message involving PKINIT extensions will be broken in transit. In 763 light of the possibility that the Kerberos specification will 764 allow TCP as a transport mechanism, we solicit discussion on whether 765 using PKINIT should encourage the use of TCP. 767 6. Bibliography 769 [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service 770 (V5). Request for Comments 1510. 772 [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service 773 for Computer Networks, IEEE Communications, 32(9):33-38. September 774 1994. 776 [3] A. Medvinsky, M. Hur. Addition of Kerberos Cipher Suites to 777 Transport Layer Security (TLS). 778 draft-ietf-tls-kerb-cipher-suites-00.txt 780 [4] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing 781 Tickets for Application Servers (PKTAPP). 782 draft-ietf-cat-pktapp-00.txt 784 [5] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos 785 Using Public Key Cryptography. Symposium On Network and Distributed 786 System Security, 1997. 788 [6] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction 789 Protocol. In Proceedings of the USENIX Workshop on Electronic 790 Commerce, July 1995. 792 [7] Alan O. Freier, Philip Karlton and Paul C. Kocher. The SSL 793 Protocol, Version 3.0 - IETF Draft. 795 [8] B.C. Neuman, Proxy-Based Authorization and Accounting for 796 Distributed Systems. In Proceedings of the 13th International 797 Conference on Distributed Computing Systems, May 1993. 799 [9] ITU-T (formerly CCITT) Information technology - Open Systems 800 Interconnection - The Directory: Authentication Framework 801 Recommendation X.509 ISO/IEC 9594-8 803 7. Acknowledgements 805 Sasha Medvinsky contributed several ideas to the protocol changes 806 and specifications in this document. His additions have been most 807 appreciated. 809 Some of the ideas on which this proposal is based arose during 810 discussions over several years between members of the SAAG, the IETF 811 CAT working group, and the PSRG, regarding integration of Kerberos 812 and SPX. Some ideas have also been drawn from the DASS system. 813 These changes are by no means endorsed by these groups. This is an 814 attempt to revive some of the goals of those groups, and this 815 proposal approaches those goals primarily from the Kerberos 816 perspective. Lastly, comments from groups working on similar ideas 817 in DCE have been invaluable. 819 8. Expiration Date 821 This draft expires January 31, 1997. 823 9. Authors 825 Brian Tung 826 Clifford Neuman 827 USC Information Sciences Institute 828 4676 Admiralty Way Suite 1001 829 Marina del Rey CA 90292-6695 830 Phone: +1 310 822 1511 831 E-mail: {brian, bcn}@isi.edu 833 John Wray 834 Digital Equipment Corporation 835 550 King Street, LKG2-2/Z7 836 Littleton, MA 01460 837 Phone: +1 508 486 5210 838 E-mail: wray@tuxedo.enet.dec.com 840 Ari Medvinsky 841 Matthew Hur 842 CyberSafe Corporation 843 1605 NW Sammamish Road Suite 310 844 Issaquah WA 98027-5378 845 Phone: +1 206 391 6000 846 E-mail: {ari.medvinsky, matt.hur}@cybersafe.com 848 Jonathan Trostle 849 Novell Corporation 850 Provo UT 851 E-mail: jtrostle@novell.com