mirror of
https://github.com/samba-team/samba.git
synced 2024-12-23 17:34:34 +03:00
7055827b8f
This makes it clearer that we always want to do heimdal changes via the lorikeet-heimdal repository. Signed-off-by: Stefan Metzmacher <metze@samba.org> Reviewed-by: Joseph Sutton <josephsutton@catalyst.net.nz> Autobuild-User(master): Joseph Sutton <jsutton@samba.org> Autobuild-Date(master): Wed Jan 19 21:41:59 UTC 2022 on sn-devel-184
2184 lines
90 KiB
Plaintext
2184 lines
90 KiB
Plaintext
NETWORK WORKING GROUP L. Zhu
|
||
Internet-Draft Microsoft Corporation
|
||
Expires: June 2, 2006 B. Tung
|
||
USC Information Sciences Institute
|
||
November 29, 2005
|
||
|
||
|
||
Public Key Cryptography for Initial Authentication in Kerberos
|
||
draft-ietf-cat-kerberos-pk-init-30
|
||
|
||
Status of this Memo
|
||
|
||
By submitting this Internet-Draft, each author represents that any
|
||
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
|
||
aware will be disclosed, in accordance with Section 6 of BCP 79.
|
||
|
||
Internet-Drafts are working documents of the Internet Engineering
|
||
Task Force (IETF), its areas, and its working groups. Note that
|
||
other groups may also distribute working documents as Internet-
|
||
Drafts.
|
||
|
||
Internet-Drafts are draft documents valid for a maximum of six months
|
||
and may be updated, replaced, or obsoleted by other documents at any
|
||
time. It is inappropriate to use Internet-Drafts as reference
|
||
material or to cite them other than as "work in progress."
|
||
|
||
The list of current Internet-Drafts can be accessed at
|
||
http://www.ietf.org/ietf/1id-abstracts.txt.
|
||
|
||
The list of Internet-Draft Shadow Directories can be accessed at
|
||
http://www.ietf.org/shadow.html.
|
||
|
||
This Internet-Draft will expire on June 2, 2006.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (2005).
|
||
|
||
Abstract
|
||
|
||
This document describes protocol extensions (hereafter called PKINIT)
|
||
to the Kerberos protocol specification. These extensions provide a
|
||
method for integrating public key cryptography into the initial
|
||
authentication exchange, by using asymmetric-key signature and/or
|
||
encryption algorithms in pre-authentication data fields.
|
||
|
||
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 1]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
Table of Contents
|
||
|
||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
|
||
3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||
3.1. Definitions, Requirements, and Constants . . . . . . . . . 5
|
||
3.1.1. Required Algorithms . . . . . . . . . . . . . . . . . 5
|
||
3.1.2. Defined Message and Encryption Types . . . . . . . . . 5
|
||
3.1.3. Algorithm Identifiers . . . . . . . . . . . . . . . . 6
|
||
3.2. PKINIT Pre-authentication Syntax and Use . . . . . . . . . 7
|
||
3.2.1. Generation of Client Request . . . . . . . . . . . . . 7
|
||
3.2.2. Receipt of Client Request . . . . . . . . . . . . . . 12
|
||
3.2.3. Generation of KDC Reply . . . . . . . . . . . . . . . 16
|
||
3.2.4. Receipt of KDC Reply . . . . . . . . . . . . . . . . . 22
|
||
3.3. Interoperability Requirements . . . . . . . . . . . . . . 24
|
||
3.4. KDC Indication of PKINIT Support . . . . . . . . . . . . . 24
|
||
4. Security Considerations . . . . . . . . . . . . . . . . . . . 25
|
||
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
|
||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
|
||
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
|
||
7.1. Normative References . . . . . . . . . . . . . . . . . . . 28
|
||
7.2. Informative References . . . . . . . . . . . . . . . . . . 29
|
||
Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 29
|
||
Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 35
|
||
Appendix C. Miscellaneous Information about Microsoft Windows
|
||
PKINIT Implementations . . . . . . . . . . . . . . . 36
|
||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
|
||
Intellectual Property and Copyright Statements . . . . . . . . . . 39
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 2]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
1. Introduction
|
||
|
||
A client typically authenticates itself to a service in Kerberos
|
||
using three distinct though related exchanges. First, the client
|
||
requests a ticket-granting ticket (TGT) from the Kerberos
|
||
authentication server (AS). Then, it uses the TGT to request a
|
||
service ticket from the Kerberos ticket-granting server (TGS).
|
||
Usually, the AS and TGS are integrated in a single device known as a
|
||
Kerberos Key Distribution Center, or KDC. Finally, the client uses
|
||
the service ticket to authenticate itself to the service.
|
||
|
||
The advantage afforded by the TGT is that the client exposes his
|
||
long-term secrets only once. The TGT and its associated session key
|
||
can then be used for any subsequent service ticket requests. One
|
||
result of this is that all further authentication is independent of
|
||
the method by which the initial authentication was performed.
|
||
Consequently, initial authentication provides a convenient place to
|
||
integrate public-key cryptography into Kerberos authentication.
|
||
|
||
As defined in [RFC4120], Kerberos authentication exchanges use
|
||
symmetric-key cryptography, in part for performance. One
|
||
disadvantage of using symmetric-key cryptography is that the keys
|
||
must be shared, so that before a client can authenticate itself, he
|
||
must already be registered with the KDC.
|
||
|
||
Conversely, public-key cryptography (in conjunction with an
|
||
established Public Key Infrastructure) permits authentication without
|
||
prior registration with a KDC. Adding it to Kerberos allows the
|
||
widespread use of Kerberized applications by clients without
|
||
requiring them to register first with a KDC--a requirement that has
|
||
no inherent security benefit.
|
||
|
||
As noted above, a convenient and efficient place to introduce public-
|
||
key cryptography into Kerberos is in the initial authentication
|
||
exchange. This document describes the methods and data formats for
|
||
integrating public-key cryptography into Kerberos initial
|
||
authentication.
|
||
|
||
|
||
2. Conventions Used in This Document
|
||
|
||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||
document are to be interpreted as described in [RFC2119].
|
||
|
||
Both the AS and the TGS are referred to as the KDC.
|
||
|
||
In this document, the encryption key used to encrypt the enc-part
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 3]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
field of the KDC-REP in the AS-REP [RFC4120] is referred to as the AS
|
||
reply key.
|
||
|
||
In this document, an empty sequence in an optional field can be
|
||
either included or omitted: both encodings are permitted and
|
||
considered equivalent.
|
||
|
||
In this document, the term "Modular Exponential Diffie-Hellman" is
|
||
used to refer to the Diffie-Hellman key exchange as described in
|
||
[RFC2631], in order to differentiate it from other equivalent
|
||
representations of the same key agreement algorithm.
|
||
|
||
|
||
3. Extensions
|
||
|
||
This section describes extensions to [RFC4120] for supporting the use
|
||
of public-key cryptography in the initial request for a ticket.
|
||
|
||
Briefly, this document defines the following extensions to [RFC4120]:
|
||
|
||
1. The client indicates the use of public-key authentication by
|
||
including a special preauthenticator in the initial request. This
|
||
preauthenticator contains the client's public-key data and a
|
||
signature.
|
||
|
||
2. The KDC tests the client's request against its authentication
|
||
policy and trusted Certification Authorities (CAs).
|
||
|
||
3. If the request passes the verification tests, the KDC replies as
|
||
usual, but the reply is encrypted using either:
|
||
|
||
a. a key generated through a Diffie-Hellman (DH) key exchange
|
||
[RFC2631] [IEEE1363] with the client, signed using the KDC's
|
||
signature key; or
|
||
|
||
b. a symmetric encryption key, signed using the KDC's signature
|
||
key and encrypted using the client's public key.
|
||
|
||
Any keying material required by the client to obtain the
|
||
encryption key for decrypting the KDC reply is returned in a pre-
|
||
authentication field accompanying the usual reply.
|
||
|
||
4. The client validates the KDC's signature, obtains the encryption
|
||
key, decrypts the reply, and then proceeds as usual.
|
||
|
||
Section 3.1 of this document enumerates the required algorithms and
|
||
necessary extension message types. Section 3.2 describes the
|
||
extension messages in greater detail.
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 4]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
3.1. Definitions, Requirements, and Constants
|
||
|
||
3.1.1. Required Algorithms
|
||
|
||
All PKINIT implementations MUST support the following algorithms:
|
||
|
||
o AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-
|
||
sha1-96 [RFC3962].
|
||
|
||
o Signature algorithm: sha-1WithRSAEncryption [RFC3279].
|
||
|
||
o AS reply key delivery method: Diffie-Hellman key exchange
|
||
[RFC2631].
|
||
|
||
In addition, implementations of this specification MUST be capable of
|
||
processing the Extended Key Usage (EKU) extension and the id-pkinit-
|
||
san (as defined in Section 3.2.2) otherName of the Subject
|
||
Alternative Name (SAN) extension in X.509 certificates [RFC3280], if
|
||
present.
|
||
|
||
3.1.2. Defined Message and Encryption Types
|
||
|
||
PKINIT makes use of the following new pre-authentication types:
|
||
|
||
PA_PK_AS_REQ 16
|
||
PA_PK_AS_REP 17
|
||
|
||
PKINIT also makes use of the following new authorization data type:
|
||
|
||
AD_INITIAL_VERIFIED_CAS 9
|
||
|
||
PKINIT introduces the following new error codes:
|
||
|
||
KDC_ERR_CLIENT_NOT_TRUSTED 62
|
||
KDC_ERR_INVALID_SIG 64
|
||
KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65
|
||
KDC_ERR_CANT_VERIFY_CERTIFICATE 70
|
||
KDC_ERR_INVALID_CERTIFICATE 71
|
||
KDC_ERR_REVOKED_CERTIFICATE 72
|
||
KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
|
||
KDC_ERR_CLIENT_NAME_MISMATCH 75
|
||
KDC_ERR_INCONSISTENT_KEY_PURPOSE 76
|
||
KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED 77
|
||
KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED 78
|
||
KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED 79
|
||
|
||
PKINIT uses the following typed data types for errors:
|
||
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 5]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
TD_TRUSTED_CERTIFIERS 104
|
||
TD_INVALID_CERTIFICATES 105
|
||
TD_DH_PARAMETERS 109
|
||
|
||
The ASN.1 module for all structures defined in this document (plus
|
||
IMPORT statements for all imported structures) is given in
|
||
Appendix A.
|
||
|
||
All structures defined in or imported into this document MUST be
|
||
encoded using Distinguished Encoding Rules (DER) [X680] [X690]
|
||
(unless otherwise noted). All data structures carried in OCTET
|
||
STRINGs must be encoded according to the rules specified in
|
||
corresponding specifications.
|
||
|
||
Interoperability note: Some implementations may not be able to decode
|
||
wrapped CMS objects encoded with BER but not DER; specifically, they
|
||
may not be able to decode indefinite length encodings. To maximize
|
||
interoperability, implementers SHOULD 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
|
||
in [RFC3279]:
|
||
|
||
sha-1WithRSAEncryption (RSA with SHA1)
|
||
md5WithRSAEncryption (RSA with MD5)
|
||
id-dsa-with-sha1 (DSA with SHA1)
|
||
|
||
PKINIT uses the following encryption algorithm identifiers as defined
|
||
in [RFC3447] for encrypting the temporary key with a public key:
|
||
|
||
rsaEncryption
|
||
id-RSAES-OAEP
|
||
|
||
PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565]
|
||
for encrypting the AS reply key with the temporary key:
|
||
|
||
des-ede3-cbc (three-key 3DES, CBC mode, as defined in [RFC3370])
|
||
rc2-cbc (RC2, CBC mode, as defined in [RFC3370])
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 6]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
id-aes256-CBC (AES-256, CBC mode, as defined in [RFC3565])
|
||
|
||
PKINIT defines the following encryption types, for use in the etype
|
||
field of the AS-REQ [RFC4120] message to indicate acceptance of the
|
||
corresponding algorithms that can used by Cryptographic Message
|
||
Syntax (CMS) [RFC3852] messages in the reply:
|
||
|
||
id-dsa-with-sha1-CmsOID 9
|
||
-- Indicates that the client supports id-dsa-with-sha1.
|
||
md5WithRSAEncryption-CmsOID 10
|
||
-- Indicates that the client supports md5WithRSAEncryption.
|
||
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
|
||
|
||
This section defines the syntax and use of the various pre-
|
||
authentication fields employed by PKINIT.
|
||
|
||
3.2.1. Generation of Client Request
|
||
|
||
The initial authentication request (AS-REQ) is sent as per [RFC4120];
|
||
in addition, a pre-authentication data element, whose padata-type is
|
||
PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
|
||
type PA-PK-AS-REQ, is included.
|
||
|
||
PA-PK-AS-REQ ::= SEQUENCE {
|
||
signedAuthPack [0] IMPLICIT OCTET STRING,
|
||
-- Contains a CMS type ContentInfo encoded
|
||
-- according to [RFC3852].
|
||
-- The contentType field of the type ContentInfo
|
||
-- is id-signedData (1.2.840.113549.1.7.2),
|
||
-- and the content field is a SignedData.
|
||
-- The eContentType field for the type SignedData is
|
||
-- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
|
||
-- eContent field contains the DER encoding of the
|
||
-- type AuthPack.
|
||
-- AuthPack is defined below.
|
||
trustedCertifiers [1] SEQUENCE OF
|
||
ExternalPrincipalIdentifier OPTIONAL,
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 7]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
-- Contains a list of CAs, trusted by the client,
|
||
-- that can be used to certify the KDC.
|
||
-- Each ExternalPrincipalIdentifier identifies a CA
|
||
-- or a CA certificate (thereby its public key).
|
||
-- The information contained in the
|
||
-- trustedCertifiers SHOULD be used by the KDC as
|
||
-- hints to guide its selection of an appropriate
|
||
-- certificate chain to return to the client.
|
||
kdcPkId [2] IMPLICIT OCTET STRING
|
||
OPTIONAL,
|
||
-- Contains a CMS type SignerIdentifier encoded
|
||
-- according to [RFC3852].
|
||
-- Identifies, if present, a particular KDC
|
||
-- public key that the client already has.
|
||
...
|
||
}
|
||
|
||
DHNonce ::= OCTET STRING
|
||
|
||
ExternalPrincipalIdentifier ::= SEQUENCE {
|
||
subjectName [0] IMPLICIT OCTET STRING OPTIONAL,
|
||
-- Contains a PKIX type Name encoded according to
|
||
-- [RFC3280].
|
||
-- Identifies the certificate subject by the
|
||
-- distinguished subject name.
|
||
-- REQUIRED when there is a distinguished subject
|
||
-- name present in the certificate.
|
||
issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL,
|
||
-- Contains a CMS type IssuerAndSerialNumber encoded
|
||
-- according to [RFC3852].
|
||
-- Identifies a certificate of the subject.
|
||
-- REQUIRED for TD-INVALID-CERTIFICATES and
|
||
-- TD-TRUSTED-CERTIFIERS.
|
||
subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL,
|
||
-- Identifies the subject's public key by a key
|
||
-- identifier. When an X.509 certificate is
|
||
-- referenced, this key identifier matches the X.509
|
||
-- subjectKeyIdentifier extension value. When other
|
||
-- certificate formats are referenced, the documents
|
||
-- that specify the certificate format and their use
|
||
-- with the CMS must include details on matching the
|
||
-- key identifier to the appropriate certificate
|
||
-- field.
|
||
-- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
|
||
...
|
||
}
|
||
|
||
AuthPack ::= SEQUENCE {
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 8]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
pkAuthenticator [0] PKAuthenticator,
|
||
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
|
||
-- Type SubjectPublicKeyInfo is defined in
|
||
-- [RFC3280].
|
||
-- Specifies Diffie-Hellman domain parameters
|
||
-- and the client's public key value [IEEE1363].
|
||
-- The DH public key value is encoded as a BIT
|
||
-- STRING according to [RFC3279].
|
||
-- This field is present only if the client wishes
|
||
-- to use the Diffie-Hellman key agreement method.
|
||
supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
|
||
OPTIONAL,
|
||
-- Type AlgorithmIdentifier is defined in
|
||
-- [RFC3280].
|
||
-- List of CMS encryption types supported by the
|
||
-- client in order of (decreasing) preference.
|
||
clientDHNonce [3] DHNonce OPTIONAL,
|
||
-- Present only if the client indicates that it
|
||
-- wishes to reuse DH keys or to allow the KDC to
|
||
-- do so (see Section 3.2.3.1).
|
||
...
|
||
}
|
||
|
||
PKAuthenticator ::= SEQUENCE {
|
||
cusec [0] INTEGER (0..999999),
|
||
ctime [1] KerberosTime,
|
||
-- cusec and ctime are used as in [RFC4120], for
|
||
-- replay prevention.
|
||
nonce [2] INTEGER (0..4294967295),
|
||
-- Chosen randomly; This nonce does not need to
|
||
-- match with the nonce in the KDC-REQ-BODY.
|
||
paChecksum [3] OCTET STRING,
|
||
-- Contains the SHA1 checksum, performed over
|
||
-- KDC-REQ-BODY.
|
||
...
|
||
}
|
||
|
||
The ContentInfo [RFC3852] structure contained in the signedAuthPack
|
||
field of the type PA-PK-AS-REQ is encoded according to [RFC3852] and
|
||
is filled out as follows:
|
||
|
||
1. The contentType field of the type ContentInfo is id-signedData
|
||
(as defined in [RFC3852]), and the content field is a SignedData
|
||
(as defined in [RFC3852]).
|
||
|
||
2. The eContentType field for the type SignedData is id-pkinit-
|
||
authData: { iso(1) org(3) dod(6) internet(1) security(5)
|
||
kerberosv5(2) pkinit(3) authData(1) }. Notes to CMS
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 9]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
implementers: the signed attribute content-type MUST be present
|
||
in this SignedData instance and its value is id-pkinit-authData
|
||
according to [RFC3852].
|
||
|
||
3. The eContent field for the type SignedData contains the DER
|
||
encoding of the type AuthPack.
|
||
|
||
4. The signerInfos field of the type SignedData contains a single
|
||
signerInfo, which contains the signature over the type AuthPack.
|
||
|
||
5. The AuthPack structure contains a PKAuthenticator, the client
|
||
public key information, the CMS encryption types supported by the
|
||
client and a DHNonce. The pkAuthenticator field certifies to the
|
||
KDC that the client has recent knowledge of the signing key that
|
||
authenticates the client. The clientPublicValue field specifies
|
||
Diffie-Hellman domain parameters and the client's public key
|
||
value. The DH public key value is encoded as a BIT STRING
|
||
according to [RFC3279]. The clientPublicValue field is present
|
||
only if the client wishes to use the Diffie-Hellman key agreement
|
||
method. The supportedCMSTypes field specifies the list of CMS
|
||
encryption types supported by the client in order of (decreasing)
|
||
preference. The clientDHNonce field is described later in this
|
||
section.
|
||
|
||
6. The ctime field in the PKAuthenticator structure contains the
|
||
current time on the client's host, and the cusec field contains
|
||
the microsecond part of the client's timestamp. The ctime and
|
||
cusec fields are used together to specify a reasonably accurate
|
||
timestamp [RFC4120]. The nonce field is chosen randomly. The
|
||
paChecksum field contains a SHA1 checksum that is performed over
|
||
the KDC-REQ-BODY [RFC4120].
|
||
|
||
7. The certificates field of the type SignedData contains
|
||
certificates intended to facilitate certification path
|
||
construction, so that the KDC can verify the signature over the
|
||
type AuthPack. For path validation, these certificates SHOULD be
|
||
sufficient to construct at least one certification path from the
|
||
client certificate to one trust anchor acceptable by the KDC
|
||
[RFC4158]. The client MUST be capable of including such a set of
|
||
certificates if configured to do so. The certificates field MUST
|
||
NOT contain "root" CA certificates.
|
||
|
||
8. The client's Diffie-Hellman public value (clientPublicValue) is
|
||
included if and only if the client wishes to use the Diffie-
|
||
Hellman key agreement method. The Diffie-Hellman domain
|
||
parameters [IEEE1363] for the client's public key are specified
|
||
in the algorithm field of the type SubjectPublicKeyInfo [RFC3279]
|
||
and the client's Diffie-Hellman public key value is mapped to a
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 10]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
subjectPublicKey (a BIT STRING) according to [RFC3279]. When
|
||
using the Diffie-Hellman key agreement method, implementations
|
||
MUST support Oakley 1024-bit Modular Exponential (MODP) well-
|
||
known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group
|
||
14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known
|
||
group 16 [RFC3526].
|
||
|
||
The Diffie-Hellman field size should be chosen so as to provide
|
||
sufficient cryptographic security [RFC3766].
|
||
|
||
When MODP Diffie-Hellman is used, the exponents should have at
|
||
least twice as many bits as the symmetric keys that will be
|
||
derived from them [ODL99].
|
||
|
||
9. The client may wish to reuse DH keys or to allow the KDC to do so
|
||
(see Section 3.2.3.1). If so, then the client includes the
|
||
clientDHNonce field. This nonce string MUST be as long as the
|
||
longest key length of the symmetric key types that the client
|
||
supports. This nonce MUST be chosen randomly.
|
||
|
||
The ExternalPrincipalIdentifier structure is used in this document to
|
||
identify the subject's public key thereby the subject principal.
|
||
This structure is filled out as follows:
|
||
|
||
1. The subjectName field contains a PKIX type Name encoded according
|
||
to [RFC3280]. This field identifies the certificate subject by
|
||
the distinguished subject name. This field is REQUIRED when
|
||
there is a distinguished subject name present in the certificate
|
||
being used.
|
||
|
||
2. The issuerAndSerialNumber field contains a CMS type
|
||
IssuerAndSerialNumber encoded according to [RFC3852]. This field
|
||
identifies a certificate of the subject. This field is REQUIRED
|
||
for TD-INVALID-CERTIFICATES and TD-TRUSTED-CERTIFIERS (both
|
||
structures are defined in Section 3.2.2).
|
||
|
||
3. The subjectKeyIdentifier [RFC3852] field identifies the subject's
|
||
public key by a key identifier. When an X.509 certificate is
|
||
referenced, this key identifier matches the X.509
|
||
subjectKeyIdentifier extension value. When other certificate
|
||
formats are referenced, the documents that specify the
|
||
certificate format and their use with the CMS must include
|
||
details on matching the key identifier to the appropriate
|
||
certificate field. This field is RECOMMENDED for TD-TRUSTED-
|
||
CERTIFIERS (as defined in Section 3.2.2).
|
||
|
||
The trustedCertifiers field of the type PA-PK-AS-REQ contains a list
|
||
of CAs, trusted by the client, that can be used to certify the KDC.
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 11]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
Each ExternalPrincipalIdentifier identifies a CA or a CA certificate
|
||
(thereby its public key).
|
||
|
||
The kdcPkId field of the type PA-PK-AS-REQ contains a CMS type
|
||
SignerIdentifier encoded according to [RFC3852]. This field
|
||
identifies, if present, a particular KDC public key that the client
|
||
already has.
|
||
|
||
3.2.2. Receipt of Client Request
|
||
|
||
Upon receiving the client's request, the KDC validates it. This
|
||
section describes the steps that the KDC MUST (unless otherwise
|
||
noted) take in validating the request.
|
||
|
||
The KDC verifies the client's signature in the signedAuthPack field
|
||
according to [RFC3852].
|
||
|
||
If, while validating the client's X.509 certificate [RFC3280], the
|
||
KDC cannot build a certification path to validate the client's
|
||
certificate, it sends back a KRB-ERROR [RFC4120] message with the
|
||
code KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for
|
||
this error message is a TYPED-DATA (as defined in [RFC4120]) that
|
||
contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and
|
||
whose data-value contains the DER encoding of the type TD-TRUSTED-
|
||
CERTIFIERS:
|
||
|
||
TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
|
||
ExternalPrincipalIdentifier
|
||
-- Identifies a list of CAs trusted by the KDC.
|
||
-- Each ExternalPrincipalIdentifier identifies a CA
|
||
-- or a CA certificate (thereby its public key).
|
||
|
||
Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
|
||
TD-TRUSTED-CERTIFIERS structure identifies a CA or a CA certificate
|
||
(thereby its public key) trusted by the KDC.
|
||
|
||
Upon receiving this error message, the client SHOULD retry only if it
|
||
has a different set of certificates (from those of the previous
|
||
requests) that form a certification path (or a partial path) from one
|
||
of the trust anchors acceptable by the KDC to its own certificate.
|
||
|
||
If, while processing the certification path, the KDC determines that
|
||
the signature on one of the certificates in the signedAuthPack field
|
||
is invalid, it returns a KRB-ERROR [RFC4120] message with the code
|
||
KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data for this error
|
||
message is a TYPED-DATA that contains an element whose data-type is
|
||
TD_INVALID_CERTIFICATES, and whose data-value contains the DER
|
||
encoding of the type TD-INVALID-CERTIFICATES:
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 12]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
TD-INVALID-CERTIFICATES ::= SEQUENCE OF
|
||
ExternalPrincipalIdentifier
|
||
-- Each ExternalPrincipalIdentifier identifies a
|
||
-- certificate (sent by the client) with an invalid
|
||
-- signature.
|
||
|
||
Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
|
||
TD-INVALID-CERTIFICATES structure identifies a certificate (that was
|
||
sent by the client) with an invalid signature.
|
||
|
||
If more than one X.509 certificate signature is invalid, the KDC MAY
|
||
include one IssuerAndSerialNumber per invalid signature within the
|
||
TD-INVALID-CERTIFICATES.
|
||
|
||
The client's X.509 certificate is validated according to [RFC3280].
|
||
|
||
Based on local policy, the KDC may also check whether any X.509
|
||
certificates in the certification path validating the client's
|
||
certificate have been revoked. If any of them have been revoked, the
|
||
KDC MUST return an error message with the code
|
||
KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
|
||
revocation status but is unable to do so, it SHOULD return an error
|
||
message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN. The
|
||
certificate or certificates affected are identified exactly as for
|
||
the error code KDC_ERR_INVALID_CERTIFICATE (see above).
|
||
|
||
Note that the TD_INVALID_CERTIFICATES error data is only used to
|
||
identify invalid certificates sent by the client in the request.
|
||
|
||
The client's public key is then used to verify the signature. If the
|
||
signature fails to verify, the KDC MUST return an error message with
|
||
the code KDC_ERR_INVALID_SIG. There is no accompanying e-data for
|
||
this error message.
|
||
|
||
In addition to validating the client's signature, the KDC MUST also
|
||
check that the client's public key used to verify the client's
|
||
signature is bound to the client's principal name as specified in the
|
||
AS-REQ as follows:
|
||
|
||
1. If the KDC has its own binding between either the client's
|
||
signature-verification public key or the client's certificate and
|
||
the client's Kerberos principal name, it uses that binding.
|
||
|
||
2. Otherwise, if the client's X.509 certificate contains a Subject
|
||
Alternative Name (SAN) extension carrying a KRB5PrincipalName
|
||
(defined below) in the otherName field of the type GeneralName
|
||
[RFC3280], it binds the client's X.509 certificate to that name.
|
||
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 13]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
The type of the otherName field is AnotherName. The type-id field
|
||
of the type AnotherName is id-pkinit-san:
|
||
|
||
id-pkinit-san OBJECT IDENTIFIER ::=
|
||
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
|
||
x509SanAN (2) }
|
||
|
||
And the value field of the type AnotherName is a
|
||
KRB5PrincipalName.
|
||
|
||
KRB5PrincipalName ::= SEQUENCE {
|
||
realm [0] Realm,
|
||
principalName [1] PrincipalName
|
||
}
|
||
|
||
If the KDC does not have its own binding and there is no
|
||
KRB5PrincipalName name present in the client's X.509 certificate, or
|
||
if the Kerberos name in the request does not match the
|
||
KRB5PrincipalName in the client's X.509 certificate (including the
|
||
realm name), the KDC MUST return an error message with the code
|
||
KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for
|
||
this error message.
|
||
|
||
Even if the certification path is validated and the certificate is
|
||
mapped to the client's principal name, the KDC may decide not to
|
||
accept the client's certificate, depending on local policy.
|
||
|
||
The KDC MAY require the presence of an Extended Key Usage (EKU)
|
||
KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field
|
||
of the client's X.509 certificate:
|
||
|
||
id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
|
||
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
|
||
pkinit(3) keyPurposeClientAuth(4) }
|
||
-- PKINIT client authentication.
|
||
-- Key usage bits that MUST be consistent:
|
||
-- digitalSignature.
|
||
|
||
The digitalSignature key usage bit MUST be asserted when the intended
|
||
purpose of the client certificate is restricted with the id-pkinit-
|
||
KPClientAuth EKU.
|
||
|
||
If this EKU KeyPurposeId is required but it is not present or if the
|
||
client certificate is restricted not to be used for PKINIT client
|
||
authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
|
||
an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE. There
|
||
is no accompanying e-data for this error message. KDCs implementing
|
||
this requirement SHOULD also accept the EKU KeyPurposeId id-ms-kp-sc-
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 14]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there
|
||
are a large number of X.509 client certificates deployed for use with
|
||
PKINIT which have this EKU.
|
||
|
||
As a matter of local policy, the KDC MAY decide to reject requests on
|
||
the basis of the absence or presence of other specific EKU OID's.
|
||
|
||
If the digest algorithm used in generating the CA signature for the
|
||
public key in any certificate of the request is not acceptable by the
|
||
KDC, the KDC MUST return a KRB-ERROR [RFC4120] message with the code
|
||
KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED. The accompanying e-data MUST be
|
||
encoded in TYPED-DATA although none is defined at this point.
|
||
|
||
If the client's public key is not accepted with reasons other than
|
||
what were specified above, the KDC returns a KRB-ERROR [RFC4120]
|
||
message with the code KDC_ERR_CLIENT_NOT_TRUSTED. There is no
|
||
accompanying e-data currently defined for this error message.
|
||
|
||
The KDC MUST check the timestamp to ensure that the request is not a
|
||
replay, and that the time skew falls within acceptable limits. The
|
||
recommendations for clock skew times in [RFC4120] apply here. If the
|
||
check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
|
||
KRB_AP_ERR_SKEW, respectively.
|
||
|
||
If the clientPublicValue is filled in, indicating that the client
|
||
wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
|
||
check to see if the key parameters satisfy its policy. If they do
|
||
not, it MUST return an error message with the code
|
||
KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The accompanying e-data is a
|
||
TYPED-DATA that contains an element whose data-type is
|
||
TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
|
||
the type TD-DH-PARAMETERS:
|
||
|
||
TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
|
||
-- Each AlgorithmIdentifier specifies a set of
|
||
-- Diffie-Hellman domain parameters [IEEE1363].
|
||
-- This list is in decreasing preference order.
|
||
|
||
TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
|
||
that the KDC supports in decreasing preference order, from which the
|
||
client SHOULD pick one to retry the request.
|
||
|
||
The AlgorithmIdentifier structure is defined in [RFC3280] and is
|
||
filled in according to [RFC3279]. More specifically Section 2.3.3 of
|
||
[RFC3279] describes how to fill in the AlgorithmIdentifier structure
|
||
in the case where MODP Diffie-Hellman key exchange is used.
|
||
|
||
If the client included a kdcPkId field in the PA-PK-AS-REQ and the
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 15]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
KDC does not possess the corresponding key, the KDC MUST ignore the
|
||
kdcPkId field as if the client did not include one.
|
||
|
||
If the digest algorithm used by the id-pkinit-authData is not
|
||
acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120]
|
||
message with the code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED.
|
||
The accompanying e-data MUST be encoded in TYPED-DATA although none
|
||
is defined at this point.
|
||
|
||
3.2.3. Generation of KDC Reply
|
||
|
||
Assuming that the client's request has been properly validated, the
|
||
KDC proceeds as per [RFC4120], except as follows.
|
||
|
||
The KDC MUST set the initial flag and include an authorization data
|
||
element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued
|
||
ticket. The ad-data [RFC4120] field contains the DER encoding of the
|
||
type AD-INITIAL-VERIFIED-CAS:
|
||
|
||
AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
|
||
ExternalPrincipalIdentifier
|
||
-- Identifies the certification path based on which
|
||
-- the client certificate was validated.
|
||
-- Each ExternalPrincipalIdentifier identifies a CA
|
||
-- or a CA certificate (thereby its public key).
|
||
|
||
The AD-INITIAL-VERIFIED-CAS structure identifies the certification
|
||
path based on which the client certificate was validated. Each
|
||
ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the AD-
|
||
INITIAL-VERIFIED-CAS structure identifies a CA or a CA certificate
|
||
(thereby its public key).
|
||
|
||
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
|
||
(this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
|
||
[RFC4120]). Furthermore, any TGS MUST copy such authorization data
|
||
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
|
||
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
|
||
AD-IF-RELEVANT container.
|
||
|
||
Application servers that understand this authorization data type
|
||
SHOULD apply local policy to determine whether a given ticket bearing
|
||
such a type *not* contained within an AD-IF-RELEVANT container is
|
||
acceptable. (This corresponds to the AP server checking the
|
||
transited field when the TRANSITED-POLICY-CHECKED flag has not been
|
||
set [RFC4120].) If such a data type is contained within an AD-IF-
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 16]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
RELEVANT container, AP servers MAY apply local policy to determine
|
||
whether the authorization data is acceptable.
|
||
|
||
A pre-authentication data element, whose padata-type is PA_PK_AS_REP
|
||
and whose padata-value contains the DER encoding of the type PA-PK-
|
||
AS-REP (defined below), is included in the AS-REP [RFC4120].
|
||
|
||
PA-PK-AS-REP ::= CHOICE {
|
||
dhInfo [0] DHRepInfo,
|
||
-- Selected when Diffie-Hellman key exchange is
|
||
-- used.
|
||
encKeyPack [1] IMPLICIT OCTET STRING,
|
||
-- Selected when public key encryption is used.
|
||
-- Contains a CMS type ContentInfo encoded
|
||
-- according to [RFC3852].
|
||
-- The contentType field of the type ContentInfo is
|
||
-- id-envelopedData (1.2.840.113549.1.7.3).
|
||
-- The content field is an EnvelopedData.
|
||
-- The contentType field for the type EnvelopedData
|
||
-- is id-signedData (1.2.840.113549.1.7.2).
|
||
-- The eContentType field for the inner type
|
||
-- SignedData (when unencrypted) is
|
||
-- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
|
||
-- eContent field contains the DER encoding of the
|
||
-- type ReplyKeyPack.
|
||
-- ReplyKeyPack is defined in Section 3.2.3.2.
|
||
...
|
||
}
|
||
|
||
DHRepInfo ::= SEQUENCE {
|
||
dhSignedData [0] IMPLICIT OCTET STRING,
|
||
-- Contains a CMS type ContentInfo encoded according
|
||
-- to [RFC3852].
|
||
-- The contentType field of the type ContentInfo is
|
||
-- id-signedData (1.2.840.113549.1.7.2), and the
|
||
-- content field is a SignedData.
|
||
-- The eContentType field for the type SignedData is
|
||
-- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
|
||
-- eContent field contains the DER encoding of the
|
||
-- type KDCDHKeyInfo.
|
||
-- KDCDHKeyInfo is defined below.
|
||
serverDHNonce [1] DHNonce OPTIONAL
|
||
-- Present if and only if dhKeyExpiration is
|
||
-- present in the KDCDHKeyInfo.
|
||
}
|
||
|
||
KDCDHKeyInfo ::= SEQUENCE {
|
||
subjectPublicKey [0] BIT STRING,
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 17]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
-- The KDC's DH public key.
|
||
-- The DH public key value is encoded as a BIT
|
||
-- STRING according to [RFC3279].
|
||
nonce [1] INTEGER (0..4294967295),
|
||
-- Contains the nonce in the pkAuthenticator field
|
||
-- in the request if the DH keys are NOT reused,
|
||
-- 0 otherwise.
|
||
dhKeyExpiration [2] KerberosTime OPTIONAL,
|
||
-- Expiration time for KDC's key pair,
|
||
-- present if and only if the DH keys are reused.
|
||
-- If present, the KDC's DH public key MUST not be
|
||
-- used past the point of this expiration time.
|
||
-- If this field is omitted then the serverDHNonce
|
||
-- field MUST also be omitted.
|
||
...
|
||
}
|
||
|
||
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
|
||
key. Instead, it encrypts it with either a shared key derived from a
|
||
Diffie-Hellman exchange, or a generated encryption key. The contents
|
||
of the PA-PK-AS-REP indicate which key delivery method is used.
|
||
|
||
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
|
||
lifetime, however, can be shorter than that of the client's public-
|
||
private key pair. For the implementations of this specification, the
|
||
lifetime of the client's public-private key pair is the validity
|
||
period in X.509 certificates [RFC3280], unless configured otherwise.
|
||
|
||
3.2.3.1. Using Diffie-Hellman Key Exchange
|
||
|
||
In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
|
||
|
||
The ContentInfo [RFC3852] structure for the dhSignedData field is
|
||
filled in as follows:
|
||
|
||
1. The contentType field of the type ContentInfo is id-signedData
|
||
(as defined in [RFC3852]), and the content field is a SignedData
|
||
(as defined in [RFC3852]).
|
||
|
||
2. The eContentType field for the type SignedData is the OID value
|
||
for id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1)
|
||
security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }. Notes to CMS
|
||
implementers: the signed attribute content-type MUST be present
|
||
in this SignedData instance and its value is id-pkinit-DHKeyData
|
||
according to [RFC3852].
|
||
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 18]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
3. The eContent field for the type SignedData contains the DER
|
||
encoding of the type KDCDHKeyInfo.
|
||
|
||
4. The KDCDHKeyInfo structure contains the KDC's public key, a nonce
|
||
and optionally the expiration time of the KDC's DH key being
|
||
reused. The subjectPublicKey field of the type KDCDHKeyInfo
|
||
field identifies KDC's DH public key. This DH public key value
|
||
is encoded as a BIT STRING according to [RFC3279]. The nonce
|
||
field contains the nonce in the pkAuthenticator field in the
|
||
request if the DH keys are NOT reused. The value of this nonce
|
||
field is 0 if the DH keys are reused. The dhKeyExpiration field
|
||
is present if and only if the DH keys are reused. If the
|
||
dhKeyExpiration field is present, the KDC's public key in this
|
||
KDCDHKeyInfo structure MUST NOT be used past the point of this
|
||
expiration time. If this field is omitted then the serverDHNonce
|
||
field MUST also be omitted.
|
||
|
||
5. The signerInfos field of the type SignedData contains a single
|
||
signerInfo, which contains the signature over the type
|
||
KDCDHKeyInfo.
|
||
|
||
6. The certificates field of the type SignedData contains
|
||
certificates intended to facilitate certification path
|
||
construction, so that the client can verify the KDC's signature
|
||
over the type KDCDHKeyInfo. The information contained in the
|
||
trustedCertifiers in the request SHOULD be used by the KDC as
|
||
hints to guide its selection of an appropriate certificate chain
|
||
to return to the client. This field may be left empty if the KDC
|
||
public key specified by the kdcPkId field in the PA-PK-AS-REQ was
|
||
used for signing. Otherwise, for path validation, these
|
||
certificates SHOULD be sufficient to construct at least one
|
||
certification path from the KDC certificate to one trust anchor
|
||
acceptable by the client [RFC4158]. The KDC MUST be capable of
|
||
including such a set of certificates if configured to do so. The
|
||
certificates field MUST NOT contain "root" CA certificates.
|
||
|
||
7. If the client included the clientDHNonce field, then the KDC may
|
||
choose to reuse its DH keys (see Section 3.2.3.1). If the server
|
||
reuses DH keys then it MUST include an expiration time in the
|
||
dhKeyExpiration field. Past the point of the expiration time,
|
||
the signature over the type DHRepInfo is considered expired/
|
||
invalid. When the server reuses DH keys then it MUST include a
|
||
serverDHNonce at least as long as the length of keys for the
|
||
symmetric encryption system used to encrypt the AS reply. Note
|
||
that including the serverDHNonce changes how the client and
|
||
server calculate the key to use to encrypt the reply; see below
|
||
for details. The KDC SHOULD NOT reuse DH keys unless the
|
||
clientDHNonce field is present in the request.
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 19]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
The AS reply key is derived as follows:
|
||
|
||
1. Both the KDC and the client calculate the shared secret value as
|
||
follows:
|
||
|
||
a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
|
||
shared secret value. DHSharedSecret is the value ZZ as
|
||
described in Section 2.1.1 of [RFC2631].
|
||
|
||
DHSharedSecret is first padded with leading zeros such that the
|
||
size of DHSharedSecret in octets is the same as that of the
|
||
modulus, then represented as a string of octets in big-endian
|
||
order.
|
||
|
||
Implementation note: Both the client and the KDC can cache the
|
||
triple (ya, yb, DHSharedSecret), where ya is the client's public
|
||
key and yb is the KDC's public key. If both ya and yb are the
|
||
same in a later exchange, the cached DHSharedSecret can be used.
|
||
|
||
2. Let K be the key-generation seed length [RFC3961] of the AS reply
|
||
key whose enctype is selected according to [RFC4120].
|
||
|
||
3. Define the function octetstring2key() as follows:
|
||
|
||
octetstring2key(x) == random-to-key(K-truncate(
|
||
SHA1(0x00 | x) |
|
||
SHA1(0x01 | x) |
|
||
SHA1(0x02 | x) |
|
||
...
|
||
))
|
||
|
||
where x is an octet string; | is the concatenation operator; 0x00,
|
||
0x01, 0x02, etc., are each represented as a single octet; random-
|
||
to-key() is an operation that generates a protocol key from a
|
||
bitstring of length K; and K-truncate truncates its input to the
|
||
first K bits. Both K and random-to-key() are as defined in the
|
||
kcrypto profile [RFC3961] for the enctype of the AS reply key.
|
||
|
||
4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
|
||
the serverDHNonce; otherwise, let both n_c and n_k be empty octet
|
||
strings.
|
||
|
||
5. The AS reply key k is:
|
||
|
||
k = octetstring2key(DHSharedSecret | n_c | n_k)
|
||
|
||
If the hash algorithm used in the key derivation function (currently
|
||
only octetstring2key() is defined) is not acceptable by the KDC, the
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 20]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
KDC MUST return a KRB-ERROR [RFC4120] message with the code
|
||
KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED. The accompanying e-data MUST be
|
||
encoded in TYPED-DATA although none is defined at this point.
|
||
|
||
3.2.3.2. Using Public Key Encryption
|
||
|
||
In this case, the PA-PK-AS-REP contains an encKeyPack structure where
|
||
the AS reply key is encrypted.
|
||
|
||
The ContentInfo [RFC3852] structure for the encKeyPack field is
|
||
filled in as follows:
|
||
|
||
1. The contentType field of the type ContentInfo is id-envelopedData
|
||
(as defined in [RFC3852]), and the content field is an
|
||
EnvelopedData (as defined in [RFC3852]).
|
||
|
||
2. The contentType field for the type EnvelopedData is id-
|
||
signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
|
||
pkcs (1) pkcs7 (7) signedData (2) }.
|
||
|
||
3. The eContentType field for the inner type SignedData (when
|
||
decrypted from the encryptedContent field for the type
|
||
EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6)
|
||
internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }.
|
||
Notes to CMS implementers: the signed attribute content-type MUST
|
||
be present in this SignedData instance and its value is id-
|
||
pkinit-rkeyData according to [RFC3852].
|
||
|
||
4. The eContent field for the inner type SignedData contains the DER
|
||
encoding of the type ReplyKeyPack (as described below).
|
||
|
||
5. The signerInfos field of the inner type SignedData contains a
|
||
single signerInfo, which contains the signature for the type
|
||
ReplyKeyPack.
|
||
|
||
6. The certificates field of the inner type SignedData contains
|
||
certificates intended to facilitate certification path
|
||
construction, so that the client can verify the KDC's signature
|
||
for the type ReplyKeyPack. The information contained in the
|
||
trustedCertifiers in the request SHOULD be used by the KDC as
|
||
hints to guide its selection of an appropriate certificate chain
|
||
to return to the client. This field may be left empty if the KDC
|
||
public key specified by the kdcPkId field in the PA-PK-AS-REQ was
|
||
used for signing. Otherwise, for path validation, these
|
||
certificates SHOULD be sufficient to construct at least one
|
||
certification path from the KDC certificate to one trust anchor
|
||
acceptable by the client [RFC4158]. The KDC MUST be capable of
|
||
including such a set of certificates if configured to do so. The
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 21]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
certificates field MUST NOT contain "root" CA certificates.
|
||
|
||
7. The recipientInfos field of the type EnvelopedData is a SET which
|
||
MUST contain exactly one member of type KeyTransRecipientInfo.
|
||
The encryptedKey of this member contains the temporary key which
|
||
is encrypted using the client's public key.
|
||
|
||
8. The unprotectedAttrs or originatorInfo fields of the type
|
||
EnvelopedData MAY be present.
|
||
|
||
If there is a supportedCMSTypes field in the AuthPack, the KDC must
|
||
check to see if it supports any of the listed types. If it supports
|
||
more than one of the types, the KDC SHOULD use the one listed first.
|
||
If it does not support any of them, it MUST return an error message
|
||
with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].
|
||
|
||
Furthermore the KDC computes the checksum of the AS-REQ in the client
|
||
request. This checksum is performed over the type AS-REQ and the
|
||
protocol key [RFC3961] of the checksum operation is the replyKey and
|
||
the key usage number is 6. If the replyKey's enctype is "newer"
|
||
[RFC4120] [RFC4121], the checksum operation is the required checksum
|
||
operation [RFC3961] of that enctype.
|
||
|
||
ReplyKeyPack ::= SEQUENCE {
|
||
replyKey [0] EncryptionKey,
|
||
-- Contains the session key used to encrypt the
|
||
-- enc-part field in the AS-REP, i.e. the
|
||
-- AS reply key.
|
||
asChecksum [1] Checksum,
|
||
-- Contains the checksum of the AS-REQ
|
||
-- corresponding to the containing AS-REP.
|
||
-- The checksum is performed over the type AS-REQ.
|
||
-- The protocol key [RFC3961] of the checksum is the
|
||
-- replyKey and the key usage number is 6.
|
||
-- If the replyKey's enctype is "newer" [RFC4120]
|
||
-- [RFC4121], the checksum is the required
|
||
-- checksum operation [RFC3961] for that enctype.
|
||
-- The client MUST verify this checksum upon receipt
|
||
-- of the AS-REP.
|
||
...
|
||
}
|
||
|
||
Implementations of this RSA encryption key delivery method are
|
||
RECOMMENDED to support RSA keys at least 2048 bits in size.
|
||
|
||
3.2.4. Receipt of KDC Reply
|
||
|
||
Upon receipt of the KDC's reply, the client proceeds as follows. If
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 22]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
the PA-PK-AS-REP contains the dhSignedData field, the client derives
|
||
the AS reply key using the same procedure used by the KDC as defined
|
||
in Section 3.2.3.1. Otherwise, the message contains the encKeyPack
|
||
field, and the client decrypts and extracts the temporary key in the
|
||
encryptedKey field of the member KeyTransRecipientInfo, and then uses
|
||
that as the AS reply key.
|
||
|
||
If the public key encryption method is used, the client MUST verify
|
||
the asChecksum contained in the ReplyKeyPack.
|
||
|
||
In either case, the client MUST verify the signature in the
|
||
SignedData according to [RFC3852]. The KDC's X.509 certificate MUST
|
||
be validated according to [RFC3280]. In addition, unless the client
|
||
can otherwise verify that the public key used to verify the KDC's
|
||
signature is bound to the KDC of the target realm, the KDC's X.509
|
||
certificate MUST contain a Subject Alternative Name extension
|
||
[RFC3280] carrying an AnotherName whose type-id is id-pkinit-san (as
|
||
defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
|
||
matches the name of the TGS of the target realm (as defined in
|
||
Section 7.3 of [RFC4120]).
|
||
|
||
Unless the client knows by some other means that the KDC certificate
|
||
is intended for a Kerberos KDC, the client MUST require that the KDC
|
||
certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc:
|
||
|
||
id-pkinit-KPKdc OBJECT IDENTIFIER ::=
|
||
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
|
||
pkinit(3) keyPurposeKdc(5) }
|
||
-- Signing KDC responses.
|
||
-- Key usage bits that MUST be consistent:
|
||
-- digitalSignature.
|
||
|
||
The digitalSignature key usage bit MUST be asserted when the intended
|
||
purpose of KDC certificate is restricted with the id-pkinit-KPKdc
|
||
EKU.
|
||
|
||
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
|
||
a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required.
|
||
|
||
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,
|
||
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.
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 23]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
3.3. Interoperability Requirements
|
||
|
||
The client MUST be capable of sending a set of certificates
|
||
sufficient to allow the KDC to construct a certification path for the
|
||
client's certificate, if the correct set of certificates is provided
|
||
through configuration or policy.
|
||
|
||
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
|
||
verify the client's public key otherwise, the KDC MUST be able to
|
||
process path validation for the client's certificate based on the
|
||
certificates in the request.
|
||
|
||
The KDC MUST be capable of sending a set of certificates sufficient
|
||
to allow the client to construct a certification path for the KDC's
|
||
certificate, if the correct set of certificates is provided through
|
||
configuration or policy.
|
||
|
||
If the KDC sends all the X.509 certificates on a certification path
|
||
to a trust anchor acceptable by the client, and the client can not
|
||
verify the KDC's public key otherwise, the client MUST be able to
|
||
process path validation for the KDC's certificate based on the
|
||
certificates in the reply.
|
||
|
||
3.4. KDC Indication of PKINIT Support
|
||
|
||
If pre-authentication is required, but was not present in the
|
||
request, per [RFC4120] an error message with the code
|
||
KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
|
||
stored in the e-data field of the KRB-ERROR message to specify which
|
||
pre-authentication mechanisms are acceptable. The KDC can then
|
||
indicate the support of PKINIT by including an empty element whose
|
||
padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
|
||
|
||
Otherwise if it is required by the KDC's local policy that the client
|
||
must be pre-authenticated using the pre-authentication mechanism
|
||
specified in this document, but no PKINIT pre-authentication was
|
||
present in the request, an error message with the code
|
||
KDC_ERR_PREAUTH_FAILED SHOULD be returned.
|
||
|
||
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
|
||
STRING), and clients MUST ignore this and any other value. Future
|
||
extensions to this protocol may specify other data to send instead of
|
||
an empty OCTET STRING.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 24]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
4. Security Considerations
|
||
|
||
Kerberos error messages are not integrity protected, as a result, the
|
||
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
|
||
could be either weaker or not mutually preferred. Local policy can
|
||
configure sets of domain parameters acceptable locally, or disallow
|
||
the negotiation of DH domain parameters.
|
||
|
||
The symmetric reply key size and Diffie-Hellman field size or RSA
|
||
modulus size should be chosen so as to provide sufficient
|
||
cryptographic security [RFC3766].
|
||
|
||
When MODP Diffie-Hellman is used, the exponents should have at least
|
||
twice as many bits as the symmetric keys that will be derived from
|
||
them [ODL99].
|
||
|
||
PKINIT raises certain security considerations beyond those that can
|
||
be regulated strictly in protocol definitions. We will address them
|
||
in this section.
|
||
|
||
PKINIT extends the cross-realm model to the public-key
|
||
infrastructure. Users of PKINIT must understand security policies
|
||
and procedures appropriate to the use of Public Key Infrastructures
|
||
[RFC3280].
|
||
|
||
In order to trust a KDC certificate that is certified by a CA as a
|
||
KDC certificate for a target realm (for example, by asserting the TGS
|
||
name of that Kerberos realm as an id-pkinit-san SAN and/or
|
||
restricting the certificate usage by using the id-pkinit-KPKdc EKU,
|
||
as described in Section 3.2.4), the client MUST verify that the KDC
|
||
certificate's issuing CA is authorized to issue KDC certificates for
|
||
that target realm. Otherwise, the binding between the KDC
|
||
certificate and the KDC of the target realm is not established.
|
||
|
||
How to validate this authorization is a matter of local policy. A
|
||
way to achieve this is the configuration of specific sets of
|
||
intermediary CAs and trust anchors, one of which must be on the KDC
|
||
certificate's certification path [RFC3280]; and for each CA or trust
|
||
anchor the realms for which it is allowed to issue certificates.
|
||
|
||
In addition, if any CA is trusted to issue KDC certificates can also
|
||
issue other kinds of certificates, then local policy must be able to
|
||
distinguish between them: for example, it could require that KDC
|
||
certificates contain the id-pkinit-KPKdc EKU or that the realm be
|
||
specified with the id-pkinit-san SAN.
|
||
|
||
It is the responsibility of the PKI administrators for an
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 25]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
organization to ensure that KDC certificates are only issued to KDCs,
|
||
and that clients can ascertain this using their local policy.
|
||
|
||
Standard Kerberos allows the possibility of interactions between
|
||
cryptosystems of varying strengths; this document adds interactions
|
||
with public-key cryptosystems to Kerberos. Some administrative
|
||
policies may allow the use of relatively weak public keys. Using
|
||
such keys to wrap data encrypted under stronger conventional
|
||
cryptosystems may be inappropriate.
|
||
|
||
PKINIT requires keys for symmetric cryptosystems to be generated.
|
||
Some such systems contain "weak" keys. For recommendations regarding
|
||
these weak keys, see [RFC4120].
|
||
|
||
PKINIT allows the use of the same RSA key pair for encryption and
|
||
signing when doing RSA encryption based key delivery. This is not
|
||
recommended usage of RSA keys [RFC3447], by using DH based key
|
||
delivery this is avoided.
|
||
|
||
Care should be taken in how certificates are chosen for the purposes
|
||
of authentication using PKINIT. Some local policies may require that
|
||
key escrow be used for certain certificate types. Deployers of
|
||
PKINIT should be aware of the implications of using certificates that
|
||
have escrowed keys for the purposes of authentication. Because
|
||
signing only certificates are normally not escrowed, by using DH
|
||
based key delivery this is avoided.
|
||
|
||
PKINIT does not provide for a "return routability" test to prevent
|
||
attackers from mounting a denial-of-service attack on the KDC by
|
||
causing it to perform unnecessary and expensive public-key
|
||
operations. Strictly speaking, this is also true of standard
|
||
Kerberos, although the potential cost is not as great, because
|
||
standard Kerberos does not make use of public-key cryptography. By
|
||
using DH based key delivery and reusing DH keys, the necessary crypto
|
||
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-
|
||
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
|
||
mechanisms discussed in this specification (meaning it may be dropped
|
||
or added by attackers without being detected by either the client or
|
||
the KDC). Designers of additional pre-authentication data should
|
||
take that into consideration if such additional pre-authentication
|
||
data can be used in conjunction with the PA_PK_AS_REQ. The future
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 26]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
work of the Kerberos working group is expected to update the hash
|
||
algorithms specified in this document and provide a generic mechanism
|
||
to bind additional pre-authentication data with the accompanying
|
||
AS_REQ.
|
||
|
||
|
||
5. Acknowledgements
|
||
|
||
The following people have made significant contributions to this
|
||
draft: Paul Leach, Stefan Santesson, Sam Hartman, Love Hornquist
|
||
Astrand, Ken Raeburn, Nicolas Williams, John Wray, Tom Yu, Jeffrey
|
||
Hutzelman, David Cross, Dan Simon, Karthik Jaganathan, Chaskiel M
|
||
Grundman and Jeffrey Altman.
|
||
|
||
Andre Scedrov, Aaron D. Jaggard, Iliano Cervesato, Joe-Kai Tsay and
|
||
Chris Walstad discovered a binding issue between the AS-REQ and AS-
|
||
REP in draft -26, the asChecksum field was added as the result.
|
||
|
||
Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and
|
||
Jonathan Trostle who wrote earlier versions of this document.
|
||
|
||
The authors are indebted to the Kerberos working group chair Jeffrey
|
||
Hutzelman who kept track of various issues and was enormously helpful
|
||
during the creation of this document.
|
||
|
||
Some of the ideas on which this document is based arose during
|
||
discussions over several years between members of the SAAG, the IETF
|
||
CAT working group, and the PSRG, regarding integration of Kerberos
|
||
and SPX. Some ideas have also been drawn from the DASS system.
|
||
These changes are by no means endorsed by these groups. This is an
|
||
attempt to revive some of the goals of those groups, and this
|
||
document approaches those goals primarily from the Kerberos
|
||
perspective.
|
||
|
||
Lastly, comments from groups working on similar ideas in DCE have
|
||
been invaluable.
|
||
|
||
|
||
6. IANA Considerations
|
||
|
||
This document has no actions for IANA.
|
||
|
||
|
||
7. References
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 27]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
7.1. Normative References
|
||
|
||
[IEEE1363]
|
||
IEEE, "Standard Specifications for Public Key
|
||
Cryptography", IEEE 1363, 2000.
|
||
|
||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
|
||
RFC 2412, November 1998.
|
||
|
||
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
|
||
RFC 2631, June 1999.
|
||
|
||
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
|
||
Identifiers for the Internet X.509 Public Key
|
||
Infrastructure Certificate and Certificate Revocation List
|
||
(CRL) Profile", RFC 3279, April 2002.
|
||
|
||
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
|
||
X.509 Public Key Infrastructure Certificate and
|
||
Certificate Revocation List (CRL) Profile", RFC 3280,
|
||
April 2002.
|
||
|
||
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
|
||
Algorithms", RFC 3370, August 2002.
|
||
|
||
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
|
||
Standards (PKCS) #1: RSA Cryptography Specifications
|
||
Version 2.1", RFC 3447, February 2003.
|
||
|
||
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
|
||
Diffie-Hellman groups for Internet Key Exchange (IKE)",
|
||
RFC 3526, May 2003.
|
||
|
||
[RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES)
|
||
Encryption Algorithm in Cryptographic Message Syntax
|
||
(CMS)", RFC 3565, July 2003.
|
||
|
||
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
|
||
Public Keys Used For Exchanging Symmetric Keys", BCP 86,
|
||
RFC 3766, April 2004.
|
||
|
||
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
|
||
RFC 3852, July 2004.
|
||
|
||
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 28]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
Kerberos 5", RFC 3961, February 2005.
|
||
|
||
[RFC3962] Raeburn, K., "Advanced Encryption Standard (AES)
|
||
Encryption for Kerberos 5", RFC 3962, February 2005.
|
||
|
||
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
|
||
Kerberos Network Authentication Service (V5)", RFC 4120,
|
||
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,
|
||
Information technology - Abstract Syntax Notation One
|
||
(ASN.1): Specification of basic notation.
|
||
|
||
[X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
|
||
Information technology - ASN.1 encoding Rules: Specification
|
||
of Basic Encoding Rules (BER), Canonical Encoding Rules
|
||
(CER) and Distinguished Encoding Rules (DER).
|
||
|
||
7.2. Informative References
|
||
|
||
[LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
|
||
Sizes", Journal of Cryptology 14 (2001) 255-293.
|
||
|
||
[ODL99] Odlyzko, A., "Discrete logarithms: The past and the
|
||
future, Designs, Codes, and Cryptography (1999)".
|
||
|
||
|
||
Zhu & Tung Expires June 1, 2006 [Page 27]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
[RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
|
||
Nicholas, "Internet X.509 Public Key Infrastructure:
|
||
Certification Path Building", RFC 4158, September 2005.
|
||
|
||
|
||
Appendix A. PKINIT ASN.1 Module
|
||
|
||
KerberosV5-PK-INIT-SPEC {
|
||
iso(1) identified-organization(3) dod(6) internet(1)
|
||
security(5) kerberosV5(2) modules(4) pkinit(5)
|
||
} DEFINITIONS EXPLICIT TAGS ::= BEGIN
|
||
|
||
IMPORTS
|
||
SubjectPublicKeyInfo, AlgorithmIdentifier
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 29]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
FROM PKIX1Explicit88 { iso (1)
|
||
identified-organization (3) dod (6) internet (1)
|
||
security (5) mechanisms (5) pkix (7) id-mod (0)
|
||
id-pkix1-explicit (18) }
|
||
-- As defined in RFC 3280.
|
||
|
||
KerberosTime, PrincipalName, Realm, EncryptionKey
|
||
FROM KerberosV5Spec2 { iso(1) identified-organization(3)
|
||
dod(6) internet(1) security(5) kerberosV5(2)
|
||
modules(4) krb5spec2(2) } ;
|
||
|
||
id-pkinit OBJECT IDENTIFIER ::=
|
||
{ iso (1) org (3) dod (6) internet (1) security (5)
|
||
kerberosv5 (2) pkinit (3) }
|
||
|
||
id-pkinit-authData OBJECT IDENTIFIER ::= { id-pkinit 1 }
|
||
id-pkinit-DHKeyData OBJECT IDENTIFIER ::= { id-pkinit 2 }
|
||
id-pkinit-rkeyData OBJECT IDENTIFIER ::= { id-pkinit 3 }
|
||
id-pkinit-KPClientAuth OBJECT IDENTIFIER ::= { id-pkinit 4 }
|
||
id-pkinit-KPKdc OBJECT IDENTIFIER ::= { id-pkinit 5 }
|
||
|
||
id-pkinit-san OBJECT IDENTIFIER ::=
|
||
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
|
||
x509SanAN (2) }
|
||
|
||
pa-pk-as-req INTEGER ::= 16
|
||
pa-pk-as-rep INTEGER ::= 17
|
||
|
||
ad-initial-verified-cas INTEGER ::= 9
|
||
|
||
td-trusted-certifiers INTEGER ::= 104
|
||
td-invalid-certificates INTEGER ::= 105
|
||
td-dh-parameters INTEGER ::= 109
|
||
|
||
PA-PK-AS-REQ ::= SEQUENCE {
|
||
signedAuthPack [0] IMPLICIT OCTET STRING,
|
||
-- Contains a CMS type ContentInfo encoded
|
||
-- according to [RFC3852].
|
||
-- The contentType field of the type ContentInfo
|
||
-- is id-signedData (1.2.840.113549.1.7.2),
|
||
-- and the content field is a SignedData.
|
||
-- The eContentType field for the type SignedData is
|
||
-- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
|
||
-- eContent field contains the DER encoding of the
|
||
-- type AuthPack.
|
||
-- AuthPack is defined below.
|
||
trustedCertifiers [1] SEQUENCE OF
|
||
ExternalPrincipalIdentifier OPTIONAL,
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 30]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
-- Contains a list of CAs, trusted by the client,
|
||
-- that can be used to certify the KDC.
|
||
-- Each ExternalPrincipalIdentifier identifies a CA
|
||
-- or a CA certificate (thereby its public key).
|
||
-- The information contained in the
|
||
-- trustedCertifiers SHOULD be used by the KDC as
|
||
-- hints to guide its selection of an appropriate
|
||
-- certificate chain to return to the client.
|
||
kdcPkId [2] IMPLICIT OCTET STRING
|
||
OPTIONAL,
|
||
-- Contains a CMS type SignerIdentifier encoded
|
||
-- according to [RFC3852].
|
||
-- Identifies, if present, a particular KDC
|
||
-- public key that the client already has.
|
||
...
|
||
}
|
||
|
||
DHNonce ::= OCTET STRING
|
||
|
||
ExternalPrincipalIdentifier ::= SEQUENCE {
|
||
subjectName [0] IMPLICIT OCTET STRING OPTIONAL,
|
||
-- Contains a PKIX type Name encoded according to
|
||
-- [RFC3280].
|
||
-- Identifies the certificate subject by the
|
||
-- distinguished subject name.
|
||
-- REQUIRED when there is a distinguished subject
|
||
-- name present in the certificate.
|
||
issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL,
|
||
-- Contains a CMS type IssuerAndSerialNumber encoded
|
||
-- according to [RFC3852].
|
||
-- Identifies a certificate of the subject.
|
||
-- REQUIRED for TD-INVALID-CERTIFICATES and
|
||
-- TD-TRUSTED-CERTIFIERS.
|
||
subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL,
|
||
-- Identifies the subject's public key by a key
|
||
-- identifier. When an X.509 certificate is
|
||
-- referenced, this key identifier matches the X.509
|
||
-- subjectKeyIdentifier extension value. When other
|
||
-- certificate formats are referenced, the documents
|
||
-- that specify the certificate format and their use
|
||
-- with the CMS must include details on matching the
|
||
-- key identifier to the appropriate certificate
|
||
-- field.
|
||
-- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
|
||
...
|
||
}
|
||
|
||
AuthPack ::= SEQUENCE {
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 31]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
pkAuthenticator [0] PKAuthenticator,
|
||
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
|
||
-- Type SubjectPublicKeyInfo is defined in
|
||
-- [RFC3280].
|
||
-- Specifies Diffie-Hellman domain parameters
|
||
-- and the client's public key value [IEEE1363].
|
||
-- The DH public key value is encoded as a BIT
|
||
-- STRING according to [RFC3279].
|
||
-- This field is present only if the client wishes
|
||
-- to use the Diffie-Hellman key agreement method.
|
||
supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
|
||
OPTIONAL,
|
||
-- Type AlgorithmIdentifier is defined in
|
||
-- [RFC3280].
|
||
-- List of CMS encryption types supported by the
|
||
-- client in order of (decreasing) preference.
|
||
clientDHNonce [3] DHNonce OPTIONAL,
|
||
-- Present only if the client indicates that it
|
||
-- wishes to reuse DH keys or to allow the KDC to
|
||
-- do so.
|
||
...
|
||
}
|
||
|
||
PKAuthenticator ::= SEQUENCE {
|
||
cusec [0] INTEGER (0..999999),
|
||
ctime [1] KerberosTime,
|
||
-- cusec and ctime are used as in [RFC4120], for
|
||
-- replay prevention.
|
||
nonce [2] INTEGER (0..4294967295),
|
||
-- Chosen randomly; This nonce does not need to
|
||
-- match with the nonce in the KDC-REQ-BODY.
|
||
paChecksum [3] OCTET STRING,
|
||
-- Contains the SHA1 checksum, performed over
|
||
-- KDC-REQ-BODY.
|
||
...
|
||
}
|
||
|
||
TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
|
||
ExternalPrincipalIdentifier
|
||
-- Identifies a list of CAs trusted by the KDC.
|
||
-- Each ExternalPrincipalIdentifier identifies a CA
|
||
-- or a CA certificate (thereby its public key).
|
||
|
||
TD-INVALID-CERTIFICATES ::= SEQUENCE OF
|
||
ExternalPrincipalIdentifier
|
||
-- Each ExternalPrincipalIdentifier identifies a
|
||
-- certificate (sent by the client) with an invalid
|
||
-- signature.
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 32]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
KRB5PrincipalName ::= SEQUENCE {
|
||
realm [0] Realm,
|
||
principalName [1] PrincipalName
|
||
}
|
||
|
||
AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
|
||
ExternalPrincipalIdentifier
|
||
-- Identifies the certification path based on which
|
||
-- the client certificate was validated.
|
||
-- Each ExternalPrincipalIdentifier identifies a CA
|
||
-- or a CA certificate (thereby its public key).
|
||
|
||
PA-PK-AS-REP ::= CHOICE {
|
||
dhInfo [0] DHRepInfo,
|
||
-- Selected when Diffie-Hellman key exchange is
|
||
-- used.
|
||
encKeyPack [1] IMPLICIT OCTET STRING,
|
||
-- Selected when public key encryption is used.
|
||
-- Contains a CMS type ContentInfo encoded
|
||
-- according to [RFC3852].
|
||
-- The contentType field of the type ContentInfo is
|
||
-- id-envelopedData (1.2.840.113549.1.7.3).
|
||
-- The content field is an EnvelopedData.
|
||
-- The contentType field for the type EnvelopedData
|
||
-- is id-signedData (1.2.840.113549.1.7.2).
|
||
-- The eContentType field for the inner type
|
||
-- SignedData (when unencrypted) is
|
||
-- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
|
||
-- eContent field contains the DER encoding of the
|
||
-- type ReplyKeyPack.
|
||
-- ReplyKeyPack is defined below.
|
||
...
|
||
}
|
||
|
||
DHRepInfo ::= SEQUENCE {
|
||
dhSignedData [0] IMPLICIT OCTET STRING,
|
||
-- Contains a CMS type ContentInfo encoded according
|
||
-- to [RFC3852].
|
||
-- The contentType field of the type ContentInfo is
|
||
-- id-signedData (1.2.840.113549.1.7.2), and the
|
||
-- content field is a SignedData.
|
||
-- The eContentType field for the type SignedData is
|
||
-- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
|
||
-- eContent field contains the DER encoding of the
|
||
-- type KDCDHKeyInfo.
|
||
-- KDCDHKeyInfo is defined below.
|
||
serverDHNonce [1] DHNonce OPTIONAL
|
||
-- Present if and only if dhKeyExpiration is
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 33]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
-- present.
|
||
}
|
||
|
||
KDCDHKeyInfo ::= SEQUENCE {
|
||
subjectPublicKey [0] BIT STRING,
|
||
-- The KDC's DH public key.
|
||
-- The DH public key value is encoded as a BIT
|
||
-- STRING according to [RFC3279].
|
||
nonce [1] INTEGER (0..4294967295),
|
||
-- Contains the nonce in the pkAuthenticator field
|
||
-- in the request if the DH keys are NOT reused,
|
||
-- 0 otherwise.
|
||
dhKeyExpiration [2] KerberosTime OPTIONAL,
|
||
-- Expiration time for KDC's key pair,
|
||
-- present if and only if the DH keys are reused.
|
||
-- If present, the KDC's DH public key MUST not be
|
||
-- used past the point of this expiration time.
|
||
-- If this field is omitted then the serverDHNonce
|
||
-- field MUST also be omitted.
|
||
...
|
||
}
|
||
|
||
ReplyKeyPack ::= SEQUENCE {
|
||
replyKey [0] EncryptionKey,
|
||
-- Contains the session key used to encrypt the
|
||
-- enc-part field in the AS-REP, i.e. the
|
||
-- AS reply key.
|
||
asChecksum [1] Checksum,
|
||
-- Contains the checksum of the AS-REQ
|
||
-- corresponding to the containing AS-REP.
|
||
-- The checksum is performed over the type AS-REQ.
|
||
-- The protocol key [RFC3961] of the checksum is the
|
||
-- replyKey and the key usage number is 6.
|
||
-- If the replyKey's enctype is "newer" [RFC4120]
|
||
-- [RFC4121], the checksum is the required
|
||
-- checksum operation [RFC3961] for that enctype.
|
||
-- The client MUST verify this checksum upon receipt
|
||
-- of the AS-REP.
|
||
...
|
||
}
|
||
|
||
TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
|
||
-- Each AlgorithmIdentifier specifies a set of
|
||
-- Diffie-Hellman domain parameters [IEEE1363].
|
||
-- This list is in decreasing preference order.
|
||
END
|
||
|
||
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 34]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
Appendix B. Test Vectors
|
||
|
||
Function octetstring2key() is defined in Section 3.2.3.1. This
|
||
section describes a few sets of test vectors that would be useful for
|
||
implementers of octetstring2key().
|
||
|
||
|
||
Set 1
|
||
=====
|
||
Input octet string x is:
|
||
|
||
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||
|
||
Output of K-truncate() when the key size is 32 octets:
|
||
|
||
5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83
|
||
75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41
|
||
|
||
|
||
Set 2:
|
||
=====
|
||
Input octet string x is:
|
||
|
||
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||
|
||
Output of K-truncate() when the key size is 32 octets:
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 35]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb
|
||
a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e
|
||
|
||
|
||
Set 3:
|
||
======
|
||
Input octet string x is:
|
||
|
||
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
|
||
10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
|
||
0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
|
||
0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
|
||
0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b
|
||
0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a
|
||
0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09
|
||
0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
|
||
|
||
Output of K-truncate() when the key size is 32 octets:
|
||
|
||
c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3
|
||
73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e
|
||
|
||
|
||
Set 4:
|
||
=====
|
||
Input octet string x is:
|
||
|
||
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
|
||
10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
|
||
0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
|
||
0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
|
||
0d 0e 0f 10 00 01 02 03 04 05 06 07 08
|
||
|
||
Output of K-truncate() when the key size is 32 octets:
|
||
|
||
00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a
|
||
59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc
|
||
|
||
|
||
Appendix C. Miscellaneous Information about Microsoft Windows PKINIT
|
||
Implementations
|
||
|
||
Earlier revisions of the PKINIT I-D were implemented in various
|
||
releases of Microsoft Windows and deployed in fairly large numbers.
|
||
To enable the community to better interoperate with systems running
|
||
those releases, the following information may be useful.
|
||
|
||
KDC certificates issued by Windows 2000 Enterprise CAs contain a
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 36]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
dNSName SAN with the DNS name of the host running the KDC, and the
|
||
id-kp-serverAuth EKU [RFC3280].
|
||
|
||
KDC certificates issued by Windows 2003 Enterprise CAs contain a
|
||
dNSName SAN with the DNS name of the host running the KDC, the id-kp-
|
||
serverAuth EKU and the id-ms-kp-sc-logon EKU.
|
||
|
||
It is anticipated that the next release of Windows is already too far
|
||
along to allow it to support the issuing KDC certificates with id-
|
||
pkinit-san SAN as specified in this RFC. Instead, they will have a
|
||
dNSName SAN containing the domain name of the KDC and the intended
|
||
purpose of these KDC certificates be restricted by the presence of
|
||
the id-pkinit-KPKdc EKU and id-kp-serverAuth EKU.
|
||
|
||
In addition to checking that the above are present in a KDC
|
||
certificate, Windows clients verify that the issuer of the KDC
|
||
certificate is one of a set of allowed issuers of such certificates,
|
||
so those wishing to issue KDC certificates need to configure their
|
||
Windows clients appropriately.
|
||
|
||
Client certificates accepted by Windows 2000 and Windows 2003 Server
|
||
KDCs must contain an id-ms-san-sc-logon-upn (1.3.6.1.4.1.311.20.2.3)
|
||
SAN and the id-ms-kp-sc-logon EKU. The id-ms-san-sc-logon-upn SAN
|
||
contains a UTF8 encoded string whose value is that of the Directory
|
||
Service attribute UserPrincipalName of the client account object, and
|
||
the purpose of including the id-ms-san-sc-logon-upn SAN in the client
|
||
certificate is to validate the client mapping (in other words, the
|
||
client's public key is bound to the account that has this
|
||
UserPrincipalName value).
|
||
|
||
It should be noted that all Microsoft Kerberos realm names are domain
|
||
style realm names and strictly in upper case. In addition, the
|
||
UserPrincipalName attribute is globally unique in Windows 2000 and
|
||
Windows 2003.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 37]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
Authors' Addresses
|
||
|
||
Larry Zhu
|
||
Microsoft Corporation
|
||
One Microsoft Way
|
||
Redmond, WA 98052
|
||
US
|
||
|
||
Email: lzhu@microsoft.com
|
||
|
||
|
||
Brian Tung
|
||
USC Information Sciences Institute
|
||
4676 Admiralty Way Suite 1001
|
||
Marina del Rey, CA 90292
|
||
US
|
||
|
||
Email: brian@isi.edu
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 38]
|
||
|
||
Internet-Draft PKINIT November 2005
|
||
|
||
|
||
Intellectual Property Statement
|
||
|
||
The IETF takes no position regarding the validity or scope of any
|
||
Intellectual Property Rights or other rights that might be claimed to
|
||
pertain to the implementation or use of the technology described in
|
||
this document or the extent to which any license under such rights
|
||
might or might not be available; nor does it represent that it has
|
||
made any independent effort to identify any such rights. Information
|
||
on the procedures with respect to rights in RFC documents can be
|
||
found in BCP 78 and BCP 79.
|
||
|
||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||
assurances of licenses to be made available, or the result of an
|
||
attempt made to obtain a general license or permission for the use of
|
||
such proprietary rights by implementers or users of this
|
||
specification can be obtained from the IETF on-line IPR repository at
|
||
http://www.ietf.org/ipr.
|
||
|
||
The IETF invites any interested party to bring to its attention any
|
||
copyrights, patents or patent applications, or other proprietary
|
||
rights that may cover technology that may be required to implement
|
||
this standard. Please address the information to the IETF at
|
||
ietf-ipr@ietf.org.
|
||
|
||
|
||
Disclaimer of Validity
|
||
|
||
This document and the information contained herein are provided on an
|
||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
|
||
Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (2005). This document is subject
|
||
to the rights, licenses and restrictions contained in BCP 78, and
|
||
except as set forth therein, the authors retain all their rights.
|
||
|
||
|
||
Acknowledgment
|
||
|
||
Funding for the RFC Editor function is currently provided by the
|
||
Internet Society.
|
||
|
||
|
||
|
||
|
||
Zhu & Tung Expires June 2, 2006 [Page 39]
|