| < draft-ietf-cat-kerberos-pk-init-33.txt | draft-ietf-cat-kerberos-pk-init-34.txt > | |||
|---|---|---|---|---|
| NETWORK WORKING GROUP L. Zhu | NETWORK WORKING GROUP L. Zhu | |||
| Internet-Draft Microsoft Corporation | Internet-Draft Microsoft Corporation | |||
| Expires: July 28, 2006 B. Tung | Expires: August 11, 2006 B. Tung | |||
| USC Information Sciences Institute | USC Information Sciences Institute | |||
| January 24, 2006 | February 7, 2006 | |||
| Public Key Cryptography for Initial Authentication in Kerberos | Public Key Cryptography for Initial Authentication in Kerberos | |||
| draft-ietf-cat-kerberos-pk-init-33 | draft-ietf-cat-kerberos-pk-init-34 | |||
| Status of this Memo | Status of this Memo | |||
| By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
| applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
| have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
| aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| skipping to change at page 1, line 35 ¶ | skipping to change at page 1, line 35 ¶ | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This Internet-Draft will expire on July 28, 2006. | This Internet-Draft will expire on August 11, 2006. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (C) The Internet Society (2006). | Copyright (C) The Internet Society (2006). | |||
| Abstract | Abstract | |||
| This document describes protocol extensions (hereafter called PKINIT) | This document describes protocol extensions (hereafter called PKINIT) | |||
| to the Kerberos protocol specification. These extensions provide a | to the Kerberos protocol specification. These extensions provide a | |||
| method for integrating public key cryptography into the initial | method for integrating public key cryptography into the initial | |||
| authentication exchange, by using asymmetric-key signature and/or | authentication exchange, by using asymmetric-key signature and/or | |||
| encryption algorithms in pre-authentication data fields. | encryption algorithms in pre-authentication data fields. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 | 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 | |||
| 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 3.1. Definitions, Requirements, and Constants . . . . . . . . . 6 | 3.1. Definitions, Requirements, and Constants . . . . . . . . . 6 | |||
| 3.1.1. Required Algorithms . . . . . . . . . . . . . . . . . 6 | 3.1.1. Required Algorithms . . . . . . . . . . . . . . . . . 6 | |||
| 3.1.2. Defined Message and Encryption Types . . . . . . . . . 7 | 3.1.2. Recommended Algorithms . . . . . . . . . . . . . . . . 6 | |||
| 3.1.3. Kerberos Encryption Types Defined for CMS | 3.1.3. Defined Message and Encryption Types . . . . . . . . . 7 | |||
| 3.1.4. Kerberos Encryption Types Defined for CMS | ||||
| Algorithm Identifiers . . . . . . . . . . . . . . . . 8 | Algorithm Identifiers . . . . . . . . . . . . . . . . 8 | |||
| 3.2. PKINIT Pre-authentication Syntax and Use . . . . . . . . . 9 | 3.2. PKINIT Pre-authentication Syntax and Use . . . . . . . . . 9 | |||
| 3.2.1. Generation of Client Request . . . . . . . . . . . . . 9 | 3.2.1. Generation of Client Request . . . . . . . . . . . . . 9 | |||
| 3.2.2. Receipt of Client Request . . . . . . . . . . . . . . 14 | 3.2.2. Receipt of Client Request . . . . . . . . . . . . . . 14 | |||
| 3.2.3. Generation of KDC Reply . . . . . . . . . . . . . . . 18 | 3.2.3. Generation of KDC Reply . . . . . . . . . . . . . . . 18 | |||
| 3.2.4. Receipt of KDC Reply . . . . . . . . . . . . . . . . . 25 | 3.2.4. Receipt of KDC Reply . . . . . . . . . . . . . . . . . 25 | |||
| 3.3. Interoperability Requirements . . . . . . . . . . . . . . 26 | 3.3. Interoperability Requirements . . . . . . . . . . . . . . 26 | |||
| 3.4. KDC Indication of PKINIT Support . . . . . . . . . . . . . 26 | 3.4. KDC Indication of PKINIT Support . . . . . . . . . . . . . 27 | |||
| 4. Security Considerations . . . . . . . . . . . . . . . . . . . 27 | 4. Security Considerations . . . . . . . . . . . . . . . . . . . 27 | |||
| 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 | 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 | |||
| 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
| 7.1. Normative References . . . . . . . . . . . . . . . . . . . 30 | 7.1. Normative References . . . . . . . . . . . . . . . . . . . 30 | |||
| 7.2. Informative References . . . . . . . . . . . . . . . . . . 32 | 7.2. Informative References . . . . . . . . . . . . . . . . . . 32 | |||
| Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 32 | Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 32 | |||
| Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 37 | Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 38 | |||
| Appendix C. Miscellaneous Information about Microsoft Windows | Appendix C. Miscellaneous Information about Microsoft Windows | |||
| PKINIT Implementations . . . . . . . . . . . . . . . 39 | PKINIT Implementations . . . . . . . . . . . . . . . 40 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 | |||
| Intellectual Property and Copyright Statements . . . . . . . . . . 42 | Intellectual Property and Copyright Statements . . . . . . . . . . 42 | |||
| 1. Introduction | 1. Introduction | |||
| The Kerberos V5 protocol [RFC4120] involves use of a trusted third | The Kerberos V5 protocol [RFC4120] involves use of a trusted third | |||
| party known as the Key Distribution Center (KDC) to negotiate shared | party known as the Key Distribution Center (KDC) to negotiate shared | |||
| session keys between clients and services and provide mutual | session keys between clients and services and provide mutual | |||
| authentication between them. | authentication between them. | |||
| skipping to change at page 6, line 35 ¶ | skipping to change at page 6, line 35 ¶ | |||
| Section 3.1 of this document enumerates the required algorithms and | Section 3.1 of this document enumerates the required algorithms and | |||
| necessary extension message types. Section 3.2 describes the | necessary extension message types. Section 3.2 describes the | |||
| extension messages in greater detail. | extension messages in greater detail. | |||
| 3.1. Definitions, Requirements, and Constants | 3.1. Definitions, Requirements, and Constants | |||
| 3.1.1. Required Algorithms | 3.1.1. Required Algorithms | |||
| All PKINIT implementations MUST support the following algorithms: | All PKINIT implementations MUST support the following algorithms: | |||
| o AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac- | o AS reply key enctype(s): aes128-cts-hmac-sha1-96 and aes256-cts- | |||
| sha1-96 [RFC3962]. | hmac-sha1-96 [RFC3962]. | |||
| o Signature algorithm: sha-1WithRSAEncryption [RFC3279]. | ||||
| o AS reply key delivery method: Diffie-Hellman key exchange | ||||
| [RFC2631]. | ||||
| o Algorithms identified in the contentEncryptionAlgorithm field of | o Signature algorithm(s): sha-1WithRSAEncryption [RFC3370]. | |||
| the type EncryptedContentInfo [RFC3852] for encrypting the | ||||
| temporary key in the encryptedKey field of the type | ||||
| KeyTransRecipientInfo [RFC3852] with a public key, as described in | ||||
| Section 3.2.3.2: rsaEncryption [RFC3447] [RFC3279]. | ||||
| o Algorithms identified in the contentEncryptionAlgorithm field of | o AS reply key delivery method(s): the Diffie-Hellman key delivery | |||
| the type EncryptedContentInfo [RFC3852] for encrypting the AS | method as described in Section 3.2.3.1. | |||
| reply key with the temporary key contained in the encryptedKey | ||||
| field of the type KeyTransRecipientInfo [RFC3852], as described in | ||||
| Section 3.2.3.2: des-ede3-cbc (three-key 3DES, CBC mode) | ||||
| [RFC3370]. | ||||
| In addition, implementations of this specification MUST be capable of | In addition, implementations of this specification MUST be capable of | |||
| processing the Extended Key Usage (EKU) extension and the id-pkinit- | processing the Extended Key Usage (EKU) extension and the id-pkinit- | |||
| san (as defined in Section 3.2.2) otherName of the Subject | san (as defined in Section 3.2.2) otherName of the Subject | |||
| Alternative Name (SAN) extension in X.509 certificates [RFC3280]. | Alternative Name (SAN) extension in X.509 certificates [RFC3280]. | |||
| 3.1.2. Defined Message and Encryption Types | 3.1.2. Recommended Algorithms | |||
| All PKINIT implementations SHOULD support the following algorithms: | ||||
| o AS reply key delivery method(s): the public key encryption key | ||||
| delivery method as described in Section 3.2.3.2. | ||||
| For implementations that support the public key encryption key | ||||
| delivery method, the following algorithms MUST be supported: | ||||
| a) Key transport algorithm(s) identified in the | ||||
| keyEncryptionAlgorithm field of the type KeyTransRecipientInfo | ||||
| [RFC3852] for encrypting the temporary key in the encryptedKey | ||||
| field [RFC3852] with a public key, as described in | ||||
| Section 3.2.3.2: rsaEncryption (this is the RSAES-PKCS1-v1_5 | ||||
| encryption scheme) [RFC3370] [RFC3447]. | ||||
| b) Content encryption algorithm(s) identified in the | ||||
| contentEncryptionAlgorithm field of the type EncryptedContentInfo | ||||
| [RFC3852] for encrypting the AS reply key with the temporary key | ||||
| contained in the encryptedKey field of the type | ||||
| KeyTransRecipientInfo [RFC3852], as described in Section 3.2.3.2: | ||||
| des-ede3-cbc (three-key 3DES, CBC mode) [RFC3370]. | ||||
| 3.1.3. Defined Message and Encryption Types | ||||
| PKINIT makes use of the following new pre-authentication types: | PKINIT makes use of the following new pre-authentication types: | |||
| PA_PK_AS_REQ 16 | PA_PK_AS_REQ 16 | |||
| PA_PK_AS_REP 17 | PA_PK_AS_REP 17 | |||
| PKINIT also makes use of the following new authorization data type: | PKINIT also makes use of the following new authorization data type: | |||
| AD_INITIAL_VERIFIED_CAS 9 | AD_INITIAL_VERIFIED_CAS 9 | |||
| skipping to change at page 7, line 37 ¶ | skipping to change at page 7, line 50 ¶ | |||
| KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65 | KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65 | |||
| KDC_ERR_CANT_VERIFY_CERTIFICATE 70 | KDC_ERR_CANT_VERIFY_CERTIFICATE 70 | |||
| KDC_ERR_INVALID_CERTIFICATE 71 | KDC_ERR_INVALID_CERTIFICATE 71 | |||
| KDC_ERR_REVOKED_CERTIFICATE 72 | KDC_ERR_REVOKED_CERTIFICATE 72 | |||
| KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 | KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 | |||
| KDC_ERR_CLIENT_NAME_MISMATCH 75 | KDC_ERR_CLIENT_NAME_MISMATCH 75 | |||
| KDC_ERR_INCONSISTENT_KEY_PURPOSE 77 | KDC_ERR_INCONSISTENT_KEY_PURPOSE 77 | |||
| KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED 78 | KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED 78 | |||
| KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED 79 | KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED 79 | |||
| KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED 80 | KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED 80 | |||
| KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED 81 | ||||
| PKINIT uses the following typed data types for errors: | PKINIT uses the following typed data types for errors: | |||
| TD_TRUSTED_CERTIFIERS 104 | TD_TRUSTED_CERTIFIERS 104 | |||
| TD_INVALID_CERTIFICATES 105 | TD_INVALID_CERTIFICATES 105 | |||
| TD_DH_PARAMETERS 109 | TD_DH_PARAMETERS 109 | |||
| The ASN.1 module for all structures defined in this document (plus | The ASN.1 module for all structures defined in this document (plus | |||
| IMPORT statements for all imported structures) is given in | IMPORT statements for all imported structures) is given in | |||
| Appendix A. | Appendix A. | |||
| skipping to change at page 8, line 12 ¶ | skipping to change at page 8, line 25 ¶ | |||
| (unless otherwise noted). All data structures carried in OCTET | (unless otherwise noted). All data structures carried in OCTET | |||
| STRINGs must be encoded according to the rules specified in | STRINGs must be encoded according to the rules specified in | |||
| corresponding specifications. | corresponding specifications. | |||
| Interoperability note: Some implementations may not be able to decode | Interoperability note: Some implementations may not be able to decode | |||
| wrapped Cryptographic Message Syntax (CMS) [RFC3852] objects encoded | wrapped Cryptographic Message Syntax (CMS) [RFC3852] objects encoded | |||
| with BER; specifically, they may not be able to decode indefinite | with BER; specifically, they may not be able to decode indefinite | |||
| length encodings. To maximize interoperability, implementers SHOULD | length encodings. To maximize interoperability, implementers SHOULD | |||
| encode CMS objects used in PKINIT with DER. | encode CMS objects used in PKINIT with DER. | |||
| 3.1.3. Kerberos Encryption Types Defined for CMS Algorithm Identifiers | 3.1.4. Kerberos Encryption Types Defined for CMS Algorithm Identifiers | |||
| PKINIT defines the following Kerberos encryption type numbers | PKINIT defines the following Kerberos encryption type numbers | |||
| [RFC3961], which can be used in the etype field of the AS-REQ | [RFC3961], which can be used in the etype field of the AS-REQ | |||
| [RFC4120] message to indicate to the KDC the client's acceptance of | [RFC4120] message to indicate to the KDC the client's acceptance of | |||
| the corresponding algorithms (including public encryption algorithms, | the corresponding algorithms (including key transport algorithms | |||
| bulk encryption algorithms, and signature algorithms) for use with | [RFC3370], content encryption algorithms [RFC3370], and signature | |||
| Cryptographic Message Syntax (CMS) [RFC3852]. | algorithms) for use with Cryptographic Message Syntax (CMS) [RFC3852] | |||
| [RFC3370]. | ||||
| Per [RFC4120], the encryption types in the etype field are in the | Per [RFC4120], the encryption types in the etype field are in the | |||
| decreasing preference order of the client. Note that there is no | decreasing preference order of the client. Note that there is no | |||
| significance in the relative order between any two of different types | significance in the relative order between any two of different types | |||
| of algorithms: public key encryption algorithms, bulk encryption | of algorithms: key transport algorithms, content encryption | |||
| algorithms and signature algorithms. | algorithms and signature algorithms. | |||
| The presence of each of these encryption types in the etype field is | The presence of each of these encryption types in the etype field is | |||
| equivalent to the presence of the corresponding algorithm Object | equivalent to the presence of the corresponding algorithm Object | |||
| Identifier (OID) in the supportedCMSTypes field as described in | Identifier (OID) in the supportedCMSTypes field as described in | |||
| Section 3.2.1. And the preference order expressed in the | Section 3.2.1. And the preference order expressed in the | |||
| supportedCMSTypes field would override the preference order listed in | supportedCMSTypes field would override the preference order listed in | |||
| the etype field. | the etype field. | |||
| Kerberos Encryption Type Name Num Corresponding Algorithm OID | Kerberos Encryption Type Name Num Corresponding Algorithm OID | |||
| ============================== === =============================== | ============================== === =============================== | |||
| id-dsa-with-sha1-CmsOID 9 id-dsa-with-sha1 [RFC3279] | id-dsa-with-sha1-CmsOID 9 id-dsa-with-sha1 [RFC3370] | |||
| md5WithRSAEncryption-CmsOID 10 md5WithRSAEncryption [RFC3279] | md5WithRSAEncryption-CmsOID 10 md5WithRSAEncryption [RFC3370] | |||
| sha-1WithRSAEncryption-CmsOID 11 sha-1WithRSAEncryption [RFC3279] | sha-1WithRSAEncryption-CmsOID 11 sha-1WithRSAEncryption [RFC3370] | |||
| rc2-cbc-EnvOID 12 rc2-cbc [RFC3370] | rc2-cbc-EnvOID 12 rc2-cbc [RFC3370] | |||
| rsaEncryption-EnvOID 13 rsaEncryption [RFC3447][RFC3279] | rsaEncryption-EnvOID 13 rsaEncryption [RFC3447][RFC3370] | |||
| id-RSAES-OAEP-EnvOID 14 id-RSAES-OAEP [RFC3447][RFC3279] | id-RSAES-OAEP-EnvOID 14 id-RSAES-OAEP [RFC3447][RFC3560] | |||
| des-ede3-cbc-EnvOID 15 des-ede3-cbc [RFC3370] | des-ede3-cbc-EnvOID 15 des-ede3-cbc [RFC3370] | |||
| The above encryption type numbers are used only to indicate support | The above encryption type numbers are used only to indicate support | |||
| for the use of the corresponding algorithms in PKINIT; they do not | for the use of the corresponding algorithms in PKINIT; they do not | |||
| correspond to actual Kerberos encryption types [RFC3961] and MUST NOT | correspond to actual Kerberos encryption types [RFC3961] and MUST NOT | |||
| be used in the etype field of the Kerberos EncryptedData type | be used in the etype field of the Kerberos EncryptedData type | |||
| [RFC4120]. The practice of assigning Kerberos encryption type | [RFC4120]. The practice of assigning Kerberos encryption type | |||
| numbers to indicate support for CMS algorithms is considered | numbers to indicate support for CMS algorithms is considered | |||
| deprecated, and new numbers should not be assigned for this purpose. | deprecated, and new numbers should not be assigned for this purpose. | |||
| Instead, the supportedCMSTypes field should be used to identify the | Instead, the supportedCMSTypes field should be used to identify the | |||
| algorithms supported by the client and the preference order of the | algorithms supported by the client and the preference order of the | |||
| client. | client. | |||
| For maximum interoperability, however, PKINIT clients wishing to | For maximum interoperability, however, PKINIT clients wishing to | |||
| indicate to the KDC the support for one or more of the algorithms | indicate to the KDC the support for one or more of the algorithms | |||
| listed above SHOULD include the corresponding encryption type | listed above SHOULD include the corresponding encryption type | |||
| number(s) in the etype field of the AS-REQ. | number(s) in the etype field of the AS-REQ. | |||
| 3.2. PKINIT Pre-authentication Syntax and Use | 3.2. PKINIT Pre-authentication Syntax and Use | |||
| skipping to change at page 10, line 35 ¶ | skipping to change at page 11, line 4 ¶ | |||
| -- Identifies the subject's public key by a key | -- Identifies the subject's public key by a key | |||
| -- identifier. When an X.509 certificate is | -- identifier. When an X.509 certificate is | |||
| -- referenced, this key identifier matches the X.509 | -- referenced, this key identifier matches the X.509 | |||
| -- subjectKeyIdentifier extension value. When other | -- subjectKeyIdentifier extension value. When other | |||
| -- certificate formats are referenced, the documents | -- certificate formats are referenced, the documents | |||
| -- that specify the certificate format and their use | -- that specify the certificate format and their use | |||
| -- with the CMS must include details on matching the | -- with the CMS must include details on matching the | |||
| -- key identifier to the appropriate certificate | -- key identifier to the appropriate certificate | |||
| -- field. | -- field. | |||
| -- RECOMMENDED for TD-TRUSTED-CERTIFIERS. | -- RECOMMENDED for TD-TRUSTED-CERTIFIERS. | |||
| ... | ... | |||
| } | } | |||
| AuthPack ::= SEQUENCE { | AuthPack ::= SEQUENCE { | |||
| pkAuthenticator [0] PKAuthenticator, | pkAuthenticator [0] PKAuthenticator, | |||
| clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, | clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, | |||
| -- Type SubjectPublicKeyInfo is defined in | -- Type SubjectPublicKeyInfo is defined in | |||
| -- [RFC3280]. | -- [RFC3280]. | |||
| -- Specifies Diffie-Hellman domain parameters | -- Specifies Diffie-Hellman domain parameters | |||
| -- and the client's public key value [IEEE1363]. | -- and the client's public key value [IEEE1363]. | |||
| -- The DH public key value is encoded as a BIT | -- The DH public key value is encoded as a BIT | |||
| -- STRING according to [RFC3279]. | -- STRING according to [RFC3279]. | |||
| -- This field is present only if the client wishes | -- This field is present only if the client wishes | |||
| -- to use the Diffie-Hellman key agreement method. | -- to use the Diffie-Hellman key agreement method. | |||
| supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier | supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier | |||
| OPTIONAL, | OPTIONAL, | |||
| -- Type AlgorithmIdentifier is defined in | -- Type AlgorithmIdentifier is defined in | |||
| -- [RFC3280]. | -- [RFC3280]. | |||
| -- List of CMS public key encryption algorithm | -- List of CMS algorithm [RFC3370] identifiers | |||
| -- identifiers, bulk encryption algorithm | -- that identify key transport algorithms, or | |||
| -- identifiers, or signature algorithm identifiers | -- content encryption algorithms, or signature | |||
| -- supported by the client in order of (decreasing) | -- algorithms supported by the client in order of | |||
| -- preference. | -- (decreasing) preference. | |||
| clientDHNonce [3] DHNonce OPTIONAL, | clientDHNonce [3] DHNonce OPTIONAL, | |||
| -- Present only if the client indicates that it | -- Present only if the client indicates that it | |||
| -- wishes to reuse DH keys or to allow the KDC to | -- wishes to reuse DH keys or to allow the KDC to | |||
| -- do so (see Section 3.2.3.1). | -- do so (see Section 3.2.3.1). | |||
| ... | ... | |||
| } | } | |||
| PKAuthenticator ::= SEQUENCE { | PKAuthenticator ::= SEQUENCE { | |||
| cusec [0] INTEGER (0..999999), | cusec [0] INTEGER (0..999999), | |||
| ctime [1] KerberosTime, | ctime [1] KerberosTime, | |||
| skipping to change at page 12, line 20 ¶ | skipping to change at page 12, line 34 ¶ | |||
| client and a DHNonce. The pkAuthenticator field certifies to the | client and a DHNonce. The pkAuthenticator field certifies to the | |||
| KDC that the client has recent knowledge of the signing key that | KDC that the client has recent knowledge of the signing key that | |||
| authenticates the client. The clientPublicValue field specifies | authenticates the client. The clientPublicValue field specifies | |||
| Diffie-Hellman domain parameters and the client's public key | Diffie-Hellman domain parameters and the client's public key | |||
| value. The DH public key value is encoded as a BIT STRING | value. The DH public key value is encoded as a BIT STRING | |||
| according to [RFC3279]. The clientPublicValue field is present | according to [RFC3279]. The clientPublicValue field is present | |||
| only if the client wishes to use the Diffie-Hellman key agreement | only if the client wishes to use the Diffie-Hellman key agreement | |||
| method. The supportedCMSTypes field specifies the list of CMS | method. The supportedCMSTypes field specifies the list of CMS | |||
| algorithm identifiers that are supported by the client in order | algorithm identifiers that are supported by the client in order | |||
| of (decreasing) preference, and can be used to identify a | of (decreasing) preference, and can be used to identify a | |||
| signature algorithm or a public key encryption algorithm in the | signature algorithm or a key transport algorithm [RFC3370] in the | |||
| keyEncryptionAlgorithm field of the type KeyTransRecipientInfo or | keyEncryptionAlgorithm field of the type KeyTransRecipientInfo or | |||
| a bulk encryption algorithm in the contentEncryptionAlgorithm | a content encryption algorithm [RFC3370] in the | |||
| field of the type EncryptedContentInfo [RFC3852] when encrypting | contentEncryptionAlgorithm field of the type EncryptedContentInfo | |||
| the AS reply key as described in Section 3.2.3.2. However, there | [RFC3852] when encrypting the AS reply key as described in | |||
| is no significance in the relative order between any two of | Section 3.2.3.2. However, there is no significance in the | |||
| different types of algorithms: public key encryption algorithms, | relative order between any two of different types of algorithms: | |||
| bulk encryption algorithms and signature algorithms. The | key transport algorithms, content encryption algorithms, and | |||
| clientDHNonce field is described later in this section. | signature algorithms. The clientDHNonce field is described later | |||
| in this section. | ||||
| 6. The ctime field in the PKAuthenticator structure contains the | 6. The ctime field in the PKAuthenticator structure contains the | |||
| current time on the client's host, and the cusec field contains | current time on the client's host, and the cusec field contains | |||
| the microsecond part of the client's timestamp. The ctime and | the microsecond part of the client's timestamp. The ctime and | |||
| cusec fields are used together to specify a reasonably accurate | cusec fields are used together to specify a reasonably accurate | |||
| timestamp [RFC4120]. The nonce field is chosen randomly. The | timestamp [RFC4120]. The nonce field is chosen randomly. The | |||
| paChecksum field MUST be present and it contains a SHA1 checksum | paChecksum field MUST be present and it contains a SHA1 checksum | |||
| that is performed over the KDC-REQ-BODY [RFC4120]. In order to | that is performed over the KDC-REQ-BODY [RFC4120]. In order to | |||
| ease future migration from the use of SHA1, the paChecksum field | ease future migration from the use of SHA1, the paChecksum field | |||
| is made optional syntactically: when the request is extended to | is made optional syntactically: when the request is extended to | |||
| skipping to change at page 20, line 52 ¶ | skipping to change at page 21, line 14 ¶ | |||
| -- field MUST also be omitted. | -- field MUST also be omitted. | |||
| ... | ... | |||
| } | } | |||
| The content of the AS-REP is otherwise unchanged from [RFC4120]. The | The content of the AS-REP is otherwise unchanged from [RFC4120]. The | |||
| KDC encrypts the reply as usual, but not with the client's long-term | KDC encrypts the reply as usual, but not with the client's long-term | |||
| key. Instead, it encrypts it with either a shared key derived from a | key. Instead, it encrypts it with either a shared key derived from a | |||
| Diffie-Hellman exchange, or a generated encryption key. The contents | Diffie-Hellman exchange, or a generated encryption key. The contents | |||
| of the PA-PK-AS-REP indicate which key delivery method is used. | of the PA-PK-AS-REP indicate which key delivery method is used. | |||
| If the client does not wish to use the Diffie-Hellman key delivery | ||||
| method (the clientPublicValue field is not present in the request) | ||||
| and the KDC does not support the public key encryption key delivery | ||||
| method, the KDC MUST return an error message with the code | ||||
| KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED. There is no | ||||
| accompanying e-data for this error message. | ||||
| In addition, the lifetime of the ticket returned by the KDC MUST NOT | In addition, the lifetime of the ticket returned by the KDC MUST NOT | |||
| exceed that of the client's public-private key pair. The ticket | exceed that of the client's public-private key pair. The ticket | |||
| lifetime, however, can be shorter than that of the client's public- | lifetime, however, can be shorter than that of the client's public- | |||
| private key pair. For the implementations of this specification, the | private key pair. For the implementations of this specification, the | |||
| lifetime of the client's public-private key pair is the validity | lifetime of the client's public-private key pair is the validity | |||
| period in X.509 certificates [RFC3280], unless configured otherwise. | period in X.509 certificates [RFC3280], unless configured otherwise. | |||
| 3.2.3.1. Using Diffie-Hellman Key Exchange | 3.2.3.1. Using Diffie-Hellman Key Exchange | |||
| In this case, the PA-PK-AS-REP contains a DHRepInfo structure. | In this case, the PA-PK-AS-REP contains a DHRepInfo structure. | |||
| skipping to change at page 32, line ? ¶ | skipping to change at page 31, line 35 ¶ | |||
| Algorithms", RFC 3370, August 2002. | Algorithms", RFC 3370, August 2002. | |||
| [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography | [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography | |||
| Standards (PKCS) #1: RSA Cryptography Specifications | Standards (PKCS) #1: RSA Cryptography Specifications | |||
| Version 2.1", RFC 3447, February 2003. | Version 2.1", RFC 3447, February 2003. | |||
| [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) | [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) | |||
| Diffie-Hellman groups for Internet Key Exchange (IKE)", | Diffie-Hellman groups for Internet Key Exchange (IKE)", | |||
| RFC 3526, May 2003. | RFC 3526, May 2003. | |||
| [RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport | ||||
| Algorithm in Cryptographic Message Syntax (CMS)", | ||||
| RFC 3560, July 2003. | ||||
| [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) | [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) | |||
| Encryption Algorithm in Cryptographic Message Syntax | Encryption Algorithm in Cryptographic Message Syntax | |||
| (CMS)", RFC 3565, July 2003. | (CMS)", RFC 3565, July 2003. | |||
| [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For | [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For | |||
| Public Keys Used For Exchanging Symmetric Keys", BCP 86, | Public Keys Used For Exchanging Symmetric Keys", BCP 86, | |||
| RFC 3766, April 2004. | RFC 3766, April 2004. | |||
| [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", | [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", | |||
| RFC 3852, July 2004. | RFC 3852, July 2004. | |||
| skipping to change at page 34, line 31 ¶ | skipping to change at page 35, line 4 ¶ | |||
| -- referenced, this key identifier matches the X.509 | -- referenced, this key identifier matches the X.509 | |||
| -- subjectKeyIdentifier extension value. When other | -- subjectKeyIdentifier extension value. When other | |||
| -- certificate formats are referenced, the documents | -- certificate formats are referenced, the documents | |||
| -- that specify the certificate format and their use | -- that specify the certificate format and their use | |||
| -- with the CMS must include details on matching the | -- with the CMS must include details on matching the | |||
| -- key identifier to the appropriate certificate | -- key identifier to the appropriate certificate | |||
| -- field. | -- field. | |||
| -- RECOMMENDED for TD-TRUSTED-CERTIFIERS. | -- RECOMMENDED for TD-TRUSTED-CERTIFIERS. | |||
| ... | ... | |||
| } | } | |||
| AuthPack ::= SEQUENCE { | AuthPack ::= SEQUENCE { | |||
| pkAuthenticator [0] PKAuthenticator, | pkAuthenticator [0] PKAuthenticator, | |||
| clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, | clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, | |||
| -- Type SubjectPublicKeyInfo is defined in | -- Type SubjectPublicKeyInfo is defined in | |||
| -- [RFC3280]. | -- [RFC3280]. | |||
| -- Specifies Diffie-Hellman domain parameters | -- Specifies Diffie-Hellman domain parameters | |||
| -- and the client's public key value [IEEE1363]. | -- and the client's public key value [IEEE1363]. | |||
| -- The DH public key value is encoded as a BIT | -- The DH public key value is encoded as a BIT | |||
| -- STRING according to [RFC3279]. | -- STRING according to [RFC3279]. | |||
| -- This field is present only if the client wishes | -- This field is present only if the client wishes | |||
| -- to use the Diffie-Hellman key agreement method. | -- to use the Diffie-Hellman key agreement method. | |||
| supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier | supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier | |||
| OPTIONAL, | OPTIONAL, | |||
| -- Type AlgorithmIdentifier is defined in | -- Type AlgorithmIdentifier is defined in | |||
| -- [RFC3280]. | -- [RFC3280]. | |||
| -- List of CMS public key encryption algorithm | -- List of CMS algorithm [RFC3370] identifiers | |||
| -- identifiers, bulk encryption algorithm | -- that identify key transport algorithms, or | |||
| -- identifiers, or signature algorithm identifiers | -- content encryption algorithms, or signature | |||
| -- supported by the client in order of (decreasing) | -- algorithms supported by the client in order of | |||
| -- preference. | -- (decreasing) preference. | |||
| clientDHNonce [3] DHNonce OPTIONAL, | clientDHNonce [3] DHNonce OPTIONAL, | |||
| -- Present only if the client indicates that it | -- Present only if the client indicates that it | |||
| -- wishes to reuse DH keys or to allow the KDC to | -- wishes to reuse DH keys or to allow the KDC to | |||
| -- do so. | -- do so. | |||
| ... | ... | |||
| } | } | |||
| PKAuthenticator ::= SEQUENCE { | PKAuthenticator ::= SEQUENCE { | |||
| cusec [0] INTEGER (0..999999), | cusec [0] INTEGER (0..999999), | |||
| ctime [1] KerberosTime, | ctime [1] KerberosTime, | |||
| End of changes. 28 change blocks. | ||||
| 60 lines changed or deleted | 84 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||