idnits 2.17.00 (12 Aug 2021) /tmp/idnits14878/draft-ietf-cat-kerberos-pk-init-15.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: ---------------------------------------------------------------------------- ** 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 1117 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 27 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 3 instances of lines with control characters in the document. ** 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 219: '... principal name MUST be set to KRB_NT...' RFC 2119 keyword, line 224: '... the name-string MUST be set as follow...' RFC 2119 keyword, line 229: '... realm MUST be set to the certifica...' RFC 2119 keyword, line 257: '...ees), the following MUST be satisfied....' RFC 2119 keyword, line 261: '..., the realm name MUST be valid (see 2....' (34 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 RFC1510bis, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 992 looks like a reference -- Missing reference section? '2' on line 995 looks like a reference -- Missing reference section? '6' on line 1010 looks like a reference -- Missing reference section? '7' on line 1014 looks like a reference -- Missing reference section? '5' on line 1007 looks like a reference -- Missing reference section? '11' on line 1031 looks like a reference -- Missing reference section? '15' on line 1046 looks like a reference -- Missing reference section? '0' on line 879 looks like a reference -- Missing reference section? '12' on line 1035 looks like a reference -- Missing reference section? '8' on line 1018 looks like a reference -- Missing reference section? '13' on line 1039 looks like a reference -- Missing reference section? '3' on line 999 looks like a reference -- Missing reference section? '17' on line 1053 looks like a reference -- Missing reference section? '14' on line 1042 looks like a reference -- Missing reference section? '4' on line 1003 looks like a reference -- Missing reference section? '9' on line 1022 looks like a reference -- Missing reference section? '10' on line 1026 looks like a reference -- Missing reference section? '16' on line 1049 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 20 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-15.txt Clifford Neuman 3 Updates: RFC 1510bis USC/ISI 4 expires May 25, 2002 Matthew Hur 5 Cisco 6 Ari Medvinsky 7 Keen.com, Inc. 8 Sasha Medvinsky 9 Motorola 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-15.txt, and expires May 25, 2002. 45 Please send comments to the authors. 47 1. Abstract 49 This document defines extensions (PKINIT) to the Kerberos protocol 50 specification (RFC 1510bis [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 ephemeral-ephemeral Diffie-Hellman keys in 72 combination with DSA keys as the primary, required mechanism. Note 73 that PKINIT supports the use of separate signature and encryption 74 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 an AS-REQ message to the KDC as before, except that if that 81 user 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 Note that PKINIT does not require the use of certificates. A KDC 91 may store the public key of a principal as part of that principal's 92 record. In this scenario, the KDC is the trusted party that vouches 93 for the principal (as in a standard, non-cross realm, Kerberos 94 environment). Thus, for any principal, the KDC may maintain a 95 symmetric key, a public key, or both. 97 The PKINIT specification may also be used as a building block for 98 other specifications. PKINIT may be utilized to establish 99 inter-realm keys for the purposes of issuing cross-realm service 100 tickets. It may also be used to issue anonymous Kerberos tickets 101 using the Diffie-Hellman option. Efforts are under way to draft 102 specifications for these two application protocols. 104 Additionally, the PKINIT specification may be used for direct peer 105 to peer authentication without contacting a central KDC. This 106 application of PKINIT is based on concepts introduced in [6, 7]. 107 For direct client-to-server authentication, the client uses PKINIT 108 to authenticate to the end server (instead of a central KDC), which 109 then issues a ticket for itself. This approach has an advantage 110 over TLS [5] in that the server does not need to save state (cache 111 session keys). Furthermore, an additional benefit is that Kerberos 112 tickets can facilitate delegation (see [6]). 114 3. Proposed Extensions 116 This section describes extensions to RFC 1510bis for supporting the 117 use of public key cryptography in the initial request for a ticket 118 granting ticket (TGT). 120 In summary, the following change to RFC 1510bis is proposed: 122 * Users may authenticate using either a public key pair or a 123 conventional (symmetric) key. If public key cryptography is 124 used, public key data is transported in preauthentication 125 data fields to help establish identity. The user presents 126 a public key certificate and obtains an ordinary TGT that may 127 be used for subsequent authentication, with such 128 authentication using only conventional cryptography. 130 Section 3.1 provides definitions to help specify message formats. 131 Section 3.2 describes the extensions for the initial authentication 132 method. 134 3.1. Definitions 136 The extensions involve new preauthentication fields; we introduce 137 the following preauthentication types: 139 PA-PK-AS-REQ 14 140 PA-PK-AS-REP 15 142 The extensions also involve new error types; we introduce the 143 following types: 145 KDC_ERR_CLIENT_NOT_TRUSTED 62 146 KDC_ERR_KDC_NOT_TRUSTED 63 147 KDC_ERR_INVALID_SIG 64 148 KDC_ERR_KEY_TOO_WEAK 65 149 KDC_ERR_CERTIFICATE_MISMATCH 66 150 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 151 KDC_ERR_INVALID_CERTIFICATE 71 152 KDC_ERR_REVOKED_CERTIFICATE 72 153 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 154 KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 155 KDC_ERR_CLIENT_NAME_MISMATCH 75 156 KDC_ERR_KDC_NAME_MISMATCH 76 158 We utilize the following typed data for errors: 160 TD-PKINIT-CMS-CERTIFICATES 101 161 TD-KRB-PRINCIPAL 102 162 TD-KRB-REALM 103 163 TD-TRUSTED-CERTIFIERS 104 164 TD-CERTIFICATE-INDEX 105 166 We utilize the following encryption types (which map directly to 167 OIDs): 169 dsaWithSHA1-CmsOID 9 170 md5WithRSAEncryption-CmsOID 10 171 sha1WithRSAEncryption-CmsOID 11 172 rc2CBC-EnvOID 12 173 rsaEncryption-EnvOID (PKCS#1 v1.5) 13 174 rsaES-OAEP-ENV-OID (PKCS#1 v2.0) 14 175 des-ede3-cbc-Env-OID 15 177 These mappings are provided so that a client may send the 178 appropriate enctypes in the AS-REQ message in order to indicate 179 support for the corresponding OIDs (for performing PKINIT). The 180 above encryption types are utilized only within CMS structures 181 within the PKINIT preauthentication fields. Their use within 182 the Kerberos EncryptedData structure is unspecified. 184 In many cases, PKINIT requires the encoding of the X.500 name of a 185 certificate authority as a Realm. When such a name appears as 186 a realm it will be represented using the "Other" form of the realm 187 name as specified in the naming constraints section of RFC 1510bis. 188 For a realm derived from an X.500 name, NAMETYPE will have the value 189 X500-RFC2253. The full realm name will appear as follows: 191 + ":" + 193 where nametype is "X500-RFC2253" and string is the result of doing 194 an RFC2253 encoding of the distinguished name, i.e. 196 "X500-RFC2253:" + RFC2253Encode(DistinguishedName) 198 where DistinguishedName is an X.500 name, and RFC2253Encode is a 199 function returing a readable UTF encoding of an X.500 name, as 200 defined by RFC 2253 [11] (part of LDAPv3 [15]). 202 Each component of a DistinguishedName is called a 203 RelativeDistinguishedName, where a RelativeDistinguishedName is a 204 SET OF AttributeTypeAndValue. RFC 2253 does not specify the order 205 in which to encode the elements of the RelativeDistinguishedName and 206 so to ensure that this encoding is unique, we add the following rule 207 to those specified by RFC 2253: 209 When converting a multi-valued RelativeDistinguishedName 210 to a string, the output consists of the string encodings 211 of each AttributeTypeAndValue, in the same order as 212 specified by the DER encoding. 214 Similarly, in cases where the KDC does not provide a specific 215 policy-based mapping from the X.500 name or X.509 Version 3 216 SubjectAltName extension in the user's certificate to a Kerberos 217 principal name, PKINIT requires the direct encoding of the X.500 218 name as a PrincipalName. In this case, the name-type of the 219 principal name MUST be set to KRB_NT-X500-PRINCIPAL. This new 220 name type is defined in RFC 1510bis as: 222 KRB_NT_X500_PRINCIPAL 6 224 For this type, the name-string MUST be set as follows: 226 RFC2253Encode(DistinguishedName) 228 as described above. When this name type is used, the principal's 229 realm MUST be set to the certificate authority's distinguished 230 name using the X500-RFC2253 realm name format described earlier in 231 this section. 233 Note that the same string may be represented using several different 234 ASN.1 data types. As the result, the reverse conversion from an 235 RFC2253-encoded principal name back to an X.500 name may not be 236 unique and may result in an X.500 name that is not the same as the 237 original X.500 name found in the client certificate. 239 RFC 1510bis describes an alternate encoding of an X.500 name into a 240 realm name. However, as described in RFC 1510bis, the alternate 241 encoding does not guarantee a unique mapping from a 242 DistinguishedName inside a certificate into a realm name and 243 similarly cannot be used to produce a unique principal name. PKINIT 244 therefore uses an RFC 2253-based name mapping approach, as specified 245 above. 247 RFC 1510bis specifies the ASN.1 structure for PrincipalName as follows: 249 PrincipalName ::= SEQUENCE { 250 name-type[0] INTEGER, 251 name-string[1] SEQUENCE OF GeneralString 252 } 254 The following rules relate to the the matching of PrincipalNames 255 with regard to the PKI name constraints for CAs as laid out in RFC 256 2459 [12]. In order to be regarded as a match (for permitted and 257 excluded name trees), the following MUST be satisfied. 259 1. If the constraint is given as a user plus realm name, or 260 as a client principal name plus realm name (as specified in 261 RFC 1510bis), the realm name MUST be valid (see 2.a-d below) 262 and the match MUST be exact, byte for byte. 264 2. If the constraint is given only as a realm name, matching 265 depends on the type of the realm: 267 a. If the realm contains a colon (':') before any equal 268 sign ('='), it is treated as a realm of type Other, 269 and MUST match exactly, byte for byte. 271 b. Otherwise, if the realm name conforms to rules regarding 272 the format of DNS names, it is considered a realm name of 273 type Domain. The constraint may be given as a realm 274 name 'FOO.BAR', which matches any PrincipalName within 275 the realm 'FOO.BAR' but not those in subrealms such as 276 'CAR.FOO.BAR'. A constraint of the form '.FOO.BAR' 277 matches PrincipalNames in subrealms of the form 278 'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself. 280 c. Otherwise, the realm name is invalid and does not match 281 under any conditions. 283 3.1.1. Encryption and Key Formats 285 In the exposition below, we use the terms public key and private 286 key generically. It should be understood that the term "public 287 key" may be used to refer to either a public encryption key or a 288 signature verification key, and that the term "private key" may be 289 used to refer to either a private decryption key or a signature 290 generation key. The fact that these are logically distinct does 291 not preclude the assignment of bitwise identical keys for RSA 292 keys. 294 In the case of Diffie-Hellman, the key is produced from the agreed 295 bit string as follows: 297 * Truncate the bit string to the required length. 298 * Apply the specific cryptosystem's random-to-key function. 300 Appropriate key constraints for each valid cryptosystem are given 301 in RFC 1510bis. 303 3.1.2. Algorithm Identifiers 305 PKINIT does not define, but does permit, the algorithm identifiers 306 listed below. 308 3.1.2.1. Signature Algorithm Identifiers 310 The following signature algorithm identifiers specified in [8] and 311 in [12] are used with PKINIT: 313 id-dsa-with-sha1 (DSA with SHA1) 314 md5WithRSAEncryption (RSA with MD5) 315 sha-1WithRSAEncryption (RSA with SHA1) 317 3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier 319 The following algorithm identifier shall be used within the 320 SubjectPublicKeyInfo data structure: dhpublicnumber 322 This identifier and the associated algorithm parameters are 323 specified in RFC 2459 [12]. 325 3.1.2.3. Algorithm Identifiers for RSA Encryption 327 These algorithm identifiers are used inside the EnvelopedData data 328 structure, for encrypting the temporary key with a public key: 330 rsaEncryption (RSA encryption, PKCS#1 v1.5) 331 id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0) 333 Both of the above RSA encryption schemes are specified in [13]. 334 Currently, only PKCS#1 v1.5 is specified by CMS [8], although the 335 CMS specification says that it will likely include PKCS#1 v2.0 in 336 the future. (PKCS#1 v2.0 addresses adaptive chosen ciphertext 337 vulnerability discovered in PKCS#1 v1.5.) 339 3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys 341 These algorithm identifiers are used inside the EnvelopedData data 342 structure in the PKINIT Reply, for encrypting the reply key with the 343 temporary key: 344 des-ede3-cbc (3-key 3-DES, CBC mode) 345 rc2-cbc (RC2, CBC mode) 347 The full definition of the above algorithm identifiers and their 348 corresponding parameters (an IV for block chaining) is provided in 349 the CMS specification [8]. 351 3.2. Public Key Authentication 353 Implementation of the changes in this section is REQUIRED for 354 compliance with PKINIT. 356 3.2.1. Client Request 358 Public keys may be signed by some certification authority (CA), or 359 they may be maintained by the KDC in which case the KDC is the 360 trusted authority. Note that the latter mode does not require the 361 use of certificates. 363 The initial authentication request is sent as per RFC 1510bis, except 364 that a preauthentication field containing data signed by the user's 365 private key accompanies the request: 367 PA-PK-AS-REQ ::= SEQUENCE { 368 -- PA TYPE 14 369 signedAuthPack [0] ContentInfo, 370 -- Defined in CMS [8]; 371 -- SignedData OID is {pkcs7 2} 372 -- AuthPack (below) defines the 373 -- data that is signed. 374 trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL, 375 -- This is a list of CAs that the 376 -- client trusts and that certify 377 -- KDCs. 378 kdcCert [2] IssuerAndSerialNumber OPTIONAL 379 -- As defined in CMS [8]; 380 -- specifies a particular KDC 381 -- certificate if the client 382 -- already has it. 383 encryptionCert [3] IssuerAndSerialNumber OPTIONAL 384 -- For example, this may be the 385 -- client's Diffie-Hellman 386 -- certificate, or it may be the 387 -- client's RSA encryption 388 -- certificate. 389 } 391 TrustedCas ::= CHOICE { 392 principalName [0] KerberosName, 393 -- as defined below 394 caName [1] Name 395 -- fully qualified X.500 name 396 -- as defined by X.509 397 issuerAndSerial [2] IssuerAndSerialNumber 398 -- Since a CA may have a number of 399 -- certificates, only one of which 400 -- a client trusts 401 } 403 The type of the ContentInfo in the signedAuthPack is SignedData. 404 Its usage is as follows: 406 The SignedData data type is specified in the Cryptographic 407 Message Syntax, a product of the S/MIME working group of the 408 IETF. The following describes how to fill in the fields of 409 this data: 411 1. The encapContentInfo field MUST contain the PKAuthenticator 412 and, optionally, the client's Diffie Hellman public value. 414 a. The eContentType field MUST contain the OID value for 415 pkauthdata: iso (1) org (3) dod (6) internet (1) 416 security (5) kerberosv5 (2) pkinit (3) pkauthdata (1) 418 b. The eContent field is data of the type AuthPack (below). 420 2. The signerInfos field contains the signature of AuthPack. 422 3. The Certificates field, when non-empty, contains the client's 423 certificate chain. If present, the KDC uses the public key 424 from the client's certificate to verify the signature in the 425 request. Note that the client may pass different certificate 426 chains that are used for signing or for encrypting. Thus, 427 the KDC may utilize a different client certificate for 428 signature verification than the one it uses to encrypt the 429 reply to the client. For example, the client may place a 430 Diffie-Hellman certificate in this field in order to convey 431 its static Diffie Hellman certificate to the KDC to enable 432 static-ephemeral Diffie-Hellman mode for the reply; in this 433 case, the client does NOT place its public value in the 434 AuthPack (defined below). As another example, the client may 435 place an RSA encryption certificate in this field. However, 436 there MUST always be (at least) a signature certificate. 438 4. When a DH key is being used, the public exponent is provided 439 in the subjectPublicKey field of the SubjectPublicKeyInfo and 440 the DH parameters are supplied as a DHParameter in the 441 AlgorithmIdentitfier parameters. The DH paramters SHOULD be 442 chosen from the First and Second defined Oakley Groups [The 443 Internet Key Exchange (IKE) RFC-2409], if a server will not 444 accept either of these groups, it will respond with a krb-error 445 of KDC_ERR_KEY_TOO_WEAK and the e_data will contain a 446 DHParameter with appropriate parameters for the client to use. 448 5. The KDC may wish to use cached Diffie-Hellman parameters 449 (see Section 3.2.2, KDC Response). To indicate acceptance 450 of cached parameters, the client sends zero in the nonce 451 field of the PKAuthenticator. Zero is not a valid value 452 for this field under any other circumstances. If cached 453 parameters are used, the client and the KDC MUST perform 454 key derivation (for the appropriate cryptosystem) on the 455 resulting encryption key, as specified in RFC 1510bis. (With 456 a zero nonce, message binding is performed using the nonce 457 in the main request, which must be encrypted using the 458 encapsulated reply key.) 460 AuthPack ::= SEQUENCE { 461 pkAuthenticator [0] PKAuthenticator, 462 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL 463 -- if client is using Diffie-Hellman 464 -- (ephemeral-ephemeral only) 465 } 467 PKAuthenticator ::= SEQUENCE { 468 cusec [0] INTEGER, 469 -- for replay prevention as in RFC 1510bis 470 ctime [1] KerberosTime, 471 -- for replay prevention as in RFC 1510bis 472 nonce [2] INTEGER, 473 -- zero only if client will accept 474 -- cached DH parameters from KDC; 475 -- must be non-zero otherwise 476 pachecksum [3] Checksum 477 -- Checksum over KDC-REQ-BODY 478 -- Defined by Kerberos spec; 479 -- must be unkeyed, e.g. sha1 or rsa-md5 480 } 482 SubjectPublicKeyInfo ::= SEQUENCE { 483 algorithm AlgorithmIdentifier, 484 -- dhKeyAgreement 485 subjectPublicKey BIT STRING 486 -- for DH, equals 487 -- public exponent (INTEGER encoded 488 -- as payload of BIT STRING) 489 } -- as specified by the X.509 recommendation [7] 491 AlgorithmIdentifier ::= SEQUENCE { 492 algorithm OBJECT IDENTIFIER, 493 -- for dhKeyAgreement, this is 494 -- { iso (1) member-body (2) US (840) 495 -- rsadsi (113459) pkcs (1) 3 1 } 496 -- from PKCS #3 [17] 497 parameters ANY DEFINED by algorithm OPTIONAL 498 -- for dhKeyAgreement, this is 499 -- DHParameter 500 } -- as specified by the X.509 recommendation [7] 502 DHParameter ::= SEQUENCE { 503 prime INTEGER, 504 -- p 505 base INTEGER, 506 -- g 507 privateValueLength INTEGER OPTIONAL 508 -- l 509 } -- as defined in PKCS #3 [17] 511 If the client passes an issuer and serial number in the request, 512 the KDC is requested to use the referred-to certificate. If none 513 exists, then the KDC returns an error of type 514 KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the 515 other hand, the client does not pass any trustedCertifiers, 516 believing that it has the KDC's certificate, but the KDC has more 517 than one certificate. The KDC should include information in the 518 KRB-ERROR message that indicates the KDC certificate(s) that a 519 client may utilize. This data is specified in the e-data, which 520 is defined in RFC 1510bis revisions as a SEQUENCE of TypedData: 522 TypedData ::= SEQUENCE { 523 data-type [0] INTEGER, 524 data-value [1] OCTET STRING, 525 } -- per Kerberos RFC 1510bis 527 where: 528 data-type = TD-PKINIT-CMS-CERTIFICATES = 101 529 data-value = CertificateSet // as specified by CMS [8] 531 The PKAuthenticator carries information to foil replay attacks, to 532 bind the pre-authentication data to the KDC-REQ-BODY, and to bind the 533 request and response. The PKAuthenticator is signed with the client's 534 signature key. 536 3.2.2. KDC Response 538 Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication 539 type, the KDC attempts to verify the user's certificate chain 540 (userCert), if one is provided in the request. This is done by 541 verifying the certification path against the KDC's policy of 542 legitimate certifiers. 544 If the client's certificate chain contains no certificate signed by 545 a CA trusted by the KDC, then the KDC sends back an error message 546 of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data 547 is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104) 548 whose data-value is an OCTET STRING which is the DER encoding of 550 TrustedCertifiers ::= SEQUENCE OF PrincipalName 551 -- X.500 name encoded as a principal name 552 -- see Section 3.1 554 If while verifying a certificate chain the KDC determines that the 555 signature on one of the certificates in the CertificateSet from 556 the signedAuthPack fails verification, then the KDC returns an 557 error of type KDC_ERR_INVALID_CERTIFICATE. The accompanying 558 e-data is a SEQUENCE of one TypedData (with type 559 TD-CERTIFICATE-INDEX=105) whose data-value is an OCTET STRING 560 which is the DER encoding of the index into the CertificateSet 561 ordered as sent by the client. 563 CertificateIndex ::= INTEGER 564 -- 0 = 1st certificate, 565 -- (in order of encoding) 566 -- 1 = 2nd certificate, etc 568 The KDC may also check whether any of the certificates in the 569 client's chain has been revoked. If one of the certificates has 570 been revoked, then the KDC returns an error of type 571 KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that 572 the certificate's revocation status is unknown or not 573 available, then if required by policy, the KDC returns the 574 appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or 575 KDC_ERR_REVOCATION_STATUS_UNAVAILABLE. In any of these three 576 cases, the affected certificate is identified by the accompanying 577 e-data, which contains a CertificateIndex as described for 578 KDC_ERR_INVALID_CERTIFICATE. 580 If the certificate chain can be verified, but the name of the 581 client in the certificate does not match the client's name in the 582 request, then the KDC returns an error of type 583 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data 584 field in this case. 586 Even if all succeeds, the KDC may--for policy reasons--decide not 587 to trust the client. In this case, the KDC returns an error message 588 of type KDC_ERR_CLIENT_NOT_TRUSTED. One specific case of this is 589 the presence or absence of an Enhanced Key Usage (EKU) OID within 590 the certificate extensions. The rules regarding acceptability of 591 an EKU sequence (or the absence of any sequence) are a matter of 592 local policy. For the benefit of implementers, we define a PKINIT 593 EKU OID as the following: iso (1) org (3) dod (6) internet (1) 594 security (5) kerberosv5 (2) pkinit (3) pkekuoid (2). 596 If a trust relationship exists, the KDC then verifies the client's 597 signature on AuthPack. If that fails, the KDC returns an error 598 message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the 599 timestamp (ctime and cusec) in the PKAuthenticator to assure that 600 the request is not a replay. The KDC also verifies that its name 601 is specified in the PKAuthenticator. 603 If the clientPublicValue field is filled in, indicating that the 604 client wishes to use Diffie-Hellman key agreement, then the KDC 605 checks to see that the parameters satisfy its policy. If they do 606 not (e.g., the prime size is insufficient for the expected 607 encryption type), then the KDC sends back an error message of type 608 KDC_ERR_KEY_TOO_WEAK, with an e-data containing a structure of 609 type DHParameter with appropriate DH parameters for the client to 610 retry the request. Otherwise, it generates its own public and 611 private values for the response. 613 The KDC also checks that the timestamp in the PKAuthenticator is 614 within the allowable window and that the principal name and realm 615 are correct. If the local (server) time and the client time in the 616 authenticator differ by more than the allowable clock skew, then the 617 KDC returns an error message of type KRB_AP_ERR_SKEW as defined in 618 RFC 1510bis. 620 Assuming no errors, the KDC replies as per RFC 1510bis, except as 621 follows. The user's name in the ticket is determined by the 622 following decision algorithm: 624 1. If the KDC has a mapping from the name in the certificate 625 to a Kerberos name, then use that name. 626 Else 627 2. If the certificate contains the SubjectAltName extention 628 and the local KDC policy defines a mapping from the 629 SubjectAltName to a Kerberos name, then use that name. 630 Else 631 3. Use the name as represented in the certificate, mapping 632 as necessary (e.g., as per RFC 2253 for X.500 names). In 633 this case the realm in the ticket MUST be the name of the 634 certifier that issued the user's certificate. 636 Note that a principal name may be carried in the subjectAltName 637 field of a certificate. This name may be mapped to a principal 638 record in a security database based on local policy, for example 639 the subjectAltName may be kerberos/principal@realm format. In 640 this case the realm name is not that of the CA but that of the 641 local realm doing the mapping (or some realm name chosen by that 642 realm). 644 If a non-KDC X.509 certificate contains the principal name within 645 the subjectAltName version 3 extension, that name may utilize 646 KerberosName as defined below, or, in the case of an S/MIME 647 certificate [14], may utilize the email address. If the KDC 648 is presented with an S/MIME certificate, then the email address 649 within subjectAltName will be interpreted as a principal and realm 650 separated by the "@" sign, or as a name that needs to be mapped 651 according to local policy. If the resulting name does not correspond 652 to a registered principal name, then the principal name is formed as 653 defined in section 3.1. 655 The trustedCertifiers field contains a list of certification 656 authorities trusted by the client, in the case that the client does 657 not possess the KDC's public key certificate. If the KDC has no 658 certificate signed by any of the trustedCertifiers, then it returns 659 an error of type KDC_ERR_KDC_NOT_TRUSTED. 661 KDCs should try to (in order of preference): 662 1. Use the KDC certificate identified by the serialNumber included 663 in the client's request. 664 2. Use a certificate issued to the KDC by one of the client's 665 trustedCertifier(s); 666 If the KDC is unable to comply with any of these options, then the 667 KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the 668 client. 670 The KDC encrypts the reply not with the user's long-term key, but 671 with the Diffie Hellman derived key or a random key generated 672 for this particular response which is carried in the padata field of 673 the TGS-REP message. 675 PA-PK-AS-REP ::= CHOICE { 676 -- PA TYPE 15 677 dhSignedData [0] ContentInfo, 678 -- Defined in CMS [8] and used only with 679 -- Diffie-Hellman key exchange (if the 680 -- client public value was present in the 681 -- request). 682 -- SignedData OID is {pkcs7 2} 683 -- This choice MUST be supported 684 -- by compliant implementations. 685 encKeyPack [1] ContentInfo 686 -- Defined in CMS [8]. 687 -- The temporary key is encrypted 688 -- using the client public key 689 -- key. 690 -- EnvelopedData OID is {pkcs7 3} 691 -- SignedReplyKeyPack, encrypted 692 -- with the temporary key, is also 693 -- included. 694 } 696 The type of the ContentInfo in the dhSignedData is SignedData. 697 Its usage is as follows: 699 When the Diffie-Hellman option is used, dhSignedData in 700 PA-PK-AS-REP provides authenticated Diffie-Hellman parameters 701 of the KDC. The reply key used to encrypt part of the KDC reply 702 message is derived from the Diffie-Hellman exchange: 704 1. Both the KDC and the client calculate a secret value 705 (g^ab mod p), where a is the client's private exponent and 706 b is the KDC's private exponent. 708 2. Both the KDC and the client take the first N bits of this 709 secret value and convert it into a reply key. N depends on 710 the reply key type. 712 a. For example, if the reply key is DES, N=64 bits, where 713 some of the bits are replaced with parity bits, according 714 to FIPS PUB 74. 716 b. As another example, if the reply key is (3-key) 3-DES, 717 N=192 bits, where some of the bits are replaced with 718 parity bits, according to FIPS PUB 74. 720 3. The encapContentInfo field MUST contain the KdcDHKeyInfo as 721 defined below. 723 a. The eContentType field MUST contain the OID value for 724 pkdhkeydata: iso (1) org (3) dod (6) internet (1) 725 security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2) 727 b. The eContent field is data of the type KdcDHKeyInfo 728 (below). 730 4. The certificates field MUST contain the certificates 731 necessary for the client to establish trust in the KDC's 732 certificate based on the list of trusted certifiers sent by 733 the client in the PA-PK-AS-REQ. This field may be empty if 734 the client did not send to the KDC a list of trusted 735 certifiers (the trustedCertifiers field was empty, meaning 736 that the client already possesses the KDC's certificate). 738 5. The signerInfos field is a SET that MUST contain at least 739 one member, since it contains the actual signature. 741 6. If the client indicated acceptance of cached Diffie-Hellman 742 parameters from the KDC, and the KDC supports such an option 743 (for performance reasons), the KDC should return a zero in 744 the nonce field and include the expiration time of the 745 parameters in the dhKeyExpiration field. If this time is 746 exceeded, the client SHOULD NOT use the reply. If the time 747 is absent, the client SHOULD NOT use the reply and MAY 748 resubmit a request with a non-zero nonce (thus indicating 749 non-acceptance of cached Diffie-Hellman parameters). As 750 indicated above in Section 3.2.1, Client Request, when the 751 KDC uses cached parameters, the client and the KDC MUST 752 perform key derivation (for the appropriate cryptosystem) 753 on the resulting encryption key, as specified in RFC 1510bis. 755 KdcDHKeyInfo ::= SEQUENCE { 756 -- used only when utilizing Diffie-Hellman 757 subjectPublicKey [0] BIT STRING, 758 -- Equals public exponent (g^a mod p) 759 -- INTEGER encoded as payload of 760 -- BIT STRING 761 nonce [1] INTEGER, 762 -- Binds response to the request 763 -- Exception: Set to zero when KDC 764 -- is using a cached DH value 765 dhKeyExpiration [2] KerberosTime OPTIONAL 766 -- Expiration time for KDC's cached 767 -- DH value 768 } 770 The type of the ContentInfo in the encKeyPack is EnvelopedData. Its 771 usage is as follows: 773 The EnvelopedData data type is specified in the Cryptographic 774 Message Syntax, a product of the S/MIME working group of the 775 IETF. It contains a temporary key encrypted with the PKINIT 776 client's public key. It also contains a signed and encrypted 777 reply key. 779 1. The originatorInfo field is not required, since that 780 information may be presented in the signedData structure 781 that is encrypted within the encryptedContentInfo field. 783 2. The optional unprotectedAttrs field is not required for 784 PKINIT. 786 3. The recipientInfos field is a SET which MUST contain exactly 787 one member of the KeyTransRecipientInfo type for encryption 788 with a public key. 790 a. The encryptedKey field (in KeyTransRecipientInfo) 791 contains the temporary key which is encrypted with the 792 PKINIT client's public key. 794 4. The encryptedContentInfo field contains the signed and 795 encrypted reply key. 797 a. The contentType field MUST contain the OID value for 798 id-signedData: iso (1) member-body (2) us (840) 799 rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) 801 b. The encryptedContent field is encrypted data of the CMS 802 type signedData as specified below. 804 i. The encapContentInfo field MUST contains the 805 ReplyKeyPack. 807 * The eContentType field MUST contain the OID value 808 for pkrkeydata: iso (1) org (3) dod (6) internet (1) 809 security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3) 811 * The eContent field is data of the type ReplyKeyPack 812 (below). 814 ii. The certificates field MUST contain the certificates 815 necessary for the client to establish trust in the 816 KDC's certificate based on the list of trusted 817 certifiers sent by the client in the PA-PK-AS-REQ. 818 This field may be empty if the client did not send 819 to the KDC a list of trusted certifiers (the 820 trustedCertifiers field was empty, meaning that the 821 client already possesses the KDC's certificate). 823 iii. The signerInfos field is a SET that MUST contain at 824 least one member, since it contains the actual 825 signature. 827 ReplyKeyPack ::= SEQUENCE { 828 -- not used for Diffie-Hellman 829 replyKey [0] EncryptionKey, 830 -- from RFC 1510bis 831 -- used to encrypt main reply 832 -- ENCTYPE is at least as strong as 833 -- ENCTYPE of session key 834 nonce [1] INTEGER, 835 -- binds response to the request 836 -- must be same as the nonce 837 -- passed in the PKAuthenticator 838 } 840 3.2.2.1. Use of transited Field 842 Since each certifier in the certification path of a user's 843 certificate is equivalent to a separate Kerberos realm, the name 844 of each certifier in the certificate chain MUST be added to the 845 transited field of the ticket. The format of these realm names is 846 defined in Section 3.1 of this document. If applicable, the 847 transit-policy-checked flag should be set in the issued ticket. 849 3.2.2.2. Kerberos Names in Certificates 851 The KDC's certificate(s) MUST bind the public key(s) of the KDC to 852 a name derivable from the name of the realm for that KDC. X.509 853 certificates MUST contain the principal name of the KDC (defined in 854 RFC 1510bis) as the SubjectAltName version 3 extension. Below is 855 the definition of this version 3 extension, as specified by the 856 X.509 standard: 858 subjectAltName EXTENSION ::= { 859 SYNTAX GeneralNames 860 IDENTIFIED BY id-ce-subjectAltName 861 } 863 GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName 865 GeneralName ::= CHOICE { 866 otherName [0] OtherName, 867 ... 868 } 870 OtherName ::= SEQUENCE { 871 type-id OBJECT IDENTIFIER, 872 value [0] EXPLICIT ANY DEFINED BY type-id 873 } 875 For the purpose of specifying a Kerberos principal name, the value 876 in OtherName MUST be a KerberosName, defined as follows: 878 KerberosName ::= SEQUENCE { 879 realm [0] Realm, 880 principalName [1] PrincipalName 881 } 883 This specific syntax is identified within subjectAltName by setting 884 the type-id in OtherName to krb5PrincipalName, where (from the 885 Kerberos specification) we have 887 krb5 OBJECT IDENTIFIER ::= { iso (1) 888 org (3) 889 dod (6) 890 internet (1) 891 security (5) 892 kerberosv5 (2) } 894 krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 } 896 (This specification may also be used to specify a Kerberos name 897 within the user's certificate.) The KDC's certificate may be signed 898 directly by a CA, or there may be intermediaries if the server resides 899 within a large organization, or it may be unsigned if the client 900 indicates possession (and trust) of the KDC's certificate. 902 Note that the KDC's principal name has the instance equal to the 903 realm, and those fields should be appropriately set in the realm 904 and principalName fields of the KerberosName. This is the case 905 even when obtaining a cross-realm ticket using PKINIT. 907 3.2.3. Client Extraction of Reply 909 The client then extracts the random key used to encrypt the main 910 reply. This random key (in encPaReply) is encrypted with either the 911 client's public key or with a key derived from the DH values 912 exchanged between the client and the KDC. The client uses this 913 random key to decrypt the main reply, and subsequently proceeds as 914 described in RFC 1510bis. 916 3.2.4. Required Algorithms 918 Not all of the algorithms in the PKINIT protocol specification have 919 to be implemented in order to comply with the proposed standard. 920 Below is a list of the required algorithms: 922 * Diffie-Hellman public/private key pairs 923 * utilizing Diffie-Hellman ephemeral-ephemeral mode 924 * SHA1 digest and DSA for signatures 925 * SHA1 digest for the Checksum in the PKAuthenticator 926 * using Kerberos checksum type 'sha1' 927 * 3-key triple DES keys derived from the Diffie-Hellman Exchange 928 * 3-key triple DES Temporary and Reply keys 930 4. Logistics and Policy 932 This section describes a way to define the policy on the use of 933 PKINIT for each principal and request. 935 The KDC is not required to contain a database record for users 936 who use public key authentication. However, if these users are 937 registered with the KDC, it is recommended that the database record 938 for these users be modified to an additional flag in the attributes 939 field to indicate that the user should authenticate using PKINIT. 940 If this flag is set and a request message does not contain the 941 PKINIT preauthentication field, then the KDC sends back as error of 942 type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication 943 field of type PA-PK-AS-REQ must be included in the request. 945 5. Security Considerations 947 PKINIT raises a few security considerations, which we will address 948 in this section. 950 First of all, PKINIT extends the cross-realm model to the public 951 key infrastructure. Anyone using PKINIT must be aware of how the 952 certification infrastructure they are linking to works. 954 Also, as in standard Kerberos, PKINIT presents the possibility of 955 interactions between different cryptosystems of varying strengths, 956 and this now includes public-key cryptosystems. Many systems, for 957 instance, allow the use of 512-bit public keys. Using such keys 958 to wrap data encrypted under strong conventional cryptosystems, 959 such as triple-DES, may be inappropriate. 961 Care should be taken in how certificates are choosen for the purposes 962 of authentication using PKINIT. Some local policies require that key 963 escrow be applied for certain certificate types. People deploying 964 PKINIT should be aware of the implications of using certificates that 965 have escrowed keys for the purposes of authentication. 967 As described in Section 3.2, PKINIT allows for the caching of the 968 Diffie-Hellman parameters on the KDC side, for performance reasons. 969 For similar reasons, the signed data in this case does not vary from 970 message to message, until the cached parameters expire. Because of 971 the persistence of these parameters, the client and the KDC are to 972 use the appropriate key derivation measures (as described in RFC 973 1510bis) when using cached DH parameters. 975 Lastly, PKINIT calls for randomly generated keys for conventional 976 cryptosystems. Many such systems contain systematically "weak" 977 keys. For recommendations regarding these weak keys, see RFC 978 1510bis. 980 6. Transport Issues 982 Certificate chains can potentially grow quite large and span several 983 UDP packets; this in turn increases the probability that a Kerberos 984 message involving PKINIT extensions will be broken in transit. In 985 light of the possibility that the Kerberos specification will 986 require KDCs to accept requests using TCP as a transport mechanism, 987 we make the same recommendation with respect to the PKINIT 988 extensions as well. 990 7. Bibliography 992 [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service 993 (V5). Request for Comments 1510. 995 [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service 996 for Computer Networks, IEEE Communications, 32(9):33-38. September 997 1994. 999 [3] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos 1000 Using Public Key Cryptography. Symposium On Network and Distributed 1001 System Security, 1997. 1003 [4] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction 1004 Protocol. In Proceedings of the USENIX Workshop on Electronic 1005 Commerce, July 1995. 1007 [5] T. Dierks, C. Allen. The TLS Protocol, Version 1.0 1008 Request for Comments 2246, January 1999. 1010 [6] B.C. Neuman, Proxy-Based Authorization and Accounting for 1011 Distributed Systems. In Proceedings of the 13th International 1012 Conference on Distributed Computing Systems, May 1993. 1014 [7] ITU-T (formerly CCITT) Information technology - Open Systems 1015 Interconnection - The Directory: Authentication Framework 1016 Recommendation X.509 ISO/IEC 9594-8 1018 [8] R. Housley. Cryptographic Message Syntax. 1019 draft-ietf-smime-cms-13.txt, April 1999, approved for publication 1020 as RFC. 1022 [9] PKCS #7: Cryptographic Message Syntax Standard, 1023 An RSA Laboratories Technical Note Version 1.5 1024 Revised November 1, 1993 1026 [10] R. Rivest, MIT Laboratory for Computer Science and RSA Data 1027 Security, Inc. A Description of the RC2(r) Encryption Algorithm 1028 March 1998. 1029 Request for Comments 2268. 1031 [11] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access 1032 Protocol (v3): UTF-8 String Representation of Distinguished Names. 1033 Request for Comments 2253. 1035 [12] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public 1036 Key Infrastructure, Certificate and CRL Profile, January 1999. 1037 Request for Comments 2459. 1039 [13] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography 1040 Specifications, October 1998. Request for Comments 2437. 1042 [14] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. S/MIME 1043 Version 2 Certificate Handling, March 1998. Request for 1044 Comments 2312. 1046 [15] M. Wahl, T. Howes, S. Kille. Lightweight Directory Access 1047 Protocol (v3), December 1997. Request for Comments 2251. 1049 [16] ITU-T (formerly CCITT) Information Processing Systems - Open 1050 Systems Interconnection - Specification of Abstract Syntax Notation 1051 One (ASN.1) Rec. X.680 ISO/IEC 8824-1 1053 [17] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA 1054 Laboratories Technical Note, Version 1.4, Revised November 1, 1993. 1056 8. Acknowledgements 1058 Some of the ideas on which this proposal is based arose during 1059 discussions over several years between members of the SAAG, the IETF 1060 CAT working group, and the PSRG, regarding integration of Kerberos 1061 and SPX. Some ideas have also been drawn from the DASS system. 1062 These changes are by no means endorsed by these groups. This is an 1063 attempt to revive some of the goals of those groups, and this 1064 proposal approaches those goals primarily from the Kerberos 1065 perspective. Lastly, comments from groups working on similar ideas 1066 in DCE have been invaluable. 1068 9. Expiration Date 1070 This draft expires May 25, 2002. 1072 10. Authors 1074 Brian Tung 1075 Clifford Neuman 1076 USC Information Sciences Institute 1077 4676 Admiralty Way Suite 1001 1078 Marina del Rey CA 90292-6695 1079 Phone: +1 310 822 1511 1080 E-mail: {brian, bcn}@isi.edu 1082 Matthew Hur 1083 Cisco Systems 1084 2901 Third Avenue 1085 Seattle WA 98121 1086 Phone: (206) 256-3197 1087 E-Mail: mhur@cisco.com 1089 Ari Medvinsky 1090 Keen.com, Inc. 1091 150 Independence Drive 1092 Menlo Park CA 94025 1093 Phone: +1 650 289 3134 1094 E-mail: ari@keen.com 1096 Sasha Medvinsky 1097 Motorola 1098 6450 Sequence Drive 1099 San Diego, CA 92121 1100 +1 858 404 2367 1101 E-mail: smedvinsky@gi.com 1103 John Wray 1104 Iris Associates, Inc. 1105 5 Technology Park Dr. 1106 Westford, MA 01886 1107 E-mail: John_Wray@iris.com 1109 Jonathan Trostle 1110 Cisco Systems 1111 170 W. Tasman Dr. 1112 San Jose, CA 95134 1113 E-mail: jtrostle@cisco.com