idnits 2.17.1 draft-ietf-cat-kerberos-pk-init-09.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 909 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 297: '...hanges in this section is REQUIRED for...' RFC 2119 keyword, line 311: '... trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL,...' RFC 2119 keyword, line 313: '... kdcCert [2] IssuerAndSerialNumber OPTIONAL...' RFC 2119 keyword, line 320: '... encryptionCert [3] IssuerAndSerialNumber OPTIONAL...' RFC 2119 keyword, line 334: '... issuerAndSerial [2] IssuerAndSerialNumber OPTIONAL...' (3 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 783 looks like a reference -- Missing reference section? '2' on line 786 looks like a reference -- Missing reference section? '3' on line 790 looks like a reference -- Missing reference section? '4' on line 795 looks like a reference -- Missing reference section? '5' on line 799 looks like a reference -- Missing reference section? '6' on line 803 looks like a reference -- Missing reference section? '7' on line 807 looks like a reference -- Missing reference section? '8' on line 811 looks like a reference -- Missing reference section? '9' on line 814 looks like a reference -- Missing reference section? '14' on line 834 looks like a reference -- Missing reference section? '0' on line 676 looks like a reference -- Missing reference section? '11' on line 822 looks like a reference -- Missing reference section? '15' on line 838 looks like a reference -- Missing reference section? '16' on line 842 looks like a reference -- Missing reference section? '10' on line 818 looks like a reference -- Missing reference section? '17' on line 846 looks like a reference -- Missing reference section? '12' on line 825 looks like a reference -- Missing reference section? '13' on line 829 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 21 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-09.txt Clifford Neuman 3 Updates: RFC 1510 ISI 4 expires December 1, 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 December 1, 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 135 The extensions also involve new error types; we introduce the 136 following types: 138 KDC_ERR_CLIENT_NOT_TRUSTED 62 139 KDC_ERR_KDC_NOT_TRUSTED 63 140 KDC_ERR_INVALID_SIG 64 141 KDC_ERR_KEY_TOO_WEAK 65 142 KDC_ERR_CERTIFICATE_MISMATCH 66 143 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 144 KDC_ERR_INVALID_CERTIFICATE 71 145 KDC_ERR_REVOKED_CERTIFICATE 72 146 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 147 KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 148 KDC_ERR_CLIENT_NAME_MISMATCH 75 149 KDC_ERR_KDC_NAME_MISMATCH 76 151 We utilize the following typed data for errors: 153 TD-PKINIT-CMS-CERTIFICATES 101 154 TD-KRB-PRINCIPAL 102 155 TD-KRB-REALM 103 156 TD-TRUSTED-CERTIFIERS 104 157 TD-CERTIFICATE-INDEX 105 159 We utilize the following encryption types (which map directly to 160 OIDs): 162 dsaWithSHA1-CmsOID 9 163 md5WithRSAEncryption-CmsOID 10 164 sha1WithRSAEncryption-CmsOID 11 165 rc2CBC-EnvOID 12 166 rsaEncryption-EnvOID (PKCS#1 v1.5) 13 167 rsaES-OAEP-ENV-OID (PKCS#1 v2.0) 14 168 des-ede3-cbc-Env-OID 15 170 These mappings are provided so that a client may send the 171 appropriate enctypes in the AS-REQ message in order to indicate 172 support for the corresponding OIDs (for performing PKINIT). 174 In many cases, PKINIT requires the encoding of an X.500 name as a 175 Realm. In these cases, the realm will be represented using a 176 different style, specified in RFC 1510 with the following example: 178 NAMETYPE:rest/of.name=without-restrictions 180 For a realm derived from an X.500 name, NAMETYPE will have the value 181 X500-RFC2253. The full realm name will appear as follows: 183 X500-RFC2253:RFC2253Encode(DistinguishedName) 185 where DistinguishedName is an X.500 name, and RFC2253Encode is a 186 readable UTF encoding of an X.500 name, as defined by 187 RFC 2253 [14] (part of LDAPv3). 189 To ensure that this encoding is unique, we add the following rule 190 to those specified by RFC 2253: 192 The order in which the attributes appear in the RFC 2253 193 encoding must be the reverse of the order in the ASN.1 194 encoding of the X.500 name that appears in the public key 195 certificate. The order of the relative distinguished names 196 (RDNs), as well as the order of the AttributeTypeAndValues 197 within each RDN, will be reversed. (This is despite the fact 198 that an RDN is defined as a SET of AttributeTypeAndValues, where 199 an order is normally not important.) 201 Similarly, PKINIT may require the encoding of an X.500 name as a 202 PrincipalName. In these cases, the name-type of the principal name 203 shall be set to KRB_NT-X500-PRINCIPAL. This new name type is 204 defined as: 206 KRB_NT_X500_PRINCIPAL 6 208 The name-string shall be set as follows: 210 RFC2253Encode(DistinguishedName) 212 as described above. 214 RFC 1510 specifies the ASN.1 structure for PrincipalName as follows: 216 PrincipalName ::= SEQUENCE { 217 name-type[0] INTEGER, 218 name-string[1] SEQUENCE OF GeneralString 219 } 221 For the purposes of encoding an X.500 name within this structure, 222 the name-string shall be encoded as a single GeneralString. 224 Note that name mapping may be required or optional based on 225 policy. 227 3.1.1. Encryption and Key Formats 229 In the exposition below, we use the terms public key and private 230 key generically. It should be understood that the term "public 231 key" may be used to refer to either a public encryption key or a 232 signature verification key, and that the term "private key" may be 233 used to refer to either a private decryption key or a signature 234 generation key. The fact that these are logically distinct does 235 not preclude the assignment of bitwise identical keys. 237 In the case of Diffie-Hellman, the key shall be produced from the 238 agreed bit string as follows: 240 * Truncate the bit string to the appropriate length. 241 * Rectify parity in each byte (if necessary) to obtain the key. 243 For instance, in the case of a DES key, we take the first eight 244 bytes of the bit stream, and then adjust the least significant bit 245 of each byte to ensure that each byte has odd parity. 247 3.1.2. Algorithm Identifiers 249 PKINIT does not define, but does permit, the algorithm identifiers 250 listed below. 252 3.1.2.1. Signature Algorithm Identifiers 254 The following signature algorithm identifiers specified in [11] and 255 in [15] shall be used with PKINIT: 257 id-dsa-with-sha1 (DSA with SHA1) 258 md5WithRSAEncryption (RSA with MD5) 259 sha-1WithRSAEncryption (RSA with SHA1) 261 3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier 263 The following algorithm identifier shall be used within the 264 SubjectPublicKeyInfo data structure: dhpublicnumber 266 This identifier and the associated algorithm parameters are 267 specified in RFC 2459 [15]. 269 3.1.2.3. Algorithm Identifiers for RSA Encryption 271 These algorithm identifiers are used inside the EnvelopedData data 272 structure, for encrypting the temporary key with a public key: 274 rsaEncryption (RSA encryption, PKCS#1 v1.5) 275 id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0) 277 Both of the above RSA encryption schemes are specified in [16]. 278 Currently, only PKCS#1 v1.5 is specified by CMS [11], although the 279 CMS specification says that it will likely include PKCS#1 v2.0 in 280 the future. (PKCS#1 v2.0 addresses adaptive chosen ciphertext 281 vulnerability discovered in PKCS#1 v1.5.) 283 3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys 285 These algorithm identifiers are used inside the EnvelopedData data 286 structure in the PKINIT Reply, for encrypting the reply key with the 287 temporary key: 288 des-ede3-cbc (3-key 3-DES, CBC mode) 289 rc2-cbc (RC2, CBC mode) 291 The full definition of the above algorithm identifiers and their 292 corresponding parameters (an IV for block chaining) is provided in 293 the CMS specification [11]. 295 3.2. Public Key Authentication 297 Implementation of the changes in this section is REQUIRED for 298 compliance with PKINIT. 300 It is assumed that all public keys are signed by some certification 301 authority (CA). The initial authentication request is sent as per 302 RFC 1510, except that a preauthentication field containing data 303 signed by the user's private key accompanies the request: 305 PA-PK-AS-REQ ::= SEQUENCE { 306 -- PA TYPE 14 307 signedAuthPack [0] SignedData 308 -- defined in CMS [11] 309 -- AuthPack (below) defines the data 310 -- that is signed 311 trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL, 312 -- CAs that the client trusts 313 kdcCert [2] IssuerAndSerialNumber OPTIONAL 314 -- as defined in CMS [11] 315 -- specifies a particular KDC 316 -- certificate if the client 317 -- already has it; 318 -- must be accompanied by 319 -- a single trustedCertifier 320 encryptionCert [3] IssuerAndSerialNumber OPTIONAL 321 -- For example, this may be the 322 -- client's Diffie-Hellman 323 -- certificate, or it may be the 324 -- client's RSA encryption 325 -- certificate. 326 } 328 TrustedCas ::= CHOICE { 329 principalName [0] KerberosName, 330 -- as defined below 331 caName [1] Name 332 -- fully qualified X.500 name 333 -- as defined by X.509 334 issuerAndSerial [2] IssuerAndSerialNumber OPTIONAL 335 -- Since a CA may have a number of 336 -- certificates, only one of which 337 -- a client trusts 338 } 340 Usage of SignedData: 341 The SignedData data type is specified in the Cryptographic 342 Message Syntax, a product of the S/MIME working group of the IETF. 343 - The encapContentInfo field must contain the PKAuthenticator 344 and, optionally, the client's Diffie Hellman public value. 345 - The eContentType field shall contain the OID value for 346 id-data: iso(1) member-body(2) us(840) rsadsi(113549) 347 pkcs(1) pkcs7(7) data(1) 348 - The eContent field is data of the type AuthPack (below). 349 - The signerInfos field contains the signature of AuthPack. 350 - The Certificates field, when non-empty, contains the client's 351 certificate chain. If present, the KDC uses the public key from 352 the client's certificate to verify the signature in the request. 353 Note that the client may pass different certificates that are used 354 for signing or for encrypting. Thus, the KDC may utilize a 355 different client certificate for signature verification than the 356 one it uses to encrypt the reply to the client. For example, the 357 client may place a Diffie-Hellman certificate in this field in 358 order to convey its static Diffie Hellman certificate to the KDC 359 enable static-ephemeral Diffie-Hellman mode for the reply. As 360 another example, the client may place an RSA encryption 361 certificate in this field. 363 AuthPack ::= SEQUENCE { 364 pkAuthenticator [0] PKAuthenticator, 365 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL 366 -- if client is using Diffie-Hellman 367 } 369 PKAuthenticator ::= SEQUENCE { 370 kdcName [0] PrincipalName, 371 kdcRealm [1] Realm, 372 cusec [2] INTEGER, 373 -- for replay prevention 374 ctime [3] KerberosTime, 375 -- for replay prevention 376 nonce [4] INTEGER 377 } 379 SubjectPublicKeyInfo ::= SEQUENCE { 380 algorithm AlgorithmIdentifier, 381 -- dhKeyAgreement 382 subjectPublicKey BIT STRING 383 -- for DH, equals 384 -- public exponent (INTEGER encoded 385 -- as payload of BIT STRING) 386 } -- as specified by the X.509 recommendation [10] 388 AlgorithmIdentifier ::= SEQUENCE { 389 algorithm ALGORITHM.&id, 390 parameters ALGORITHM.&type 391 } -- as specified by the X.509 recommendation [10] 393 If the client passes an issuer and serial number in the request, 394 the KDC is requested to use the referred-to certificate. If none 395 exists, then the KDC returns an error of type 396 KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the 397 other hand, the client does not pass any trustedCertifiers, 398 believing that it has the KDC's certificate, but the KDC has more 399 than one certificate. The KDC should include information in the 400 KRB-ERROR message that indicates the KDC certificate(s) that a 401 client may utilize. This data is specified in the e-data, which 402 is defined in RFC 1510 revisions as a SEQUENCE of TypedData: 404 TypedData ::= SEQUENCE { 405 data-type [0] INTEGER, 406 data-value [1] OCTET STRING, 407 } -- per Kerberos RFC 1510 revisions 409 where: 410 data-type = TD-PKINIT-CMS-CERTIFICATES = 101 411 data-value = CertificateSet // as specified by CMS [11] 413 The PKAuthenticator carries information to foil replay attacks, 414 to bind the request and response. The PKAuthenticator is signed 415 with the private key corresponding to the public key in the 416 certificate found in userCert (or cached by the KDC). 418 The trustedCertifiers field contains a list of certification 419 authorities trusted by the client, in the case that the client does 420 not possess the KDC's public key certificate. If the KDC has no 421 certificate signed by any of the trustedCertifiers, then it returns 422 an error of type KDC_ERR_KDC_NOT_TRUSTED. 424 KDCs should try to (in order of preference): 425 1. Use the KDC certificate identified by the serialNumber included 426 in the client's request. 427 2. Use a certificate issued to the KDC by the client's CA (if in the 428 middle of a CA key roll-over, use the KDC cert issued under same 429 CA key as user cert used to verify request). 430 3. Use a certificate issued to the KDC by one of the client's 431 trustedCertifier(s); 432 If the KDC is unable to comply with any of these options, then the 433 KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the 434 client. 436 Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication 437 type, the KDC attempts to verify the user's certificate chain 438 (userCert), if one is provided in the request. This is done by 439 verifying the certification path against the KDC's policy of 440 legitimate certifiers. This may be based on a certification 441 hierarchy, or it may be simply a list of recognized certifiers in a 442 system like PGP. 444 If the client's certificate chain contains no certificate signed by 445 a CA trusted by the KDC, then the KDC sends back an error message 446 of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data 447 is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104) 448 whose data-value is an OCTET STRING which is the DER encoding of 450 TrustedCertifiers ::= SEQUENCE OF PrincipalName 451 -- X.500 name encoded as a principal name 452 -- see Section 3.1 454 If the signature on one of the certificates in the client's chain 455 fails verification, then the KDC returns an error of type 456 KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data is a SEQUENCE 457 of one TypedData (with type TD-CERTIFICATE-INDEX=105) whose 458 data-value is an OCTET STRING which is the DER encoding of 460 CertificateIndex ::= INTEGER 461 -- 0 = 1st certificate, 462 -- (in order of encoding) 463 -- 1 = 2nd certificate, etc 465 The KDC may also check whether any of the certificates in the 466 client's chain has been revoked. If one of the certificates has 467 been revoked, then the KDC returns an error of type 468 KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that the 469 certificate's revocation status is unknown, the KDC returns an 470 error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN; if the revocation 471 status is unavailable, the KDC returns an error of type 472 KDC_ERR_REVOCATION_STATUS_UNAVAILABLE. In any of these three 473 cases, the affected certificate is identified by the accompanying 474 e-data, which contains a CertificateIndex as described for 475 KDC_ERR_INVALID_CERTIFICATE. 477 If the certificate chain can be verified, but the name of the 478 client in the certificate does not match the client's name in the 479 request, then the KDC returns an error of type 480 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data 481 field in this case. 483 Finally, if the certificate chain is verified, but the KDC's name 484 or realm as given in the PKAuthenticator does not match the KDC's 485 actual principal name, then the KDC returns an error of type 486 KDC_ERR_KDC_NAME_MISMATCH. The accompanying e-data field is again 487 a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or 488 TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET 489 STRING whose data-value is the DER encoding of a PrincipalName or 490 Realm as defined in RFC 1510 revisions. 492 Even if all succeeds, the KDC may--for policy reasons--decide not 493 to trust the client. In this case, the KDC returns an error message 494 of type KDC_ERR_CLIENT_NOT_TRUSTED. 496 If a trust relationship exists, the KDC then verifies the client's 497 signature on AuthPack. If that fails, the KDC returns an error 498 message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the 499 timestamp (ctime and cusec) in the PKAuthenticator to assure that 500 the request is not a replay. The KDC also verifies that its name 501 is specified in the PKAuthenticator. 503 If the clientPublicValue field is filled in, indicating that the 504 client wishes to use Diffie-Hellman key agreement, then the KDC 505 checks to see that the parameters satisfy its policy. If they do 506 not (e.g., the prime size is insufficient for the expected 507 encryption type), then the KDC sends back an error message of type 508 KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and 509 private values for the response. 511 The KDC also checks that the timestamp in the PKAuthenticator is 512 within the allowable window and that the principal name and realm 513 are correct. If the local (server) time and the client time in the 514 authenticator differ by more than the allowable clock skew, then the 515 KDC returns an error message of type KRB_AP_ERR_SKEW. 517 Assuming no errors, the KDC replies as per RFC 1510, except as 518 follows. The user's name in the ticket is determined by the 519 following decision algorithm: 521 1. If the KDC has a mapping from the name in the certificate 522 to a Kerberos name, then use that name. 523 Else 524 2. If the certificate contains a Kerberos name in an extension 525 field, and local KDC policy allows, then use that name. 526 Else 527 3. Use the name as represented in the certificate, mapping 528 as necessary (e.g., as per RFC 2253 for X.500 names). In 529 this case the realm in the ticket shall be the name of the 530 certification authority that issued the user's certificate. 532 The KDC encrypts the reply not with the user's long-term key, but 533 with a random key generated only for this particular response. This 534 random key is sealed in the preauthentication field: 536 PA-PK-AS-REP ::= CHOICE { 537 -- PA TYPE 15 538 dhSignedData [0] SignedData, 539 -- Defined in CMS and used only with 540 -- Diffie-Helman key exchange 541 -- This choice MUST be supported 542 -- by compliant implementations. 543 encKeyPack [1] EnvelopedData, 544 -- Defined in CMS 545 -- The temporary key is encrypted 546 -- using the client public key 547 -- key 548 -- SignedReplyKeyPack, encrypted 549 -- with the temporary key, is also 550 -- included. 551 } 553 Usage of SignedData: 554 If the Diffie-Hellman option is used, dhSignedData in PA-PK-AS-REP 555 provides authenticated Diffie-Hellman parameters of the KDC. The 556 reply key used to encrypt part of the KDC reply message is derived 557 from the Diffie-Hellman exchange: 558 - Both the KDC and the client calculate a secret value (g^ab mod p), 559 where a is the client's private exponent and b is the KDC's 560 private exponent. 561 - Both the KDC and the client take the first N bits of this secret 562 value and convert it into a reply key. N depends on the reply key 563 type. 564 - If the reply key is DES, N=64 bits, where some of the bits are 565 replaced with parity bits, according to FIPS PUB 74. 566 - If the reply key is (3-key) 3-DES, N=192 bits, where some of the 567 bits are replaced with parity bits, according to FIPS PUB 74. 568 - The encapContentInfo field must contain the KdcDHKeyInfo as 569 defined below. 570 - The eContentType field shall contain the OID value for 571 id-data: iso(1) member-body(2) us(840) rsadsi(113549) 572 pkcs(1) pkcs7(7) data(1) 573 - The certificates field must contain the certificates necessary 574 for the client to establish trust in the KDC's certificate 575 based on the list of trusted certifiers sent by the client in 576 the PA-PK-AS-REQ. This field may be empty if the client did 577 not send to the KDC a list of trusted certifiers (the 578 trustedCertifiers field was empty, meaning that the client 579 already possesses the KDC's certificate). 580 - The signerInfos field is a SET that must contain at least one 581 member, since it contains the actual signature. 583 Usage of EnvelopedData: 584 The EnvelopedData data type is specified in the Cryptographic 585 Message Syntax, a product of the S/MIME working group of the IETF. 586 It contains an temporary key encrypted with the PKINIT 587 client's public key. It also contains a signed and encrypted 588 reply key. 589 - The originatorInfo field is not required, since that information 590 may be presented in the signedData structure that is encrypted 591 within the encryptedContentInfo field. 592 - The optional unprotectedAttrs field is not required for PKINIT. 593 - The recipientInfos field is a SET which must contain exactly one 594 member of the KeyTransRecipientInfo type for encryption 595 with an RSA public key. 596 - The encryptedKey field (in KeyTransRecipientInfo) contains 597 the temporary key which is encrypted with the PKINIT client's 598 public key. 599 - The encryptedContentInfo field contains the signed and encrypted 600 reply key. 601 - The contentType field shall contain the OID value for 602 id-signedData: iso(1) member-body(2) us(840) rsadsi(113549) 603 pkcs(1) pkcs7(7) signedData(2) 604 - The encryptedContent field is encrypted data of the CMS type 605 signedData as specified below. 606 - The encapContentInfo field must contains the ReplyKeyPack. 607 - The eContentType field shall contain the OID value for 608 id-data: iso(1) member-body(2) us(840) rsadsi(113549) 609 pkcs(1) pkcs7(7) data(1) 610 - The eContent field is data of the type ReplyKeyPack (below). 611 - The certificates field must contain the certificates necessary 612 for the client to establish trust in the KDC's certificate 613 based on the list of trusted certifiers sent by the client in 614 the PA-PK-AS-REQ. This field may be empty if the client did 615 not send to the KDC a list of trusted certifiers (the 616 trustedCertifiers field was empty, meaning that the client 617 already possesses the KDC's certificate). 618 - The signerInfos field is a SET that must contain at least one 619 member, since it contains the actual signature. 621 KdcDHKeyInfo ::= SEQUENCE { 622 -- used only when utilizing Diffie-Hellman 623 nonce [0] INTEGER, 624 -- binds responce to the request 625 subjectPublicKey [2] BIT STRING 626 -- Equals public exponent (g^a mod p) 627 -- INTEGER encoded as payload of 628 -- BIT STRING 629 } 631 ReplyKeyPack ::= SEQUENCE { 632 -- not used for Diffie-Hellman 633 replyKey [0] EncryptionKey, 634 -- used to encrypt main reply 635 -- ENCTYPE is at least as strong as 636 -- ENCTYPE of session key 637 nonce [1] INTEGER, 638 -- binds response to the request 639 -- must be same as the nonce 640 -- passed in the PKAuthenticator 641 } 643 Since each certifier in the certification path of a user's 644 certificate is essentially a separate realm, the name of each 645 certifier must be added to the transited field of the ticket. The 646 format of these realm names is defined in Section 3.1 of this 647 document. If applicable, the transit-policy-checked flag should be 648 set in the issued ticket. 650 The KDC's certificate must bind the public key to a name derivable 651 from the name of the realm for that KDC. X.509 certificates shall 652 contain the principal name of the KDC as the SubjectAltName version 653 3 extension. Below is the definition of this version 3 extension, as 654 specified by the X.509 standard: 656 subjectAltName EXTENSION ::= { 657 SYNTAX GeneralNames 658 IDENTIFIED BY id-ce-subjectAltName 659 } 661 GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName 663 GeneralName ::= CHOICE { 664 otherName [0] INSTANCE OF OTHER-NAME, 665 ... 666 } 668 OTHER-NAME ::= TYPE-IDENTIFIER 670 In this definition, otherName is a name of any form defined as an 671 instance of the OTHER-NAME information object class. For the purpose 672 of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will 673 be chosen and replaced by the type KerberosName: 675 KerberosName ::= SEQUENCE { 676 realm [0] Realm, 677 -- as define in RFC 1510 678 principalName [1] PrincipalName, 679 -- as define in RFC 1510 680 } 682 This specific syntax is identified within subjectAltName by setting 683 the OID id-ce-subjectAltName to krb5PrincipalName, where (from the 684 Kerberos specification) we have 686 krb5 OBJECT IDENTIFIER ::= { iso (1) 687 org (3) 688 dod (6) 689 internet (1) 690 security (5) 691 kerberosv5 (2) } 693 krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 } 695 This specification may also be used to specify a Kerberos name 696 within the user's certificate. 698 If a non-KDC X.509 certificate contains the principal name within 699 the subjectAltName version 3 extension , that name may utilize 700 KerberosName as defined below, or, in the case of an S/MIME 701 certificate [17], may utilize the email address. If the KDC 702 is presented with as S/MIME certificate, then the email address 703 within subjectAltName will be interpreted as a principal and realm 704 separated by the "@" sign, or as a name that needs to be 705 canonicalized. If the resulting name does not correspond to a 706 registered principal name, then the principal name is formed as 707 defined in section 3.1. 709 The client then extracts the random key used to encrypt the main 710 reply. This random key (in encPaReply) is encrypted with either the 711 client's public key or with a key derived from the DH values 712 exchanged between the client and the KDC. 714 3.2.2. Required Algorithms 716 Not all of the algorithms in the PKINIT protocol specification have 717 to be implemented in order to comply with the proposed standard. 718 Below is a list of the required algorithms: 720 - Diffie-Hellman public/private key pairs 721 - utilizing Diffie-Hellman ephemeral-ephemeral mode 722 - SHA1 digest and DSA for signatures 723 - 3-key triple DES keys derived from the Diffie-Hellman Exchange 724 - 3-key triple DES Temporary and Reply keys 726 4. Logistics and Policy 728 This section describes a way to define the policy on the use of 729 PKINIT for each principal and request. 731 The KDC is not required to contain a database record for users 732 who use public key authentication. However, if these users are 733 registered with the KDC, it is recommended that the database record 734 for these users be modified to an additional flag in the attributes 735 field to indicate that the user should authenticate using PKINIT. 736 If this flag is set and a request message does not contain the 737 PKINIT preauthentication field, then the KDC sends back as error of 738 type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication 739 field of type PA-PK-AS-REQ must be included in the request. 741 5. Security Considerations 743 PKINIT raises a few security considerations, which we will address 744 in this section. 746 First of all, PKINIT introduces a new trust model, where KDCs do not 747 (necessarily) certify the identity of those for whom they issue 748 tickets. PKINIT does allow KDCs to act as their own CAs, in order 749 to simplify key management, but one of the additional benefits is to 750 align Kerberos authentication with a global public key 751 infrastructure. Anyone using PKINIT in this way must be aware of 752 how the certification infrastructure they are linking to works. 754 Secondly, PKINIT also introduces the possibility of interactions 755 between different cryptosystems, which may be of widely varying 756 strengths. Many systems, for instance, allow the use of 512-bit 757 public keys. Using such keys to wrap data encrypted under strong 758 conventional cryptosystems, such as triple-DES, is inappropriate; 759 it adds a weak link to a strong one at extra cost. Implementors 760 and administrators should take care to avoid such wasteful and 761 deceptive interactions. 763 Lastly, PKINIT calls for randomly generated keys for conventional 764 cryptosystems. Many such systems contain systematically "weak" 765 keys. PKINIT implementations MUST avoid use of these keys, either 766 by discarding those keys when they are generated, or by fixing them 767 in some way (e.g., by XORing them with a given mask). These 768 precautions vary from system to system; it is not our intention to 769 give an explicit recipe for them here. 771 6. Transport Issues 773 Certificate chains can potentially grow quite large and span several 774 UDP packets; this in turn increases the probability that a Kerberos 775 message involving PKINIT extensions will be broken in transit. In 776 light of the possibility that the Kerberos specification will 777 require KDCs to accept requests using TCP as a transport mechanism, 778 we make the same recommendation with respect to the PKINIT 779 extensions as well. 781 7. Bibliography 783 [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service 784 (V5). Request for Comments 1510. 786 [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service 787 for Computer Networks, IEEE Communications, 32(9):33-38. September 788 1994. 790 [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld, 791 A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm 792 Authentication in Kerberos. 793 draft-ietf-cat-kerberos-pk-cross-04.txt 795 [4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in 796 Kerberos. 797 draft-ietf-cat-kerberos-anoncred-00.txt 799 [5] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing 800 Tickets for Application Servers (PKTAPP). 801 draft-ietf-cat-pktapp-00.txt 803 [6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos 804 Using Public Key Cryptography. Symposium On Network and Distributed 805 System Security, 1997. 807 [7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction 808 Protocol. In Proceedings of the USENIX Workshop on Electronic 809 Commerce, July 1995. 811 [8] T. Dierks, C. Allen. The TLS Protocol, Version 1.0 812 Request for Comments 2246, January 1999. 814 [9] B.C. Neuman, Proxy-Based Authorization and Accounting for 815 Distributed Systems. In Proceedings of the 13th International 816 Conference on Distributed Computing Systems, May 1993. 818 [10] ITU-T (formerly CCITT) Information technology - Open Systems 819 Interconnection - The Directory: Authentication Framework 820 Recommendation X.509 ISO/IEC 9594-8 822 [11] R. Housley. Cryptographic Message Syntax. 823 draft-ietf-smime-cms-13.txt, April 1999. 825 [12] PKCS #7: Cryptographic Message Syntax Standard, 826 An RSA Laboratories Technical Note Version 1.5 827 Revised November 1, 1993 829 [13] R. Rivest, MIT Laboratory for Computer Science and RSA Data 830 Security, Inc. A Description of the RC2(r) Encryption Algorithm 831 March 1998. 832 Request for Comments 2268. 834 [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access 835 Protocol (v3): UTF-8 String Representation of Distinguished Names. 836 Request for Comments 2253. 838 [15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public 839 Key Infrastructure, Certificate and CRL Profile, January 1999. 840 Request for Comments 2459. 842 [16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography 843 Specifications, October 1998. 844 Request for Comments 2437. 846 [17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. 847 S/MIME Version 2 Certificate Handling, March 1998. 848 Request for Comments 2312 850 8. Acknowledgements 852 Some of the ideas on which this proposal is based arose during 853 discussions over several years between members of the SAAG, the IETF 854 CAT working group, and the PSRG, regarding integration of Kerberos 855 and SPX. Some ideas have also been drawn from the DASS system. 856 These changes are by no means endorsed by these groups. This is an 857 attempt to revive some of the goals of those groups, and this 858 proposal approaches those goals primarily from the Kerberos 859 perspective. Lastly, comments from groups working on similar ideas 860 in DCE have been invaluable. 862 9. Expiration Date 864 This draft expires December 1, 1999. 866 10. Authors 868 Brian Tung 869 Clifford Neuman 870 USC Information Sciences Institute 871 4676 Admiralty Way Suite 1001 872 Marina del Rey CA 90292-6695 873 Phone: +1 310 822 1511 874 E-mail: {brian, bcn}@isi.edu 876 Matthew Hur 877 CyberSafe Corporation 878 1605 NW Sammamish Road 879 Issaquah WA 98027-5378 880 Phone: +1 425 391 6000 881 E-mail: matt.hur@cybersafe.com 883 Ari Medvinsky 884 Excite 885 555 Broadway 886 Redwood City, CA 94063 887 Phone +1 650 569 2119 888 E-mail: amedvins@excitecorp.com 890 Sasha Medvinsky 891 General Instrument 892 6450 Sequence Drive 893 San Diego, CA 92121 894 Phone +1 619 404 2825 895 E-mail: smedvinsky@gi.com 897 John Wray 898 Iris Associates, Inc. 899 5 Technology Park Dr. 900 Westford, MA 01886 901 E-mail: John_Wray@iris.com 903 Jonathan Trostle 904 170 W. Tasman Dr. 905 San Jose, CA 95134 906 E-mail: jtrostle@cisco.com