idnits 2.17.1 draft-ietf-cat-kerberos-pk-init-08.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): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 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 945 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.) ** 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 263: '...eValueLength INTEGER OPTIONAL...' RFC 2119 keyword, line 366: '...hanges in this section is REQUIRED for...' RFC 2119 keyword, line 380: '... trustedCertifiers [1] SEQUENCE OF PrincipalName OPTIONAL,...' RFC 2119 keyword, line 382: '... kdcCert [2] IssuerAndSerialNumber OPTIONAL...' RFC 2119 keyword, line 412: '... clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL...' (2 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 831 looks like a reference -- Missing reference section? '2' on line 834 looks like a reference -- Missing reference section? '3' on line 838 looks like a reference -- Missing reference section? '4' on line 843 looks like a reference -- Missing reference section? '5' on line 847 looks like a reference -- Missing reference section? '6' on line 851 looks like a reference -- Missing reference section? '7' on line 855 looks like a reference -- Missing reference section? '8' on line 859 looks like a reference -- Missing reference section? '9' on line 862 looks like a reference -- Missing reference section? '14' on line 882 looks like a reference -- Missing reference section? '11' on line 870 looks like a reference -- Missing reference section? '13' on line 877 looks like a reference -- Missing reference section? 'EKB' on line 333 looks like a reference -- Missing reference section? '0' on line 693 looks like a reference -- Missing reference section? '10' on line 866 looks like a reference -- Missing reference section? '12' on line 873 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 19 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-08.txt Clifford Neuman 3 Updates: RFC 1510 ISI 4 expires November 12, 1999 Matthew Hur 5 CyberSafe Corporation 6 Ari Medvinsky 7 Excite 8 Sasha Medvinsky 9 General Instrument 10 John Wray 11 Iris Associates, Inc. 12 Jonathan Trostle 13 Cisco 15 Public Key Cryptography for Initial Authentication in Kerberos 17 0. Status Of This Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC 2026. Internet-Drafts are 21 working documents of the Internet Engineering Task Force (IETF), 22 its areas, and its working groups. Note that other groups may also 23 distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 To learn the current status of any Internet-Draft, please check 38 the "1id-abstracts.txt" listing contained in the Internet-Drafts 39 Shadow Directories on ftp.ietf.org (US East Coast), 40 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 41 munnari.oz.au (Pacific Rim). 43 The distribution of this memo is unlimited. It is filed as 44 draft-ietf-cat-kerberos-pk-init-09.txt, and expires November 12, 45 1999. Please send comments to the authors. 47 1. Abstract 49 This document defines extensions (PKINIT) to the Kerberos protocol 50 specification (RFC 1510 [1]) to provide a method for using public 51 key cryptography during initial authentication. The methods 52 defined specify the ways in which preauthentication data fields and 53 error data fields in Kerberos messages are to be used to transport 54 public key data. 56 2. Introduction 58 The popularity of public key cryptography has produced a desire for 59 its support in Kerberos [2]. The advantages provided by public key 60 cryptography include simplified key management (from the Kerberos 61 perspective) and the ability to leverage existing and developing 62 public key certification infrastructures. 64 Public key cryptography can be integrated into Kerberos in a number 65 of ways. One is to associate a key pair with each realm, which can 66 then be used to facilitate cross-realm authentication; this is the 67 topic of another draft proposal. Another way is to allow users with 68 public key certificates to use them in initial authentication. This 69 is the concern of the current document. 71 PKINIT utilizes Diffie-Hellman keys in combination with digital 72 signature keys as the primary, required mechanism. It also allows 73 for the use of RSA keys. Note that PKINIT supports the use of 74 separate signature and encryption keys. 76 PKINIT enables access to Kerberos-secured services based on initial 77 authentication utilizing public key cryptography. PKINIT utilizes 78 standard public key signature and encryption data formats within the 79 standard Kerberos messages. The basic mechanism is as follows: The 80 user sends a request to the KDC as before, except that if that user 81 is to use public key cryptography in the initial authentication 82 step, his certificate and a signature accompany the initial request 83 in the preauthentication fields. Upon receipt of this request, the 84 KDC verifies the certificate and issues a ticket granting ticket 85 (TGT) as before, except that the encPart from the AS-REP message 86 carrying the TGT is now encrypted utilizing either a Diffie-Hellman 87 derived key or the user's public key. This message is authenticated 88 utilizing the public key signature of the KDC. 90 The PKINIT specification may also be used as a building block for 91 other specifications. PKCROSS [3] utilizes PKINIT for establishing 92 the inter-realm key and associated inter-realm policy to be applied 93 in issuing cross realm service tickets. As specified in [4], 94 anonymous Kerberos tickets can be issued by applying a NULL 95 signature in combination with Diffie-Hellman in the PKINIT exchange. 96 Additionally, the PKINIT specification may be used for direct peer 97 to peer authentication without contacting a central KDC. This 98 application of PKINIT is described in PKTAPP [5] and is based on 99 concepts introduced in [6, 7]. For direct client-to-server 100 authentication, the client uses PKINIT to authenticate to the end 101 server (instead of a central KDC), which then issues a ticket for 102 itself. This approach has an advantage over TLS [8] in that the 103 server does not need to save state (cache session keys). 104 Furthermore, an additional benefit is that Kerberos tickets can 105 facilitate delegation (see [9]). 107 3. Proposed Extensions 109 This section describes extensions to RFC 1510 for supporting the 110 use of public key cryptography in the initial request for a ticket 111 granting ticket (TGT). 113 In summary, the following change to RFC 1510 is proposed: 115 * Users may authenticate using either a public key pair or a 116 conventional (symmetric) key. If public key cryptography is 117 used, public key data is transported in preauthentication 118 data fields to help establish identity. The user presents 119 a public key certificate and obtains an ordinary TGT that may 120 be used for subsequent authentication, with such 121 authentication using only conventional cryptography. 123 Section 3.1 provides definitions to help specify message formats. 124 Section 3.2 describes the extensions for the initial authentication 125 method. 127 3.1. Definitions 129 The extensions involve new preauthentication fields; we introduce 130 the following preauthentication types: 132 PA-PK-AS-REQ 14 133 PA-PK-AS-REP 15 134 PA-PK-KEY-REQ 18 135 PA-PK-KEY-REP 19 137 The extensions also involve new error types; we introduce the 138 following types: 140 KDC_ERR_CLIENT_NOT_TRUSTED 62 141 KDC_ERR_KDC_NOT_TRUSTED 63 142 KDC_ERR_INVALID_SIG 64 143 KDC_ERR_KEY_TOO_WEAK 65 144 KDC_ERR_CERTIFICATE_MISMATCH 66 146 We utilize the following typed data for errors: 148 ETD-PKINIT-CMS-CERTIFICATES 101 149 ETD-KRB-PRINCIPAL 102 150 ETD-KRB-REALM 103 152 We utilize the following encryption types (which map directly to 153 OIDs): 154 sha1WithRSAEncryption-CmsOID 8 155 dsaWithSHA1-CmsOID 9 156 md4WithRsaEncryption-CmsOID 10 157 md5WithRSAEncryption-CmsOID 11 158 rc2CBC-EnvOID 12 159 rc4-EnvOID 13 161 In many cases, PKINIT requires the encoding of an X.500 name as a 162 Realm. In these cases, the realm will be represented using a 163 different style, specified in RFC 1510 with the following example: 165 NAMETYPE:rest/of.name=without-restrictions 167 For a realm derived from an X.500 name, NAMETYPE will have the value 168 X500-RFC2253. The full realm name will appear as follows: 170 X500-RFC2253:RFC2253Encode(DistinguishedName) 172 where DistinguishedName is an X.500 name, and RFC2253Encode is a 173 readable ASCII encoding of an X.500 name, as defined by 174 RFC 2253 [14] (part of LDAPv3). 176 To ensure that this encoding is unique, we add the following rule 177 to those specified by RFC 2253: 179 The order in which the attributes appear in the RFC 2253 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. The order of the relative distinguished names 183 (RDNs), as well as the order of the AttributeTypeAndValues 184 within each RDN, will be reversed. (This is despite the fact 185 that an RDN is defined as a SET of AttributeTypeAndValues, where 186 an order is normally not important.) 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 KRB_NT-X500-PRINCIPAL. This new name type is 191 defined as: 193 KRB_NT_X500_PRINCIPAL 6 195 The name-string shall be set as follows: 197 RFC2253Encode(DistinguishedName) 199 as described above. 201 Note that name mapping may be required or optional based on policy. 203 3.1.1. Encryption and Key Formats 205 In the exposition below, we use the terms public key and private 206 key generically. It should be understood that the term "public 207 key" may be used to refer to either a public encryption key or a 208 signature verification key, and that the term "private key" may be 209 used to refer to either a private decryption key or a signature 210 generation key. The fact that these are logically distinct does 211 not preclude the assignment of bitwise identical keys. 213 In the case of Diffie-Hellman, the key shall be produced from the 214 agreed bit string as follows: 216 * Truncate the bit string to the appropriate length. 217 * Rectify parity in each byte (if necessary) to obtain the key. 219 For instance, in the case of a DES key, we take the first eight 220 bytes of the bit stream, and then adjust the least significant bit 221 of each byte to ensure that each byte has odd parity. 223 3.1.2. Algorithm Identifiers 225 PKINIT does not define, but does permit, the algorithm identifiers 226 listed below. 228 3.1.2.1. Signature Algorithm Identifiers 230 These are the algorithm identifiers for use in the Signature data 231 structure as specified in CMS [11]: 233 sha-1WithRSAEncryption ALGORITHM PARAMETER NULL 234 ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 235 pkcs-1(1) 5 } 237 dsaWithSHA1 ALGORITHM PARAMETER NULL 238 ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3) 239 oIWSecAlgorithm(2) dsaWithSHA1(27) } 241 md4WithRsaEncryption ALGORITHM PARAMETER NULL 242 ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3) 243 oIWSecAlgorithm(2) md4WithRSAEncryption(4) } 245 md5WithRSAEncryption ALGORITHM PARAMETER NULL 246 ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 247 pkcs-1(1) md5WithRSAEncryption(4) } 249 3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier 251 This algorithm identifier is used inside the SubjectPublicKeyInfo 252 data structure: 254 dhKeyAgreement ALGORITHM PARAMETER DHParameters 255 ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 256 pkcs-3(3) dhKeyAgreement(1) } 258 DHParameters ::= SEQUENCE { 259 prime INTEGER, 260 -- p 261 base INTEGER, 262 -- g 263 privateValueLength INTEGER OPTIONAL 264 } -- as specified by the X.509 recommendation [9] 266 3.1.2.3. Algorithm Identifiers for RSA Encryption 268 These algorithm identifiers are used inside the EnvelopedData data 269 structure, for encrypting the temporary key with a public key: 271 id-RSAES-OAEP OBJECT IDENTIFIER 272 ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 273 pkcs-1(1) 7 } 275 3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys 277 These algorithm identifiers are used inside the EnvelopedData data 278 structure, for encrypting the temporary key with a Diffie-Hellman- 279 derived key, or for encrypting the reply key: 281 desCBC ALGORITHM PARAMETER IV8 282 ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3) 283 oIWSecAlgorithm(2) desCBC(7) } 285 DES-EDE3-CBC ALGORITHM PARAMETER IV8 286 ::= { iso(1) member-body(2) US(840) rsadsi(113549) 287 encryptionAlgorithm(3) desEDE3(7) } 289 IV8 ::= OCTET STRING (SIZE(8)) -- initialization vector 291 rc2CBC ALGORITHM PARAMETER RC2-CBCParameter 292 ::= { iso(1) member-body(2) US(840) rsadsi(113549) 293 encryptionAlgorithm(3) rc2CBC(2) } 295 The rc2CBC algorithm parameters (RC2-CBCParameter) are defined 296 in the following section. 298 rc4 ALGORITHM PARAMETER NULL 299 ::= { iso(1) member-body(2) US(840) rsadsi(113549) 300 encryptionAlgorithm(3) rc4(4) } 302 The rc4 algorithm cannot be used with the Diffie-Hellman-derived 303 keys, because its parameters do not specify the size of the key. 305 3.1.2.5. rc2CBC Algorithm Parameters 307 This definition of the RC2 parameters is taken from a paper by 308 Ron Rivest [13]. Refer to [13] for the complete description of the 309 RC2 algorithm. 311 RC2-CBCParameter ::= CHOICE { 312 iv IV, 313 params SEQUENCE { 314 version RC2Version, 315 iv IV 316 } 317 } 319 where 321 IV ::= OCTET STRING -- 8 octets 322 RC2Version ::= INTEGER -- 1-1024 324 RC2 in CBC mode has two parameters: an 8-byte initialization 325 vector (IV) and a version number in the range 1-1024 which 326 specifies in a roundabout manner the number of effective key bits 327 to be used for the RC2 encryption/decryption. 329 The correspondence between effective key bits and version number 330 is as follows: 332 1. If the number EKB of effective key bits is in the range 1-255, 333 then the version number is given by Table[EKB], where the 334 256-byte translation table is specified below. It specifies a 335 permutation on the numbers 0-255. 337 2. If the number EKB of effective key bits is in the range 338 256-1024, then the version number is simply EKB. 340 The default number of effective key bits for RC2 is 32. 341 If RC2-CBC is being performed with 32 effective key bits, the 342 parameters should be supplied as a simple IV, rather than as a 343 SEQUENCE containing a version and an IV. 345 0 1 2 3 4 5 6 7 8 9 a b c d e f 347 00: bd 56 ea f2 a2 f1 ac 2a b0 93 d1 9c 1b 33 fd d0 348 10: 30 04 b6 dc 7d df 32 4b f7 cb 45 9b 31 bb 21 5a 349 20: 41 9f e1 d9 4a 4d 9e da a0 68 2c c3 27 5f 80 36 350 30: 3e ee fb 95 1a fe ce a8 34 a9 13 f0 a6 3f d8 0c 351 40: 78 24 af 23 52 c1 67 17 f5 66 90 e7 e8 07 b8 60 352 50: 48 e6 1e 53 f3 92 a4 72 8c 08 15 6e 86 00 84 fa 353 60: f4 7f 8a 42 19 f6 db cd 14 8d 50 12 ba 3c 06 4e 354 70: ec b3 35 11 a1 88 8e 2b 94 99 b7 71 74 d3 e4 bf 355 80: 3a de 96 0e bc 0a ed 77 fc 37 6b 03 79 89 62 c6 356 90: d7 c0 d2 7c 6a 8b 22 a3 5b 05 5d 02 75 d5 61 e3 357 a0: 18 8f 55 51 ad 1f 0b 5e 85 e5 c2 57 63 ca 3d 6c 358 b0: b4 c5 cc 70 b2 91 59 0d 47 20 c8 4f 58 e0 01 e2 359 c0: 16 38 c4 6f 3b 0f 65 46 be 7e 2d 7b 82 f9 40 b5 360 d0: 1d 73 f8 eb 26 c7 87 97 25 54 b1 28 aa 98 9d a5 361 e0: 64 6d 7a d4 10 81 44 ef 49 d6 ae 2e dd 76 5c 2f 362 f0: a7 1c c9 09 69 9a 83 cf 29 39 b9 e9 4c ff 43 ab 364 3.2. Public Key Authentication 366 Implementation of the changes in this section is REQUIRED for 367 compliance with PKINIT. 369 It is assumed that all public keys are signed by some certification 370 authority (CA). The initial authentication request is sent as per 371 RFC 1510, except that a preauthentication field containing data 372 signed by the user's private key accompanies the request: 374 PA-PK-AS-REQ ::= SEQUENCE { 375 -- PA TYPE 14 376 signedAuthPack [0] SignedData 377 -- defined in CMS [11] 378 -- AuthPack (below) defines the data 379 -- that is signed 380 trustedCertifiers [1] SEQUENCE OF PrincipalName OPTIONAL, 381 -- CAs that the client trusts 382 kdcCert [2] IssuerAndSerialNumber OPTIONAL 383 -- as defined in CMS [11] 384 -- specifies a particular KDC 385 -- certificate if the client 386 -- already has it; 387 -- must be accompanied by 388 -- a single trustedCertifier 389 } 391 Usage of SignedData: 392 The SignedData data type is specified in the Cryptographic 393 Message Syntax, a product of the S/MIME working group of the IETF. 394 - The encapContentInfo field must contain the PKAuthenticator 395 and, optionally, the client's Diffie Hellman public value. 396 - The eContentType field shall contain the OID value for 397 id-data: iso(1) member-body(2) us(840) rsadsi(113549) 398 pkcs(1) pkcs7(7) data(1) 399 - The eContent field is data of the type AuthPack (below). 400 - The signerInfos field is a SET of SignerInfo that is required by 401 CMS; however, the set may contain zero elements. When non-empty, 402 this field contains the client's certificate chain. If present, 403 the KDC uses the public key from the client's certificate to 404 verify the signature in the request. Note that the client may 405 pass different certificates that are used for signing or for 406 encrypting. Thus, the KDC may utilize a different client 407 certificate for signature verification than the one it uses to 408 encrypt the reply to the client. 410 AuthPack ::= SEQUENCE { 411 pkAuthenticator [0] PKAuthenticator, 412 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL 413 -- if client is using Diffie-Hellman 414 } 416 PKAuthenticator ::= SEQUENCE { 417 kdcName [0] PrincipalName, 418 kdcRealm [1] Realm, 419 cusec [2] INTEGER, 420 -- for replay prevention 421 ctime [3] KerberosTime, 422 -- for replay prevention 423 nonce [4] INTEGER 424 } 426 SubjectPublicKeyInfo ::= SEQUENCE { 427 algorithm AlgorithmIdentifier, 428 -- dhKeyAgreement 429 subjectPublicKey BIT STRING 430 -- for DH, equals 431 -- public exponent (INTEGER encoded 432 -- as payload of BIT STRING) 433 } -- as specified by the X.509 recommendation [9] 435 AlgorithmIdentifier ::= SEQUENCE { 436 algorithm ALGORITHM.&id, 437 parameters ALGORITHM.&type 438 } -- as specified by the X.509 recommendation [10] 440 If the client passes an issuer and serial number in the request, 441 the KDC is requested to use the referred-to certificate. If none 442 exists, then the KDC returns an error of type 443 KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the 444 other hand, the client does not pass any trustedCertifiers, 445 believing that it has the KDC's certificate, but the KDC has more 446 than one certificate. The KDC should include information in the 447 KRB-ERROR message that indicates the KDC certificate(s) that a 448 client may utilize. This data is specified in the e-typed-data 449 type as follows: 451 ETypedData ::= SEQUENCE { 452 e-data-type [1] INTEGER, 453 e-data-value [2] OCTET STRING, 454 } -- per Kerberos RFC 1510 revisions 456 where: 457 e-data-type = ETD-PKINIT-CMS-CERTIFICATES = 101 458 e-data-value = CertificateSet // as specified by CMS [11] 460 The PKAuthenticator carries information to foil replay attacks, 461 to bind the request and response. The PKAuthenticator is signed 462 with the private key corresponding to the public key in the 463 certificate found in userCert (or cached by the KDC). 465 The trustedCertifiers field contains a list of certification 466 authorities trusted by the client, in the case that the client does 467 not possess the KDC's public key certificate. If the KDC has no 468 certificate signed by any of the trustedCertifiers, then it returns 469 an error of type KDC_ERR_KDC_NOT_TRUSTED. 471 KDCs should try to (in order of preference): 472 1. Use the KDC certificate identified by the serialNumber included 473 in the client's request. 474 2. Use a certificate issued to the KDC by the client's CA (if in the 475 middle of a CA key roll-over, use the KDC cert issued under same 476 CA key as user cert used to verify request). 477 3. Use a certificate issued to the KDC by one of the client's 478 trustedCertifier(s); 479 If the KDC is unable to comply with any of these options, then the 480 KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the 481 client. 483 Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication 484 type, the KDC attempts to verify the user's certificate chain 485 (userCert), if one is provided in the request. This is done by 486 verifying the certification path against the KDC's policy of 487 legitimate certifiers. This may be based on a certification 488 hierarchy, or it may be simply a list of recognized certifiers in a 489 system like PGP. 491 If verification of the user's certificate fails, the KDC sends back 492 an error message of type KDC_ERR_CLIENT_NOT_TRUSTED. The e-data 493 field contains additional information pertaining to this error, and 494 is formatted as follows: 496 METHOD-DATA ::= SEQUENCE { 497 method-type [0] INTEGER, 498 -- 0 = not specified 499 -- 1 = cannot verify public key 500 -- 2 = invalid certificate 501 -- 3 = revoked certificate 502 -- 4 = invalid KDC name 503 -- 5 = client name mismatch 504 method-data [1] OCTET STRING OPTIONAL 505 } -- syntax as for KRB_AP_ERR_METHOD (RFC 1510) 507 The values for the method-type and method-data fields are described 508 in Section 3.2.1. 510 If a trust relationship exists, the KDC then verifies the client's 511 signature on AuthPack. If that fails, the KDC returns an error 512 message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the 513 timestamp (ctime and cusec) in the PKAuthenticator to assure that 514 the request is not a replay. The KDC also verifies that its name 515 is specified in the PKAuthenticator. 517 If the clientPublicValue field is filled in, indicating that the 518 client wishes to use Diffie-Hellman key agreement, then the KDC 519 checks to see that the parameters satisfy its policy. If they do 520 not (e.g., the prime size is insufficient for the expected 521 encryption type), then the KDC sends back an error message of type 522 KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and 523 private values for the response. 525 The KDC also checks that the timestamp in the PKAuthenticator is 526 within the allowable window and that the principal name and realm 527 are correct. If the local (server) time and the client time in the 528 authenticator differ by more than the allowable clock skew, then the 529 KDC returns an error message of type KRB_AP_ERR_SKEW. If the 530 principal name or realm do not match the KDC, then the KDC returns 531 an error message of type KDC_ERR_NAME_MISMATCH for which the 532 e-typed-data may contain the correct name to use 533 (EDT-KRB-PRINCIPAL=102 or EDT-KRB-REALM=103 where 534 e-data-value = PrincipalName or Realm as defined by RFC 1510). 536 Assuming no errors, the KDC replies as per RFC 1510, except as 537 follows. The user's name in the ticket is determined by the 538 following decision algorithm: 540 1. If the KDC has a mapping from the name in the certificate 541 to a Kerberos name, then use that name. 542 Else 543 2. If the certificate contains a Kerberos name in an extension 544 field, and local KDC policy allows, then use that name. 545 Else 546 3. Use the name as represented in the certificate, mapping 547 as necessary (e.g., as per RFC 2253 for X.500 names). In 548 this case the realm in the ticket shall be the name of the 549 certification authority that issued the user's certificate. 551 The KDC encrypts the reply not with the user's long-term key, but 552 with a random key generated only for this particular response. This 553 random key is sealed in the preauthentication field: 555 PA-PK-AS-REP ::= CHOICE { 556 -- PA TYPE 15 557 dhSignedData [0] SignedData, 558 -- Defined in CMS and used only with 559 -- Diffie-Helman key exchange 560 encKeyPack [1] EnvelopedData, 561 -- Defined in CMS 562 -- The temporary key is encrypted 563 -- using the client public key 564 -- key 565 -- SignedReplyKeyPack, encrypted 566 -- with the temporary key, is also 567 -- included. 568 } 570 Usage of SignedData: 571 If the Diffie-Hellman option is used, dhSignedData in PA-PK-AS-REP 572 provides authenticated Diffie-Hellman parameters of the KDC. The 573 reply key used to encrypt part of the KDC reply message is derived 574 from the Diffie-Hellman exchange: 575 - Both the KDC and the client calculate a secret value (g^ab mod p), 576 where a is the client's private exponent and b is the KDC's 577 private exponent. 578 - Both the KDC and the client take the first N bits of this secret 579 value and convert it into a reply key. N depends on the reply key 580 type. 581 - If the reply key is DES, N=64 bits, where some of the bits are 582 replaced with parity bits, according to FIPS PUB 74. 583 - If the reply key is (3-key) 3-DES, N=192 bits, where some of the 584 bits are replaced with parity bits, according to FIPS PUB 74. 585 - The encapContentInfo field must contain the KdcDHKeyInfo as 586 defined below. 587 - The eContentType field shall contain the OID value for 588 id-data: iso(1) member-body(2) us(840) rsadsi(113549) 589 pkcs(1) pkcs7(7) data(1) 590 - The certificates field must contain the certificates necessary 591 for the client to establish trust in the KDC's certificate 592 based on the list of trusted certifiers sent by the client in 593 the PA-PK-AS-REQ. This field may be empty if the client did 594 not send to the KDC a list of trusted certifiers (the 595 trustedCertifiers field was empty, meaning that the client 596 already possesses the KDC's certificate). 597 - The signerInfos field is a SET that must contain at least one 598 member, since it contains the actual signature. 600 Usage of EnvelopedData: 601 The EnvelopedData data type is specified in the Cryptographic 602 Message Syntax, a product of the S/MIME working group of the IETF. 603 It contains an temporary key encrypted with the PKINIT 604 client's public key. It also contains a signed and encrypted 605 reply key. 606 - The originatorInfo field is not required, since that information 607 may be presented in the signedData structure that is encrypted 608 within the encryptedContentInfo field. 609 - The optional unprotectedAttrs field is not required for PKINIT. 610 - The recipientInfos field is a SET which must contain exactly one 611 member of the KeyTransRecipientInfo type for encryption 612 with an RSA public key. 613 - The encryptedKey field (in KeyTransRecipientInfo) contains 614 the temporary key which is encrypted with the PKINIT client's 615 public key. 616 - The encryptedContentInfo field contains the signed and encrypted 617 reply key. 618 - The contentType field shall contain the OID value for 619 id-signedData: iso(1) member-body(2) us(840) rsadsi(113549) 620 pkcs(1) pkcs7(7) signedData(2) 621 - The encryptedContent field is encrypted data of the CMS type 622 signedData as specified below. 623 - The encapContentInfo field must contains the ReplyKeyPack. 624 - The eContentType field shall contain the OID value for 625 id-data: iso(1) member-body(2) us(840) rsadsi(113549) 626 pkcs(1) pkcs7(7) data(1) 627 - The eContent field is data of the type ReplyKeyPack (below). 628 - The certificates field must contain the certificates necessary 629 for the client to establish trust in the KDC's certificate 630 based on the list of trusted certifiers sent by the client in 631 the PA-PK-AS-REQ. This field may be empty if the client did 632 not send to the KDC a list of trusted certifiers (the 633 trustedCertifiers field was empty, meaning that the client 634 already possesses the KDC's certificate). 635 - The signerInfos field is a SET that must contain at least one 636 member, since it contains the actual signature. 638 KdcDHKeyInfo ::= SEQUENCE { 639 -- used only when utilizing Diffie-Hellman 640 nonce [0] INTEGER, 641 -- binds responce to the request 642 subjectPublicKey [2] BIT STRING 643 -- Equals public exponent (g^a mod p) 644 -- INTEGER encoded as payload of 645 -- BIT STRING 646 } 648 ReplyKeyPack ::= SEQUENCE { 649 -- not used for Diffie-Hellman 650 replyKey [0] EncryptionKey, 651 -- used to encrypt main reply 652 -- ENCTYPE is at least as strong as 653 -- ENCTYPE of session key 654 nonce [1] INTEGER, 655 -- binds response to the request 656 -- must be same as the nonce 657 -- passed in the PKAuthenticator 658 } 660 Since each certifier in the certification path of a user's 661 certificate is essentially a separate realm, the name of each 662 certifier must be added to the transited field of the ticket. The 663 format of these realm names is defined in Section 3.1 of this 664 document. If applicable, the transit-policy-checked flag should be 665 set in the issued ticket. 667 The KDC's certificate must bind the public key to a name derivable 668 from the name of the realm for that KDC. X.509 certificates shall 669 contain the principal name of the KDC as the SubjectAltName version 670 3 extension. Below is the definition of this version 3 extension, as 671 specified by the X.509 standard: 673 subjectAltName EXTENSION ::= { 674 SYNTAX GeneralNames 675 IDENTIFIED BY id-ce-subjectAltName 676 } 678 GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName 680 GeneralName ::= CHOICE { 681 otherName [0] INSTANCE OF OTHER-NAME, 682 ... 683 } 685 OTHER-NAME ::= TYPE-IDENTIFIER 687 In this definition, otherName is a name of any form defined as an 688 instance of the OTHER-NAME information object class. For the purpose 689 of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will 690 be replaced by the type KerberosPrincipalName: 692 KerberosPrincipalName ::= SEQUENCE { 693 nameType [0] OTHER-NAME.&id ( { PrincipalNameTypes } ), 694 name [1] OTHER-NAME.&type ( { PrincipalNameTypes } 695 { @nameType } ) 696 } 698 PrincipalNameTypes OTHER-NAME ::= { 699 { PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst } 700 } 702 PrincipalNameSrvInst ::= GeneralString 704 where (from the Kerberos specification) we have 706 krb5 OBJECT IDENTIFIER ::= { iso (1) 707 org (3) 708 dod (6) 709 internet (1) 710 security (5) 711 kerberosv5 (2) } 713 principalName OBJECT IDENTIFIER ::= { krb5 2 } 715 principalNameSrvInst OBJECT IDENTIFIER ::= { principalName 2 } 717 (This specification can also be used to specify a Kerberos name 718 within the user's certificate.) 720 The client then extracts the random key used to encrypt the main 721 reply. This random key (in encPaReply) is encrypted with either the 722 client's public key or with a key derived from the DH values 723 exchanged between the client and the KDC. 725 3.2.1. Additional Information for Errors 727 This section describes the interpretation of the method-type and 728 method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error. 730 If method-type=1, the client's public key certificate chain does not 731 contain a certificate that is signed by a certification authority 732 trusted by the KDC. The format of the method-data field will be an 733 ASN.1 encoding of a list of trusted certifiers, as defined above: 735 TrustedCertifiers ::= SEQUENCE OF PrincipalName 737 If method-type=2, the signature on one of the certificates in the 738 chain cannot be verified. The format of the method-data field will 739 be an ASN.1 encoding of the integer index of the certificate in 740 question: 742 CertificateIndex ::= INTEGER 743 -- 0 = 1st certificate, 744 -- 1 = 2nd certificate, etc 746 If method-type=3, one of the certificates in the chain has been 747 revoked. The format of the method-data field will be an ASN.1 748 encoding of the integer index of the certificate in question: 750 CertificateIndex ::= INTEGER 751 -- 0 = 1st certificate, 752 -- 1 = 2nd certificate, etc 754 If method-type=4, the KDC name or realm in the PKAuthenticator does 755 not match the principal name of the KDC. There is no method-data 756 field in this case. 758 If method-type=5, the client name or realm in the certificate does 759 not match the principal name of the client. There is no 760 method-data field in this case. 762 3.2.2. Required Algorithms 764 Not all of the algorithms in the PKINIT protocol specification have 765 to be implemented in order to comply with the proposed standard. 766 Below is a list of the required algorithms: 768 - Diffie-Hellman public/private key pairs 769 - SHA1 digest and DSA for signatures 770 - 3-key triple DES keys derived from the Diffie-Hellman Exchange 771 - 3-key triple DES Temporary and Reply keys 773 4. Logistics and Policy 775 This section describes a way to define the policy on the use of 776 PKINIT for each principal and request. 778 The KDC is not required to contain a database record for users 779 that use either the Standard Public Key Authentication. However, 780 if these users are registered with the KDC, it is recommended that 781 the database record for these users be modified to an additional 782 flag in the attributes field to indicate that the user should 783 authenticate using PKINIT. If this flag is set and a request 784 message does not contain the PKINIT preauthentication field, then 785 the KDC sends back as error of type KDC_ERR_PREAUTH_REQUIRED 786 indicating that a preauthentication field of type PA-PK-AS-REQ must 787 be included in the request. 789 5. Security Considerations 791 PKINIT raises a few security considerations, which we will address 792 in this section. 794 First of all, PKINIT introduces a new trust model, where KDCs do not 795 (necessarily) certify the identity of those for whom they issue 796 tickets. PKINIT does allow KDCs to act as their own CAs, in order 797 to simplify key management, but one of the additional benefits is to 798 align Kerberos authentication with a global public key 799 infrastructure. Anyone using PKINIT in this way must be aware of 800 how the certification infrastructure they are linking to works. 802 Secondly, PKINIT also introduces the possibility of interactions 803 between different cryptosystems, which may be of widely varying 804 strengths. Many systems, for instance, allow the use of 512-bit 805 public keys. Using such keys to wrap data encrypted under strong 806 conventional cryptosystems, such as triple-DES, is inappropriate; 807 it adds a weak link to a strong one at extra cost. Implementors 808 and administrators should take care to avoid such wasteful and 809 deceptive interactions. 811 Lastly, PKINIT calls for randomly generated keys for conventional 812 cryptosystems. Many such systems contain systematically "weak" 813 keys. PKINIT implementations MUST avoid use of these keys, either 814 by discarding those keys when they are generated, or by fixing them 815 in some way (e.g., by XORing them with a given mask). These 816 precautions vary from system to system; it is not our intention to 817 give an explicit recipe for them here. 819 6. Transport Issues 821 Certificate chains can potentially grow quite large and span several 822 UDP packets; this in turn increases the probability that a Kerberos 823 message involving PKINIT extensions will be broken in transit. In 824 light of the possibility that the Kerberos specification will 825 require KDCs to accept requests using TCP as a transport mechanism, 826 we make the same recommendation with respect to the PKINIT 827 extensions as well. 829 7. Bibliography 831 [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service 832 (V5). Request for Comments 1510. 834 [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service 835 for Computer Networks, IEEE Communications, 32(9):33-38. September 836 1994. 838 [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld, 839 A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm 840 Authentication in Kerberos. 841 draft-ietf-cat-kerberos-pk-cross-04.txt 843 [4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in 844 Kerberos. 845 draft-ietf-cat-kerberos-anoncred-00.txt 847 [5] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing 848 Tickets for Application Servers (PKTAPP). 849 draft-ietf-cat-pktapp-00.txt 851 [6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos 852 Using Public Key Cryptography. Symposium On Network and Distributed 853 System Security, 1997. 855 [7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction 856 Protocol. In Proceedings of the USENIX Workshop on Electronic 857 Commerce, July 1995. 859 [8] T. Dierks, C. Allen. The TLS Protocol, Version 1.0 860 Request for Comments 2246, January 1999. 862 [9] B.C. Neuman, Proxy-Based Authorization and Accounting for 863 Distributed Systems. In Proceedings of the 13th International 864 Conference on Distributed Computing Systems, May 1993. 866 [10] ITU-T (formerly CCITT) Information technology - Open Systems 867 Interconnection - The Directory: Authentication Framework 868 Recommendation X.509 ISO/IEC 9594-8 870 [11] R. Housley. Cryptographic Message Syntax. 871 draft-ietf-smime-cms-10.txt, December 1998. 873 [12] PKCS #7: Cryptographic Message Syntax Standard, 874 An RSA Laboratories Technical Note Version 1.5 875 Revised November 1, 1993 877 [13] R. Rivest, MIT Laboratory for Computer Science and RSA Data 878 Security, Inc. A Description of the RC2(r) Encryption Algorithm 879 March 1998. 880 Request for Comments 2268. 882 [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access 883 Protocol (v3): UTF-8 String Representation of Distinguished Names. 884 Request for Comments 2253. 886 8. Acknowledgements 888 Some of the ideas on which this proposal is based arose during 889 discussions over several years between members of the SAAG, the IETF 890 CAT working group, and the PSRG, regarding integration of Kerberos 891 and SPX. Some ideas have also been drawn from the DASS system. 892 These changes are by no means endorsed by these groups. This is an 893 attempt to revive some of the goals of those groups, and this 894 proposal approaches those goals primarily from the Kerberos 895 perspective. Lastly, comments from groups working on similar ideas 896 in DCE have been invaluable. 898 9. Expiration Date 900 This draft expires November 12, 1999. 902 10. Authors 904 Brian Tung 905 Clifford Neuman 906 USC Information Sciences Institute 907 4676 Admiralty Way Suite 1001 908 Marina del Rey CA 90292-6695 909 Phone: +1 310 822 1511 910 E-mail: {brian, bcn}@isi.edu 912 Matthew Hur 913 CyberSafe Corporation 914 1605 NW Sammamish Road 915 Issaquah WA 98027-5378 916 Phone: +1 425 391 6000 917 E-mail: matt.hur@cybersafe.com 919 Ari Medvinsky 920 Excite 921 555 Broadway 922 Redwood City, CA 94063 923 Phone +1 650 569 2119 924 E-mail: amedvins@excitecorp.com 926 Sasha Medvinsky 927 General Instrument 928 6450 Sequence Drive 929 San Diego, CA 92121 930 Phone +1 619 404 2825 931 E-mail: smedvinsky@gi.com 933 John Wray 934 Iris Associates, Inc. 935 5 Technology Park Dr. 936 Westford, MA 01886 937 E-mail: John_Wray@iris.com 939 Jonathan Trostle 940 170 W. Tasman Dr. 941 San Jose, CA 95134 942 E-mail: jtrostle@cisco.com