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