1INTERNET-DRAFT Brian Tung 2draft-ietf-cat-kerberos-pk-init-18.txt Clifford Neuman 3Updates: RFC 1510bis USC/ISI 4expires August 20, 2004 Matthew Hur 5 Ari Medvinsky 6 Microsoft Corporation 7 Sasha Medvinsky 8 Motorola, Inc. 9 John Wray 10 Iris Associates, Inc. 11 Jonathan Trostle 12 13 Public Key Cryptography for Initial Authentication in Kerberos 14 150. Status Of This Memo 16 17This document is an Internet-Draft and is in full conformance with 18all provision of Section 10 of RFC 2026. Internet-Drafts are 19working documents of the Internet Engineering Task Force (IETF), its 20areas, and its working groups. Note that other groups may also 21distribute working documents as Internet-Drafts. 22 23Internet-Drafts are draft documents valid for a maximum of six 24months and may be updated, replaced, or obsoleted by other documents 25at any time. It is inappropriate to use Internet-Drafts as 26reference material or to cite them other than as "work in progress." 27 28The list of current Internet-Drafts can be accessed at 29http://www.ietf.org/ietf/1id-abstracts.txt 30 31The list of Internet-Draft Shadow Directories can be accessed at 32http://www.ietf.org/shadow.html 33 34The distribution of this memo is unlimited. It is filed as 35draft-ietf-cat-kerberos-pk-init-18.txt and expires August 20, 2004. 36Please send comments to the authors. 37 38 391. Abstract 40 41This draft describes protocol extensions (hereafter called PKINIT) 42to the Kerberos protocol specification (RFC 1510bis [1]). These 43extensions provide a method for integrating public key cryptography 44into the initial authentication exchange, by passing cryptographic 45certificates and associated authenticators in preauthentication data 46fields. 47 48 492. Introduction 50 51A client typically authenticates itself to a service in Kerberos 52using three distinct though related exchanges. First, the client 53requests a ticket-granting ticket (TGT) from the Kerberos 54authentication server (AS). Then, it uses the TGT to request a 55service ticket from the Kerberos ticket-granting server (TGS). 56Usually, the AS and TGS are integrated in a single device known as 57a Kerberos Key Distribution Center, or KDC. (In this draft, we will 58refer to both the AS and the TGS as the KDC.) Finally, the client 59uses the service ticket to authenticate itself to the service. 60 61The advantage afforded by the TGT is that the user need only 62explicitly request a ticket and expose his credentials once. The 63TGT and its associated session key can then be used for any 64subsequent requests. One implication of this is that all further 65authentication is independent of the method by which the initial 66authentication was performed. Consequently, initial authentication 67provides a convenient place to integrate public-key cryptography 68into Kerberos authentication. 69 70As defined, Kerberos authentication exchanges use symmetric-key 71cryptography, in part for performance. (Symmetric-key cryptography 72is typically 10-100 times faster than public-key cryptography, 73depending on the public-key operations. [cite]) One cost of using 74symmetric-key cryptography is that the keys must be shared, so that 75before a user can authentication himself, he must already be 76registered with the KDC. 77 78Conversely, public-key cryptography--in conjunction with an 79established certification infrastructure--permits authentication 80without prior registration. Adding it to Kerberos allows the 81widespread use of Kerberized applications by users without requiring 82them to register first--a requirement that has no inherent security 83benefit. 84 85As noted above, a convenient and efficient place to introduce 86public-key cryptography into Kerberos is in the initial 87authentication exchange. This document describes the methods and 88data formats for integrating public-key cryptography into Kerberos 89initial authentication. Another document (PKCROSS) describes a 90similar protocol for Kerberos cross-realm authentication. 91 92 933. Extensions 94 95This section describes extensions to RFC 1510bis for supporting the 96use of public-key cryptography in the initial request for a ticket 97granting ticket (TGT). 98 99Briefly, the following changes to RFC 1510bis are proposed: 100 101 1. If public-key authentication is indicated, the client sends 102 the user's public-key data and an authenticator in a 103 preauthentication field accompanying the usual request. 104 This authenticator is signed by the user's private 105 signature key. 106 107 2. The KDC verifies the client's request against its own 108 policy and certification authorities. 109 110 3. If the request passes the verification tests, the KDC 111 replies as usual, but the reply is encrypted using either: 112 113 a. a randomly generated key, signed using the KDC's 114 signature key and encrypted using the user's encryption 115 key; or 116 117 b. a key generated through a Diffie-Hellman exchange with 118 the client, signed using the KDC's signature key. 119 120 Any key data required by the client to obtain the encryption 121 key is returned in a preauthentication field accompanying 122 the usual reply. 123 124 4. The client obtains the encryption key, decrypts the reply, 125 and then proceeds as usual. 126 127Section 3.1 of this document defines the necessary message formats. 128Section 3.2 describes their syntax and use in greater detail. 129Implementation of all specified formats and uses in these sections 130is REQUIRED for compliance with PKINIT. 131 132 1333.1. Definitions 134 135 1363.1.1. Required Algorithms 137 138At minimum, PKINIT must be able to use the following algorithms: 139 140 Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype 141 (as required by clarifications). 142 Signature algorithm: SHA-1 digest and RSA. 143 Reply key delivery method: ephemeral-ephemeral Diffie-Hellman 144 with a non-zero nonce. 145 Unkeyed checksum type for the paChecksum member of 146 PKAuthenticator: SHA1 (unkeyed). 147 148 1493.1.2. Defined Message and Encryption Types 150 151PKINIT makes use of the following new preauthentication types: 152 153 PA-PK-AS-REQ TBD 154 PA-PK-AS-REP TBD 155 PA-PK-OCSP-REQ TBD 156 PA-PK-OCSP-REP TBD 157 158PKINIT also makes use of the following new authorization data type: 159 160 AD-INITIAL-VERIFIED-CAS TBD 161 162PKINIT introduces the following new error types: 163 164 KDC_ERR_CLIENT_NOT_TRUSTED 62 165 KDC_ERR_KDC_NOT_TRUSTED 63 166 KDC_ERR_INVALID_SIG 64 167 KDC_ERR_KEY_TOO_WEAK 65 168 KDC_ERR_CERTIFICATE_MISMATCH 66 169 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 170 KDC_ERR_INVALID_CERTIFICATE 71 171 KDC_ERR_REVOKED_CERTIFICATE 72 172 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 173 KDC_ERR_CLIENT_NAME_MISMATCH 75 174 175PKINIT uses the following typed data types for errors: 176 177 TD-DH-PARAMETERS 102 178 TD-TRUSTED-CERTIFIERS 104 179 TD-CERTIFICATE-INDEX 105 180 181PKINIT defines the following encryption types, for use in the AS-REQ 182message (to indicate acceptance of the corresponding encryption OIDs 183in PKINIT): 184 185 dsaWithSHA1-CmsOID 9 186 md5WithRSAEncryption-CmsOID 10 187 sha1WithRSAEncryption-CmsOID 11 188 rc2CBC-EnvOID 12 189 rsaEncryption-EnvOID (PKCS1 v1.5) 13 190 rsaES-OAEP-ENV-OID (PKCS1 v2.0) 14 191 des-ede3-cbc-Env-OID 15 192 193The above encryption types are used (in PKINIT) only within CMS [8] 194structures within the PKINIT preauthentication fields. Their use 195within Kerberos EncryptedData structures is unspecified. 196 197 1983.1.3. Algorithm Identifiers 199 200PKINIT does not define, but does make use of, the following 201algorithm identifiers. 202 203PKINIT uses the following algorithm identifier for Diffie-Hellman 204key agreement [11]: 205 206 dhpublicnumber 207 208PKINIT uses the following signature algorithm identifiers [8, 12]: 209 210 sha-1WithRSAEncryption (RSA with SHA1) 211 md5WithRSAEncryption (RSA with MD5) 212 id-dsa-with-sha1 (DSA with SHA1) 213 214PKINIT uses the following encryption algorithm identifiers [12] for 215encrypting the temporary key with a public key: 216 217 rsaEncryption (PKCS1 v1.5) 218 id-RSAES-OAEP (PKCS1 v2.0) 219 220These OIDs are not to be confused with the encryption types listed 221above. 222 223PKINIT uses the following algorithm identifiers [8] for encrypting 224the reply key with the temporary key: 225 226 des-ede3-cbc (three-key 3DES, CBC mode) 227 rc2-cbc (RC2, CBC mode) 228 229Again, these OIDs are not to be confused with the encryption types 230listed above. 231 232 2333.2. PKINIT Preauthentication Syntax and Use 234 235In this section, we describe the syntax and use of the various 236preauthentication fields employed to implement PKINIT. 237 238 2393.2.1. Client Request 240 241The initial authentication request (AS-REQ) is sent as per RFC 2421510bis, except that a preauthentication field containing data 243signed by the user's private signature key accompanies the request, 244as follows: 245 246 PA-PK-AS-REQ ::= SEQUENCE { 247 -- PAType TBD 248 signedAuthPack [0] ContentInfo, 249 -- Defined in CMS. 250 -- Type is SignedData. 251 -- Content is AuthPack 252 -- (defined below). 253 trustedCertifiers [1] SEQUENCE OF TrustedCAs OPTIONAL, 254 -- A list of CAs, trusted by 255 -- the client, used to certify 256 -- KDCs. 257 kdcCert [2] IssuerAndSerialNumber OPTIONAL, 258 -- Defined in CMS. 259 -- Identifies a particular KDC 260 -- certificate, if the client 261 -- already has it. 262 encryptionCert [3] IssuerAndSerialNumber OPTIONAL, 263 -- May identify the user's 264 -- Diffie-Hellman certificate, 265 -- or an RSA encryption key 266 -- certificate. 267 ... 268 } 269 270 TrustedCAs ::= CHOICE { 271 caName [0] Name, 272 -- Fully qualified X.500 name 273 -- as defined in X.509 [11]. 274 issuerAndSerial [1] IssuerAndSerialNumber, 275 -- Identifies a specific CA 276 -- certificate, if the client 277 -- only trusts one. 278 ... 279 } 280 281 AuthPack ::= SEQUENCE { 282 pkAuthenticator [0] PKAuthenticator, 283 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL 284 -- Defined in X.509, 285 -- reproduced below. 286 -- Present only if the client 287 -- is using ephemeral-ephemeral 288 -- Diffie-Hellman. 289 } 290 291 PKAuthenticator ::= SEQUENCE { 292 cusec [0] INTEGER, 293 ctime [1] KerberosTime, 294 -- cusec and ctime are used as 295 -- in RFC 1510bis, for replay 296 -- prevention. 297 nonce [2] INTEGER, 298 -- Binds reply to request, 299 -- except is zero when client 300 -- will accept cached 301 -- Diffie-Hellman parameters 302 -- from KDC and MUST NOT be 303 -- zero otherwise. 304 -- MUST be < 2^32. 305 paChecksum [3] Checksum, 306 -- Defined in [15]. 307 -- Performed over KDC-REQ-BODY, 308 -- must be unkeyed. 309 ... 310 } 311 312 IMPORTS 313 -- from X.509 314 SubjectPublicKeyInfo, AlgorithmIdentifier, DomainParameters, 315 ValidationParms 316 FROM PKIX1Explicit88 { iso (1) identified-organization (3) 317 dod (6) internet (1) security (5) mechanisms (5) 318 pkix (7) id-mod (0) id-pkix1-explicit-88 (1) } 319 320The ContentInfo in the signedAuthPack is filled out as follows: 321 322 1. The eContent field contains data of type AuthPack. It MUST 323 contain the pkAuthenticator, and MAY also contain the 324 user's Diffie-Hellman public value (clientPublicValue). 325 326 2. The eContentType field MUST contain the OID value for 327 pkauthdata: { iso (1) org (3) dod (6) internet (1) 328 security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)} 329 330 3. The signerInfos field MUST contain the signature of the 331 AuthPack. 332 333 4. The certificates field MUST contain at least a signature 334 verification certificate chain that the KDC can use to 335 verify the signature on the AuthPack. Additionally, the 336 client may also insert an encryption certificate chain, if 337 (for example) the client is not using ephemeral-ephemeral 338 Diffie-Hellman. 339 340 5. If a Diffie-Hellman key is being used, the parameters SHOULD 341 be chosen from the First or Second defined Oakley Groups. 342 (See RFC 2409 [c].) 343 344 6. The KDC may wish to use cached Diffie-Hellman parameters. 345 To indicate acceptance of caching, the client sends zero in 346 the nonce field of the pkAuthenticator. Zero is not a valid 347 value for this field under any other circumstances. Since 348 zero is used to indicate acceptance of cached parameters, 349 message binding in this case is performed instead using the 350 nonce in the main request. 351 352 3533.2.2. Validation of Client Request 354 355Upon receiving the client's request, the KDC validates it. This 356section describes the steps that the KDC MUST (unless otherwise 357noted) take in validating the request. 358 359The KDC must look for a user certificate in the signedAuthPack. 360If it cannot find one signed by a CA it trusts, it sends back an 361error of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying 362e-data for this error is a SEQUENCE OF TypedData: 363 364 TypedData ::= SEQUENCE { 365 -- As defined in RFC 1510bis. 366 data-type [0] INTEGER, 367 data-value [1] OCTET STRING 368 } 369 370For this error, the data-type is TD-TRUSTED-CERTIFIERS, and the 371data-value is an OCTET STRING containing the DER encoding of 372 373 TrustedCertifiers ::= SEQUENCE OF Name 374 375If, while verifying the certificate chain, the KDC determines that 376the signature on one of the certificates in the signedAuthPack is 377invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE. 378The accompanying e-data for this error is a SEQUENCE OF TypedData, 379whose data-type is TD-CERTIFICATE-INDEX, and whose data-value is an 380OCTET STRING containing the DER encoding of the index into the 381CertificateSet field, ordered as sent by the client: 382 383 CertificateIndex ::= INTEGER 384 -- 0 = first certificate (in 385 -- order of encoding), 386 -- 1 = second certificate, etc. 387 388If more than one signature is invalid, the KDC sends one TypedData 389per invalid signature. 390 391The KDC MAY also check whether any of the certificates in the user's 392chain have been revoked. If any of them have been revoked, the KDC 393returns an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC 394attempts to determine the revocation status but is unable to do so, 395it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN. 396The certificate or certificates affected are identified exactly as 397for an error of type KDC_ERR_INVALID_CERTIFICATE (see above). 398 399If the certificate chain is successfully validated, but the user's 400certificate is not authorized to the client's principal name in the 401AS-REQ (when present), the KDC MUST return an error of type 402KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for 403this error. 404 405Even if the chain is validated, and the names in the certificate and 406the request match, the KDC may decide not to trust the client. For 407example, the certificate may include (or not include) an Enhanced 408Key Usage (EKU) OID in the extensions field. As a matter of local 409policy, the KDC may decide to reject requests on the basis of the 410absence or presence of specific EKU OIDs. In this case, the KDC 411returns an error of type KDC_ERR_CLIENT_NOT_TRUSTED. For the 412benefit of implementors, we define a PKINIT EKU OID as follows: 413{ iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2) 414pkinit (3) pkekuoid (4) }. 415 416If the certificate chain and usage check out, but the client's 417signature on the signedAuthPack fails to verify, the KDC returns an 418error of type KDC_ERR_INVALID_SIG. There is no accompanying e-data 419for this error. 420 421The KDC must check the timestamp to ensure that the request is not 422a replay, and that the time skew falls within acceptable limits. 423The recommendations for ordinary (that is, non-PKINIT) skew times 424apply here. If the check fails, the KDC returns an error of type 425KRB_AP_ERR_REPEAT or KRB_AP_ERR_SKEW, respectively. 426 427Finally, if the clientPublicValue is filled in, indicating that the 428client wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC 429checks to see if the parameters satisfy its policy. If they do not, 430it returns an error of type KDC_ERR_KEY_TOO_WEAK. The accompanying 431e-data is a SEQUENCE OF TypedData, whose data-type is 432TD-DH-PARAMETERS, and whose data-value is an OCTET STRING containing 433the DER encoding of a DomainParameters (see above), including 434appropriate Diffie-Hellman parameters with which to retry the 435request. 436 437In order to establish authenticity of the reply, the KDC will sign 438some key data (either the random key used to encrypt the reply in 439the case of a KDCDHKeyInfo, or the Diffie-Hellman parameters used to 440generate the reply-encrypting key in the case of a ReplyKeyPack). 441The signature certificate to be used is to be selected as follows: 442 443 1. If the client included a kdcCert field in the PA-PK-AS-REQ, 444 use the referred-to certificate, if the KDC has it. If it 445 does not, the KDC returns an error of type 446 KDC_ERR_CERTIFICATE_MISMATCH. 447 448 2. Otherwise, if the client did not include a kdcCert field, 449 but did include a trustedCertifiers field, and the KDC 450 possesses a certificate issued by one of the listed 451 certifiers, use that certificate. if it does not possess 452 one, it returns an error of type KDC_ERR_KDC_NOT_TRUSTED. 453 454 3. Otherwise, if the client included neither a kdcCert field 455 nor a trustedCertifiers field, and the KDC has only one 456 signature certificate, use that certificate. If it has 457 more than one certificate, it returns an error of type 458 KDC_ERR_CERTIFICATE_MISMATCH. 459 460 4613.2.3. KDC Reply 462 463Assuming that the client's request has been properly validated, the 464KDC proceeds as per RFC 1510bis, except as follows. 465 466The user's name as represented in the AS-REP must be derived from 467the certificate provided in the client's request. If the KDC has 468its own mapping from the name in the certificate to a Kerberos name, 469it uses that Kerberos name. 470 471Otherwise, if the certificate contains a SubjectAltName extension 472with a KerberosName in the otherName field, it uses that name. 473 474 AnotherName ::= SEQUENCE { 475 -- Defined in [11]. 476 type-id OBJECT IDENTIFIER, 477 value [0] EXPLICIT ANY DEFINED BY type-id 478 } 479 480 KerberosName ::= SEQUENCE { 481 realm [0] Realm, 482 principalName [1] PrincipalName 483 } 484 485with OID 486 487 krb5 OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6) internet (1) 488 security (5) kerberosv5 (2) } 489 490 krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 } 491 492In this case, the realm in the ticket is that of the local realm (or 493some other realm name chosen by that realm). Otherwise, the KDC 494returns an error of type KDC_ERR_CLIENT_NAME_MISMATCH. 495 496In addition, the KDC MUST set the initial flag in the issued TGT 497*and* add an authorization data of type AD-INITIAL-VERIFIED-CAS to 498the TGT. The value is an OCTET STRING containing the DER encoding 499of InitialVerifiedCAs: 500 501 InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE { 502 ca [0] Name, 503 ocspValidated [1] BOOLEAN, 504 ... 505 } 506 507The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT 508containers if the list of CAs satisfies the KDC's realm's policy. 509(This corresponds to the TRANSITED-POLICY-CHECKED ticket flag.) 510Furthermore, any TGS must copy such authorization data from tickets 511used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket, 512including the AD-IF-RELEVANT container, if present. 513 514AP servers that understand this authorization data type SHOULD apply 515local policy to determine whether a given ticket bearing such a type 516(not contained within an AD-IF-RELEVANT container) is acceptable. 517(This corresponds to the AP server checking the transited field when 518the TRANSITED-POLICY-CHECKED flag has not been set.) If such a data 519type *is* contained within an AD-IF-RELEVANT container, AP servers 520still MAY apply local policy to determine whether the authorization 521data is acceptable. 522 523The AS-REP is otherwise unchanged from RFC 1510bis. The KDC then 524encrypts the reply as usual, but not with the user's long-term key. 525Instead, it encrypts it with either a random encryption key, or a 526key derived from a Diffie-Hellman exchange. Which is the case is 527indicated by the contents of the PA-PK-AS-REP (note tags): 528 529 PA-PK-AS-REP ::= CHOICE { 530 -- PAType YY (TBD) 531 dhSignedData [0] ContentInfo, 532 -- Type is SignedData. 533 -- Content is KDCDHKeyInfo 534 -- (defined below). 535 encKeyPack [1] ContentInfo, 536 -- Type is EnvelopedData. 537 -- Content is ReplyKeyPack 538 -- (defined below). 539 ... 540 } 541 542Note that PA-PK-AS-REP is a CHOICE: either a dhSignedData, or an 543encKeyPack, but not both. The former contains data of type 544KDCDHKeyInfo, and is used only when the reply is encrypted using a 545Diffie-Hellman derived key: 546 547 KDCDHKeyInfo ::= SEQUENCE { 548 subjectPublicKey [0] BIT STRING, 549 -- Equals public exponent 550 -- (g^a mod p). 551 -- INTEGER encoded as payload 552 -- of BIT STRING. 553 nonce [1] INTEGER, 554 -- Binds reply to request. 555 -- Exception: A value of zero 556 -- indicates that the KDC is 557 -- using cached values. 558 dhKeyExpiration [2] KerberosTime OPTIONAL, 559 -- Expiration time for KDC's 560 -- cached values. 561 ... 562 } 563 564The fields of the ContentInfo for dhSignedData are to be filled in 565as follows: 566 567 1. The eContent field contains data of type KDCDHKeyInfo. 568 569 2. The eContentType field contains the OID value for 570 pkdhkeydata: { iso (1) org (3) dod (6) internet (1) 571 security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2) } 572 573 3. The signerInfos field contains a single signerInfo, which is 574 the signature of the KDCDHKeyInfo. 575 576 4. The certificates field contains a signature verification 577 certificate chain that the client may use to verify the 578 KDC's signature over the KDCDHKeyInfo.) It may only be left 579 empty if the client did not include a trustedCertifiers 580 field in the PA-PK-AS-REQ, indicating that it has the KDC's 581 certificate. 582 583 5. If the client and KDC agree to use cached parameters, the 584 KDC SHOULD return a zero in the nonce field and include the 585 expiration time of the cached values in the dhKeyExpiration 586 field. If this time is exceeded, the client SHOULD NOT use 587 the reply. If the time is absent, the client SHOULD NOT use 588 the reply and MAY resubmit a request with a non-zero nonce, 589 thus indicating non-acceptance of the cached parameters. 590 591The key is derived as follows: Both the KDC and the client calculate 592the value g^(ab) mod p, where a and b are the client's and KDC's 593private exponents, respectively. They both take the first k bits of 594this secret value as a key generation seed, where the parameter k 595(the size of the seed) is dependent on the selected key type, as 596specified in the Kerberos crypto draft [15]. The seed is then 597converted into a protocol key by applying to it a random-to-key 598function, which is also dependent on key type. 599 600The protocol key is used to derive the integrity key Ki and the 601encryption key Ke according to [15]. Ke and Ki are used to generate 602the encrypted part of the AS-REP. 603 604 1. For example, if the encryption type is DES with MD4, k = 64 605 bits and the random-to-key function consists of replacing 606 some of the bits with parity bits, according to FIPS PUB 74 607 [cite]. In this case, the key derivation function for Ke is 608 the identity function, and Ki is not needed because the 609 checksum in the EncryptedData is not keyed. 610 611 2. If the encryption type is three-key 3DES with HMAC-SHA1, 612 k = 168 bits and the random-to-key function is 613 DES3random-to-key as defined in [15]. This function inserts 614 parity bits to create a 192-bit 3DES protocol key that is 615 compliant with FIPS PUB 74 [cite]. Ke and Ki are derived 616 from this protocol key according to [15] with the key usage 617 number set to 3 (AS-REP encrypted part). 618 619If the KDC and client are not using Diffie-Hellman, the KDC encrypts 620the reply with an encryption key, packed in the encKeyPack, which 621contains data of type ReplyKeyPack: 622 623 ReplyKeyPack ::= SEQUENCE { 624 replyKey [0] EncryptionKey, 625 -- Defined in RFC 1510bis. 626 -- Used to encrypt main reply. 627 -- MUST be at least as large 628 -- as session key. 629 nonce [1] INTEGER, 630 -- Binds reply to request. 631 -- MUST be < 2^32. 632 ... 633 } 634 635The fields of the ContentInfo for encKeyPack MUST be filled in as 636follows: 637 638 1. The innermost data is of type SignedData. The eContent for 639 this data is of type ReplyKeyPack. 640 641 2. The eContentType for this data contains the OID value for 642 pkrkeydata: { iso (1) org (3) dod (6) internet (1) 643 security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3) } 644 645 3. The signerInfos field contains a single signerInfo, which is 646 the signature of the ReplyKeyPack. 647 648 4. The certificates field contains a signature verification 649 certificate chain, which the client may use to verify the 650 KDC's signature over the ReplyKeyPack.) It may only be left 651 empty if the client did not include a trustedCertifiers 652 field in the PA-PK-AS-REQ, indicating that it has the KDC's 653 certificate. 654 655 5. The outer data is of type EnvelopedData. The 656 encryptedContent for this data is the SignedData described 657 in items 1 through 4, above. 658 659 6. The encryptedContentType for this data contains the OID 660 value for id-signedData: { iso (1) member-body (2) us (840) 661 rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) } 662 663 7. The recipientInfos field is a SET which MUST contain exactly 664 one member of type KeyTransRecipientInfo. The encryptedKey 665 for this member contains the temporary key which is 666 encrypted using the client's public key. 667 668 8. Neither the unprotectedAttrs field nor the originatorInfo 669 field is required for PKINIT. 670 671 6723.2.4. Validation of KDC Reply 673 674Upon receipt of the KDC's reply, the client proceeds as follows. If 675the PA-PK-AS-REP contains a dhSignedData, the client obtains and 676verifies the Diffie-Hellman parameters, and obtains the shared key 677as described above. Otherwise, the message contains an encKeyPack, 678and the client decrypts and verifies the temporary encryption key. 679In either case, the client then decrypts the main reply with the 680resulting key, and then proceeds as described in RFC 1510bis. 681 682 6833.2.5. Support for OCSP 684 685OCSP (Online Certificate Status Protocol) [cite] allows the use of 686on-line requests for a client or server to determine the validity of 687each other's certificates. It is particularly useful for clients 688authenticating each other across a constrained network. These 689clients will not have to download the entire CRL to check for the 690validity of the KDC's certificate. 691 692In these cases, the KDC generally has better connectivity to the 693OCSP server, and it therefore processes the OCSP request and 694response and sends the results to the client. The changes proposed 695in this section allow a client to request an OCSP response from the 696KDC when using PKINIT. This is similar to the way that OCSP is 697handled in [cite]. 698 699OCSP support is provided in PKINIT through the use of additional 700preauthentication data. The following new preauthentication types 701are defined: 702 703 PA-PK-OCSP-REQ ::= SEQUENCE { 704 -- PAType TBD 705 responderIDList [0] SEQUENCE of ResponderID OPTIONAL, 706 -- ResponderID is a DER-encoded 707 -- ASN.1 type defined in [cite] 708 requestExtensions [1] Extensions OPTIONAL 709 -- Extensions is a DER-encoded 710 -- ASN.1 type defined in [cite] 711 } 712 713 PA-PK-OCSP-REP ::= SEQUENCE of OCSPResponse 714 -- OCSPResponse is a DER-encoded 715 -- ASN.1 type defined in [cite] 716 717A KDC that receives a PA-PK-OCSP-REQ MAY send a PA-PK-OCSP-REP. 718KDCs MUST NOT send a PA-PK-OCSP-REP if they do not first receive a 719PA-PK-OCSP-REQ from the client. The KDC may either send a cached 720OCSP response or send an on-line request to the OCSP server. 721 722When using OCSP, the response is signed by the OCSP server, which is 723trusted by the client. Depending on local policy, further 724verification of the validity of the OCSP server may need to be done. 725 726 7274. Security Considerations 728 729PKINIT raises certain security considerations beyond those that can 730be regulated strictly in protocol definitions. We will address them 731in this section. 732 733PKINIT extends the cross-realm model to the public-key 734infrastructure. Anyone using PKINIT must be aware of how the 735certification infrastructure they are linking to works. 736 737Also, as in standard Kerberos, PKINIT presents the possibility of 738interactions between cryptosystems of varying strengths, and this 739now includes public-key cryptosystems. Many systems, for example, 740allow the use of 512-bit public keys. Using such keys to wrap data 741encrypted under strong conventional cryptosystems, such as 3DES, may 742be inappropriate. 743 744PKINIT calls for randomly generated keys for conventional 745cryptosystems. Many such systems contain systematically "weak" 746keys. For recommendations regarding these weak keys, see RFC 7471510bis. 748 749PKINIT allows the use of a zero nonce in the PKAuthenticator when 750cached Diffie-Hellman parameters are used. In this case, message 751binding is performed using the nonce in the main request in the same 752way as it is done for ordinary (that is, non-PKINIT) AS-REQs. The 753nonce field in the KDC request body is signed through the checksum 754in the PKAuthenticator, and it therefore cryptographically binds the 755AS-REQ with the AS-REP. If cached parameters are also used on the 756client side, the generated session key will be the same, and a 757compromised session key could lead to the compromise of future 758cached exchanges. It is desirable to limit the use of cached 759parameters to just the KDC, in order to eliminate this exposure. 760 761Care should be taken in how certificates are chosen for the purposes 762of authentication using PKINIT. Some local policies may require 763that key escrow be applied for certain certificate types. People 764deploying PKINIT should be aware of the implications of using 765certificates that have escrowed keys for the purposes of 766authentication. 767 768PKINIT does not provide for a "return routability" test to prevent 769attackers from mounting a denial-of-service attack on the KDC by 770causing it to perform unnecessary and expensive public-key 771operations. Strictly speaking, this is also true of standard 772Kerberos, although the potential cost is not as great, because 773standard Kerberos does not make use of public-key cryptography. 774It might be possible to address this using a preauthentication field 775as part of the proposed Kerberos preauthenticatino framework. 776 777 7785. Acknowledgements 779 780Some of the ideas on which this proposal is based arose during 781discussions over several years between members of the SAAG, the IETF 782CAT working group, and the PSRG, regarding integration of Kerberos 783and SPX. Some ideas have also been drawn from the DASS system. 784These changes are by no means endorsed by these groups. This is an 785attempt to revive some of the goals of those groups, and this 786proposal approaches those goals primarily from the Kerberos 787perspective. Lastly, comments from groups working on similar ideas 788in DCE have been invaluable. 789 790 7916. Expiration Date 792 793This draft expires August 20, 2004. 794 795 7967. Bibliography 797 798[1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service 799(V5). Request for Comments 1510. 800 801[2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service 802for Computer Networks, IEEE Communications, 32(9):33-38. September 8031994. 804 805[3] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos 806Using Public Key Cryptography. Symposium On Network and Distributed 807System Security, 1997. 808 809[4] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction 810Protocol. In Proceedings of the USENIX Workshop on Electronic 811Commerce, July 1995. 812 813[5] T. Dierks, C. Allen. The TLS Protocol, Version 1.0. Request 814for Comments 2246, January 1999. 815 816[6] B.C. Neuman, Proxy-Based Authorization and Accounting for 817Distributed Systems. In Proceedings of the 13th International 818Conference on Distributed Computing Systems, May 1993. 819 820[7] ITU-T (formerly CCITT) Information technology - Open Systems 821Interconnection - The Directory: Authentication Framework 822Recommendation X.509 ISO/IEC 9594-8 823 824[8] R. Housley. Cryptographic Message Syntax. 825draft-ietf-smime-cms-13.txt, April 1999, approved for publication as 826RFC. 827 828[9] PKCS #7: Cryptographic Message Syntax Standard. An RSA 829Laboratories Technical Note Version 1.5. Revised November 1, 1993 830 831[10] R. Rivest, MIT Laboratory for Computer Science and RSA Data 832Security, Inc. A Description of the RC2(r) Encryption Algorithm. 833March 1998. Request for Comments 2268. 834 835[11] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public 836Key Infrastructure, Certificate and CRL Profile, April 2002. 837Request for Comments 3280. 838 839[12] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography 840Specifications, October 1998. Request for Comments 2437. 841 842[13] ITU-T (formerly CCITT) Information Processing Systems - Open 843Systems Interconnection - Specification of Abstract Syntax Notation 844One (ASN.1) Rec. X.680 ISO/IEC 8824-1. 845 846[14] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA 847Laboratories Technical Note, Version 1.4, Revised November 1, 1993. 848 849[15] K. Raeburn. Encryption and Checksum Specifications for 850Kerberos 5, October 2003. draft-ietf-krb-wg-crypto-06.txt. 851 852[16] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and 853T. Wright. Transport Layer Security (TLS) Extensions, June 2003. 854Request for Comments 3546. 855 856[17] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams. 857Internet X.509 Public Key Infrastructure: Online Certificate Status 858Protocol - OCSP, June 1999. Request for Comments 2560. 859 860 8618. Authors 862 863Brian Tung 864Clifford Neuman 865USC Information Sciences Institute 8664676 Admiralty Way Suite 1001 867Marina del Rey CA 90292-6695 868Phone: +1 310 822 1511 869E-mail: {brian,bcn}@isi.edu 870 871Matthew Hur 872Ari Medvinsky 873Microsoft Corporation 874One Microsoft Way 875Redmond WA 98052 876Phone: +1 425 707 3336 877E-mail: matthur@microsoft.com, arimed@windows.microsoft.com 878 879Sasha Medvinsky 880Motorola, Inc. 8816450 Sequence Drive 882San Diego, CA 92121 883+1 858 404 2367 884E-mail: smedvinsky@motorola.com 885 886John Wray 887Iris Associates, Inc. 8885 Technology Park Dr. 889Westford, MA 01886 890E-mail: John_Wray@iris.com 891 892Jonathan Trostle 893E-mail: jtrostle@world.std.com 894