< draft-ietf-cat-kerberos-pk-init-32.txt   draft-ietf-cat-kerberos-pk-init-33.txt >
NETWORK WORKING GROUP L. Zhu NETWORK WORKING GROUP L. Zhu
Internet-Draft Microsoft Corporation Internet-Draft Microsoft Corporation
Expires: July 15, 2006 B. Tung Expires: July 28, 2006 B. Tung
USC Information Sciences Institute USC Information Sciences Institute
January 11, 2006 January 24, 2006
Public Key Cryptography for Initial Authentication in Kerberos Public Key Cryptography for Initial Authentication in Kerberos
draft-ietf-cat-kerberos-pk-init-32 draft-ietf-cat-kerberos-pk-init-33
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 15, 2006. This Internet-Draft will expire on July 28, 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 . . . . . . . . . 6 3.1.2. Defined Message and Encryption Types . . . . . . . . . 7
3.1.3. Algorithm Identifiers . . . . . . . . . . . . . . . . 7 3.1.3. Kerberos Encryption Types Defined for CMS
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 . . . . . . . . . . . . . . 13 3.2.2. Receipt of Client Request . . . . . . . . . . . . . . 14
3.2.3. Generation of KDC Reply . . . . . . . . . . . . . . . 17 3.2.3. Generation of KDC Reply . . . . . . . . . . . . . . . 18
3.2.4. Receipt of KDC Reply . . . . . . . . . . . . . . . . . 24 3.2.4. Receipt of KDC Reply . . . . . . . . . . . . . . . . . 25
3.3. Interoperability Requirements . . . . . . . . . . . . . . 25 3.3. Interoperability Requirements . . . . . . . . . . . . . . 26
3.4. KDC Indication of PKINIT Support . . . . . . . . . . . . . 26 3.4. KDC Indication of PKINIT Support . . . . . . . . . . . . . 26
4. Security Considerations . . . . . . . . . . . . . . . . . . . 26 4. Security Considerations . . . . . . . . . . . . . . . . . . . 27
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1. Normative References . . . . . . . . . . . . . . . . . . . 29 7.1. Normative References . . . . . . . . . . . . . . . . . . . 30
7.2. Informative References . . . . . . . . . . . . . . . . . . 31 7.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 31 Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 32
Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 36 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 37
Appendix C. Miscellaneous Information about Microsoft Windows Appendix C. Miscellaneous Information about Microsoft Windows
PKINIT Implementations . . . . . . . . . . . . . . . 38 PKINIT Implementations . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . . . . 41 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.
The corner-stone of Kerberos V5 is the Ticket and the Authenticator. The corner-stone of Kerberos V5 is the Ticket and the Authenticator.
A Ticket encapsulates a symmetric key (the ticket session key) in an A Ticket encapsulates a symmetric key (the ticket session key) in an
skipping to change at page 4, line 38 skipping to change at page 4, line 38
+---------------+ AP-REP +-----------------+ +---------------+ AP-REP +-----------------+
In the AS exchange, the KDC reply contains the ticket session key, In the AS exchange, the KDC reply contains the ticket session key,
amongst other items, that is encrypted using a key (the AS reply key) amongst other items, that is encrypted using a key (the AS reply key)
shared between the client and the KDC. The AS reply key is typically shared between the client and the KDC. The AS reply key is typically
derived from the client's password for human users. Therefore for derived from the client's password for human users. Therefore for
human users the attack resistance strength of the Kerberos protocol human users the attack resistance strength of the Kerberos protocol
is no stronger than the strength of their passwords. is no stronger than the strength of their passwords.
The use of asymmetric cryptography in the form of X.509 certificates The use of asymmetric cryptography in the form of X.509 certificates
[RFC3280] is popular for facilitating non-repudiation and perfect [RFC3280] is popular for facilitating data origin authentication and
secrecy. An established Public Key Infrastructure (PKI) provides key perfect secrecy. An established Public Key Infrastructure (PKI)
management and key distribution mechanisms that can be used to provides key management and key distribution mechanisms that can be
establish authentication and secure communication. Adding public-key used to establish authentication and secure communication. Adding
cryptography to Kerberos provides a nice congruence to public-key public-key cryptography to Kerberos provides a nice congruence to
protocols, obviates the human users' burden to manage strong public-key protocols, obviates the human users' burden to manage
passwords, and allows Kerberized applications to take advantage of strong passwords, and allows Kerberized applications to take
existing key services and identity management. advantage of existing key services and identity management.
The advantage afforded by the Kerberos TGT is that the client exposes The advantage afforded by the Kerberos TGT is that the client exposes
his long-term secrets only once. The TGT and its associated session his long-term secrets only once. The TGT and its associated session
key can then be used for any subsequent service ticket requests. One key can then be used for any subsequent service ticket requests. One
result of this is that all further authentication is independent of result of this is that all further authentication is independent of
the method by which the initial authentication was performed. the method by which the initial authentication was performed.
Consequently, initial authentication provides a convenient place to Consequently, initial authentication provides a convenient place to
integrate public-key cryptography into Kerberos authentication. In integrate public-key cryptography into Kerberos authentication. In
addition, the use of symmetric cryptography after the initial addition, the use of symmetric cryptography after the initial
exchange is preferred for performance. exchange is preferred for performance.
skipping to change at page 6, line 43 skipping to change at page 6, line 43
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: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-
sha1-96 [RFC3962]. sha1-96 [RFC3962].
o Signature algorithm: sha-1WithRSAEncryption [RFC3279]. o Signature algorithm: sha-1WithRSAEncryption [RFC3279].
o AS reply key delivery method: Diffie-Hellman key exchange o AS reply key delivery method: Diffie-Hellman key exchange
[RFC2631]. [RFC2631].
o Algorithms identified in the contentEncryptionAlgorithm field of
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
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].
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], if Alternative Name (SAN) extension in X.509 certificates [RFC3280].
present.
3.1.2. Defined Message and Encryption Types 3.1.2. 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:
skipping to change at page 7, line 44 skipping to change at page 8, line 7
IMPORT statements for all imported structures) is given in IMPORT statements for all imported structures) is given in
Appendix A. Appendix A.
All structures defined in or imported into this document MUST be All structures defined in or imported into this document MUST be
encoded using Distinguished Encoding Rules (DER) [X680] [X690] encoded using Distinguished Encoding Rules (DER) [X680] [X690]
(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 CMS objects encoded with BER; specifically, they may not be wrapped Cryptographic Message Syntax (CMS) [RFC3852] objects encoded
able to decode indefinite length encodings. To maximize with BER; specifically, they may not be able to decode indefinite
interoperability, implementers SHOULD encode CMS objects used in length encodings. To maximize interoperability, implementers SHOULD
PKINIT with DER. encode CMS objects used in PKINIT with DER.
3.1.3. Algorithm Identifiers
PKINIT does not define, but does make use of, the following algorithm
identifiers.
PKINIT uses the following algorithm identifier(s) for Modular
Exponential Diffie-Hellman key agreement [RFC2631] [RFC3279]:
dhpublicnumber (as described in [RFC3279])
PKINIT uses the following signature algorithm identifiers as defined 3.1.3. Kerberos Encryption Types Defined for CMS Algorithm Identifiers
in [RFC3279]:
sha-1WithRSAEncryption (RSA with SHA1) PKINIT defines the following Kerberos encryption type numbers
md5WithRSAEncryption (RSA with MD5) [RFC3961], which can be used in the etype field of the AS-REQ
id-dsa-with-sha1 (DSA with SHA1) [RFC4120] message to indicate to the KDC the client's acceptance of
the corresponding algorithms (including public encryption algorithms,
bulk encryption algorithms, and signature algorithms) for use with
Cryptographic Message Syntax (CMS) [RFC3852].
PKINIT uses the following encryption algorithm identifiers as defined Per [RFC4120], the encryption types in the etype field are in the
in [RFC3447] for encrypting the temporary key with a public key: decreasing preference order of the client. Note that there is no
significance in the relative order between any two of different types
of algorithms: public key encryption algorithms, bulk encryption
algorithms and signature algorithms.
rsaEncryption The presence of each of these encryption types in the etype field is
id-RSAES-OAEP equivalent to the presence of the corresponding algorithm Object
Identifier (OID) in the supportedCMSTypes field as described in
Section 3.2.1. And the preference order expressed in the
supportedCMSTypes field would override the preference order listed in
the etype field.
PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565] Kerberos Encryption Type Name Num Corresponding Algorithm OID
for encrypting the AS reply key with the temporary key: ============================== === ===============================
id-dsa-with-sha1-CmsOID 9 id-dsa-with-sha1 [RFC3279]
md5WithRSAEncryption-CmsOID 10 md5WithRSAEncryption [RFC3279]
sha-1WithRSAEncryption-CmsOID 11 sha-1WithRSAEncryption [RFC3279]
rc2-cbc-EnvOID 12 rc2-cbc [RFC3370]
rsaEncryption-EnvOID 13 rsaEncryption [RFC3447][RFC3279]
id-RSAES-OAEP-EnvOID 14 id-RSAES-OAEP [RFC3447][RFC3279]
des-ede3-cbc-EnvOID 15 des-ede3-cbc [RFC3370]
des-ede3-cbc (three-key 3DES, CBC mode, as defined in [RFC3370]) The above encryption type numbers are used only to indicate support
rc2-cbc (RC2, CBC mode, as defined in [RFC3370]) for the use of the corresponding algorithms in PKINIT; they do not
id-aes256-CBC (AES-256, CBC mode, as defined in [RFC3565]) correspond to actual Kerberos encryption types [RFC3961] and MUST NOT
be used in the etype field of the Kerberos EncryptedData type
[RFC4120]. The practice of assigning Kerberos encryption type
numbers to indicate support for CMS algorithms is considered
deprecated, and new numbers should not be assigned for this purpose.
PKINIT defines the following encryption types, for use in the etype Instead, the supportedCMSTypes field should be used to identify the
field of the AS-REQ [RFC4120] message to indicate acceptance of the algorithms supported by the client and the preference order of the
corresponding algorithms that can used by Cryptographic Message client.
Syntax (CMS) [RFC3852] messages in the reply:
id-dsa-with-sha1-CmsOID 9 For maximum interoperability, however, PKINIT clients wishing to
-- Indicates that the client supports id-dsa-with-sha1. indicate to the KDC the support for one or more of the algorithms
md5WithRSAEncryption-CmsOID 10 listed above SHOULD include the corresponding encryption type
-- Indicates that the client supports md5WithRSAEncryption. number(s) in the etype field of the AS-REQ.
sha-1WithRSAEncryption-CmsOID 11
-- Indicates that the client supports sha-1WithRSAEncryption.
rc2-cbc-EnvOID 12
-- Indicates that the client supports rc2-cbc.
rsaEncryption-EnvOID 13
-- Indicates that the client supports rsaEncryption.
id-RSAES-OAEP-EnvOID 14
-- Indicates that the client supports id-RSAES-OAEP.
des-ede3-cbc-EnvOID 15
-- Indicates that the client supports des-ede3-cbc.
3.2. PKINIT Pre-authentication Syntax and Use 3.2. PKINIT Pre-authentication Syntax and Use
This section defines the syntax and use of the various pre- This section defines the syntax and use of the various pre-
authentication fields employed by PKINIT. authentication fields employed by PKINIT.
3.2.1. Generation of Client Request 3.2.1. Generation of Client Request
The initial authentication request (AS-REQ) is sent as per [RFC4120]; The initial authentication request (AS-REQ) is sent as per [RFC4120];
in addition, a pre-authentication data element, whose padata-type is in addition, a pre-authentication data element, whose padata-type is
skipping to change at page 10, line 44 skipping to change at page 11, line 5
-- 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 encryption types supported by the -- List of CMS public key encryption algorithm
-- client in order of (decreasing) preference. -- identifiers, bulk encryption algorithm
-- identifiers, or signature algorithm identifiers
-- supported by the client in order of (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,
-- cusec and ctime are used as in [RFC4120], for -- cusec and ctime are used as in [RFC4120], for
-- replay prevention. -- replay prevention.
nonce [2] INTEGER (0..4294967295), nonce [2] INTEGER (0..4294967295),
-- Chosen randomly; This nonce does not need to -- Chosen randomly; This nonce does not need to
-- match with the nonce in the KDC-REQ-BODY. -- match with the nonce in the KDC-REQ-BODY.
paChecksum [3] OCTET STRING OPTIONAL, paChecksum [3] OCTET STRING OPTIONAL,
-- MUST be present. -- MUST be present.
skipping to change at page 11, line 50 skipping to change at page 12, line 18
5. The AuthPack structure contains a PKAuthenticator, the client 5. The AuthPack structure contains a PKAuthenticator, the client
public key information, the CMS encryption types supported by the public key information, the CMS encryption types supported by the
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
encryption types supported by the client in order of (decreasing) algorithm identifiers that are supported by the client in order
preference. The clientDHNonce field is described later in this of (decreasing) preference, and can be used to identify a
section. signature algorithm or a public key encryption algorithm in the
keyEncryptionAlgorithm field of the type KeyTransRecipientInfo or
a bulk encryption algorithm in the contentEncryptionAlgorithm
field of the type EncryptedContentInfo [RFC3852] when encrypting
the AS reply key as described in Section 3.2.3.2. However, there
is no significance in the relative order between any two of
different types of algorithms: public key encryption algorithms,
bulk encryption algorithms and 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 16, line 5 skipping to change at page 16, line 32
x509SanAN (2) } x509SanAN (2) }
And the value field of the type AnotherName is a And the value field of the type AnotherName is a
KRB5PrincipalName. KRB5PrincipalName.
KRB5PrincipalName ::= SEQUENCE { KRB5PrincipalName ::= SEQUENCE {
realm [0] Realm, realm [0] Realm,
principalName [1] PrincipalName principalName [1] PrincipalName
} }
If the KDC does not have its own binding and there is no If the Kerberos client name in the AS-REQ does not match a name bound
KRB5PrincipalName name present in the client's X.509 certificate, or by the KDC (the binding can be in the certificate, for example as
if the Kerberos name in the request does not match the described above), or if there is no binding found by the KDC, the KDC
KRB5PrincipalName in the client's X.509 certificate (including the MUST return an error message with the code
realm name), the KDC MUST return an error message with the code
KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for
this error message. this error message.
Even if the certification path is validated and the certificate is Even if the certification path is validated and the certificate is
mapped to the client's principal name, the KDC may decide not to mapped to the client's principal name, the KDC may decide not to
accept the client's certificate, depending on local policy. accept the client's certificate, depending on local policy.
The KDC MAY require the presence of an Extended Key Usage (EKU) The KDC MAY require the presence of an Extended Key Usage (EKU)
KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field
of the client's X.509 certificate: of the client's X.509 certificate:
skipping to change at page 18, line 27 skipping to change at page 19, line 6
-- the client certificate was validated. -- the client certificate was validated.
-- Each ExternalPrincipalIdentifier identifies a CA -- Each ExternalPrincipalIdentifier identifies a CA
-- or a CA certificate (thereby its public key). -- or a CA certificate (thereby its public key).
The AD-INITIAL-VERIFIED-CAS structure identifies the certification The AD-INITIAL-VERIFIED-CAS structure identifies the certification
path based on which the client certificate was validated. Each path based on which the client certificate was validated. Each
ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the AD- ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the AD-
INITIAL-VERIFIED-CAS structure identifies a CA or a CA certificate INITIAL-VERIFIED-CAS structure identifies a CA or a CA certificate
(thereby its public key). (thereby its public key).
Note that the syntax for the AD-INITIAL-VERIFIED-CAS authorization
data does permit empty SEQUENCEs to be encoded. Such empty sequences
may only be used if the KDC itself vouches for the user's
certificate.
The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
containers if the list of CAs satisfies the AS' realm's local policy containers if the list of CAs satisfies the AS' realm's local policy
(this corresponds to the TRANSITED-POLICY-CHECKED ticket flag (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
[RFC4120]). Furthermore, any TGS MUST copy such authorization data [RFC4120]). Furthermore, any TGS MUST copy such authorization data
from tickets used within a PA-TGS-REQ of the TGS-REQ into the from tickets used within a PA-TGS-REQ of the TGS-REQ into the
resulting ticket. If the list of CAs satisfies the local KDC's resulting ticket. If the list of CAs satisfies the local KDC's
realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT
container, otherwise it MAY unwrap the authorization data out of the container, otherwise it MAY unwrap the authorization data out of the
AD-IF-RELEVANT container. AD-IF-RELEVANT container.
skipping to change at page 25, line 39 skipping to change at page 26, line 25
with the id-pkinit-KPKdc EKU. with the id-pkinit-KPKdc EKU.
If the KDC certificate contains the Kerberos TGS name encoded as an If the KDC certificate contains the Kerberos TGS name encoded as an
id-pkinit-san SAN, this certificate is certified by the issuing CA as id-pkinit-san SAN, this certificate is certified by the issuing CA as
a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required. a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required.
If all applicable checks are satisfied, the client then decrypts the If all applicable checks are satisfied, the client then decrypts the
enc-part field of the KDC-REP in the AS-REP using the AS reply key, enc-part field of the KDC-REP in the AS-REP using the AS reply key,
and then proceeds as described in [RFC4120]. and then proceeds as described in [RFC4120].
Implementation note: CAs issuing KDC certificates SHOULD place all
"short" and "fully-qualified" Kerberos realm names of the KDC (one
per GeneralName [RFC3280]) into the KDC certificate to allow maximum
flexibility.
3.3. Interoperability Requirements 3.3. Interoperability Requirements
The client MUST be capable of sending a set of certificates The client MUST be capable of sending a set of certificates
sufficient to allow the KDC to construct a certification path for the sufficient to allow the KDC to construct a certification path for the
client's certificate, if the correct set of certificates is provided client's certificate, if the correct set of certificates is provided
through configuration or policy. through configuration or policy.
If the client sends all the X.509 certificates on a certification If the client sends all the X.509 certificates on a certification
path to a trust anchor acceptable by the KDC, and the KDC can not path to a trust anchor acceptable by the KDC, and the KDC can not
verify the client's public key otherwise, the KDC MUST be able to verify the client's public key otherwise, the KDC MUST be able to
skipping to change at page 26, line 43 skipping to change at page 27, line 25
KDC_ERR_PREAUTH_FAILED SHOULD be returned. KDC_ERR_PREAUTH_FAILED SHOULD be returned.
KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
STRING), and clients MUST ignore this and any other value. Future STRING), and clients MUST ignore this and any other value. Future
extensions to this protocol may specify other data to send instead of extensions to this protocol may specify other data to send instead of
an empty OCTET STRING. an empty OCTET STRING.
4. Security Considerations 4. Security Considerations
The security of cryptographic algorithms is dependent on generating
secret quantities [RFC4086]. The number of truly random bits is
extremely important to determining the attack resistance strength of
the cryptosystem, for example, the secret Diffie-Hellman exponents
must be chosen based on n truly random bits (where n is the system
security requirement). The security of the overall system is
significantly weakened by using insufficient random inputs: a
sophisticated attacker may find it easier to reproduce the
environment that produced the secret quantities and to search the
resulting small set of possibilities than to locate the quantities in
the whole of the potential number space.
Kerberos error messages are not integrity protected, as a result, the Kerberos error messages are not integrity protected, as a result, the
domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered
with by an attacker so that the set of domain parameters selected with by an attacker so that the set of domain parameters selected
could be either weaker or not mutually preferred. Local policy can could be either weaker or not mutually preferred. Local policy can
configure sets of domain parameters acceptable locally, or disallow configure sets of domain parameters acceptable locally, or disallow
the negotiation of DH domain parameters. the negotiation of DH domain parameters.
The symmetric reply key size and Diffie-Hellman field size or RSA The symmetric reply key size and Diffie-Hellman field size or RSA
modulus size should be chosen so as to provide sufficient modulus size should be chosen so as to provide sufficient
cryptographic security [RFC3766]. cryptographic security [RFC3766].
skipping to change at page 27, line 48 skipping to change at page 28, line 42
certificates contain the id-pkinit-KPKdc EKU or that the realm be certificates contain the id-pkinit-KPKdc EKU or that the realm be
specified with the id-pkinit-san SAN. specified with the id-pkinit-san SAN.
It is the responsibility of the PKI administrators for an It is the responsibility of the PKI administrators for an
organization to ensure that KDC certificates are only issued to KDCs, organization to ensure that KDC certificates are only issued to KDCs,
and that clients can ascertain this using their local policy. and that clients can ascertain this using their local policy.
Standard Kerberos allows the possibility of interactions between Standard Kerberos allows the possibility of interactions between
cryptosystems of varying strengths; this document adds interactions cryptosystems of varying strengths; this document adds interactions
with public-key cryptosystems to Kerberos. Some administrative with public-key cryptosystems to Kerberos. Some administrative
policies may allow the use of relatively weak public keys. Using policies may allow the use of relatively weak public keys. When
such keys to wrap data encrypted under stronger conventional using such weak asymmetric keys to protect/exchange stronger
cryptosystems may be inappropriate. symmetric Keys, the attack resistant strength of the overall system
is no better than that of these weak keys [RFC3766].
PKINIT requires keys for symmetric cryptosystems to be generated. PKINIT requires keys for symmetric cryptosystems to be generated.
Some such systems contain "weak" keys. For recommendations regarding Some such systems contain "weak" keys. For recommendations regarding
these weak keys, see [RFC4120]. these weak keys, see [RFC4120].
PKINIT allows the use of the same RSA key pair for encryption and PKINIT allows the use of the same RSA key pair for encryption and
signing when doing RSA encryption based key delivery. This is not signing when doing RSA encryption based key delivery. This is not
recommended usage of RSA keys [RFC3447], by using DH based key recommended usage of RSA keys [RFC3447], by using DH based key
delivery this is avoided. delivery this is avoided.
skipping to change at page 28, line 31 skipping to change at page 29, line 24
PKINIT does not provide for a "return routability" test to prevent PKINIT does not provide for a "return routability" test to prevent
attackers from mounting a denial-of-service attack on the KDC by attackers from mounting a denial-of-service attack on the KDC by
causing it to perform unnecessary and expensive public-key causing it to perform unnecessary and expensive public-key
operations. Strictly speaking, this is also true of standard operations. Strictly speaking, this is also true of standard
Kerberos, although the potential cost is not as great, because Kerberos, although the potential cost is not as great, because
standard Kerberos does not make use of public-key cryptography. By standard Kerberos does not make use of public-key cryptography. By
using DH based key delivery and reusing DH keys, the necessary crypto using DH based key delivery and reusing DH keys, the necessary crypto
processing cost per request can be minimized. processing cost per request can be minimized.
The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
permit empty SEQUENCEs to be encoded. Such empty sequences may only
be used if the KDC itself vouches for the user's certificate.
When the Diffie-Hellman key exchange method is used, additional pre- When the Diffie-Hellman key exchange method is used, additional pre-
authentication data [RFC4120] (in addition to the PA_PK_AS_REQ as authentication data [RFC4120] (in addition to the PA_PK_AS_REQ as
defined in this specification) is not bound to the AS_REQ by the defined in this specification) is not bound to the AS_REQ by the
mechanisms discussed in this specification (meaning it may be dropped mechanisms discussed in this specification (meaning it may be dropped
or added by attackers without being detected by either the client or or added by attackers without being detected by either the client or
the KDC). Designers of additional pre-authentication data should the KDC). Designers of additional pre-authentication data should
take that into consideration if such additional pre-authentication take that into consideration if such additional pre-authentication
data can be used in conjunction with the PA_PK_AS_REQ. The future data can be used in conjunction with the PA_PK_AS_REQ. The future
work of the Kerberos working group is expected to update the hash work of the Kerberos working group is expected to update the hash
algorithms specified in this document and provide a generic mechanism algorithms specified in this document and provide a generic mechanism
skipping to change at page 30, line 44 skipping to change at page 32, line ?
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, July 2004. RFC 3852, July 2004.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, February 2005. Kerberos 5", RFC 3961, February 2005.
[RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES)
Encryption for Kerberos 5", RFC 3962, February 2005. Encryption for Kerberos 5", RFC 3962, February 2005.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120, Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005. July 2005.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism: Version 2", RFC 4121,
July 2005.
[X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, [X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
Information technology - Abstract Syntax Notation One Information technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation. (ASN.1): Specification of basic notation.
[X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, [X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
Information technology - ASN.1 encoding Rules: Specification Information technology - ASN.1 encoding Rules: Specification
of Basic Encoding Rules (BER), Canonical Encoding Rules of Basic Encoding Rules (BER), Canonical Encoding Rules
(CER) and Distinguished Encoding Rules (DER). (CER) and Distinguished Encoding Rules (DER).
7.2. Informative References 7.2. Informative References
[LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key [LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
Sizes", Journal of Cryptology 14 (2001) 255-293. Sizes", Journal of Cryptology 14 (2001) 255-293.
[ODL99] Odlyzko, A., "Discrete logarithms: The past and the [ODL99] Odlyzko, A., "Discrete logarithms: The past and the
future, Designs, Codes, and Cryptography (1999)". future, Designs, Codes, and Cryptography (1999)".
April 1999.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism: Version 2", RFC 4121,
July 2005.
[RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
Nicholas, "Internet X.509 Public Key Infrastructure: Nicholas, "Internet X.509 Public Key Infrastructure:
Certification Path Building", RFC 4158, September 2005. Certification Path Building", RFC 4158, September 2005.
Appendix A. PKINIT ASN.1 Module Appendix A. PKINIT ASN.1 Module
KerberosV5-PK-INIT-SPEC { KerberosV5-PK-INIT-SPEC {
iso(1) identified-organization(3) dod(6) internet(1) iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2) modules(4) pkinit(5) security(5) kerberosV5(2) modules(4) pkinit(5)
skipping to change at page 33, line 52 skipping to change at page 34, line 47
-- 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 encryption types supported by the -- List of CMS public key encryption algorithm
-- client in order of (decreasing) preference. -- identifiers, bulk encryption algorithm
-- identifiers, or signature algorithm identifiers
-- supported by the client in order of (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. 33 change blocks. 
106 lines changed or deleted 146 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/