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