< 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/