[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CVS shishi/doc/specifications
From: |
shishi-commit |
Subject: |
CVS shishi/doc/specifications |
Date: |
Wed, 27 Oct 2004 00:56:28 +0200 |
Update of /home/cvs/shishi/doc/specifications
In directory dopio:/tmp/cvs-serv16717
Added Files:
draft-ietf-cat-kerberos-pk-init-21.txt
Log Message:
Add.
--- /home/cvs/shishi/doc/specifications/draft-ietf-cat-kerberos-pk-init-21.txt
2004/10/26 22:56:28 NONE
+++ /home/cvs/shishi/doc/specifications/draft-ietf-cat-kerberos-pk-init-21.txt
2004/10/26 22:56:28 1.1
INTERNET-DRAFT Brian Tung
draft-ietf-cat-kerberos-pk-init-21.txt Clifford Neuman
expires April 25, 2005 USC/ISI
Sasha Medvinsky
Motorola, Inc.
Public Key Cryptography for Initial Authentication in Kerberos
0. Status Of This Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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
The distribution of this memo is unlimited. It is filed as
draft-ietf-cat-kerberos-pk-init-21.txt and expires April 25, 2005.
Please send comments to the authors.
1. Abstract
This document describes protocol extensions (hereafter called
PKINIT) to the Kerberos protocol specification [1]. These
extensions provide a method for integrating public key cryptography
into the initial authentication exchange, by passing digital
certificates and associated authenticators in preauthentication data
fields.
2. 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. (In this document, we
will refer to both the AS and the TGS as the KDC.) Finally, the
client uses the service ticket to authenticate itself to the
service.
The advantage afforded by the TGT is that the client need explicitly
request a ticket and expose his credentials only once. The TGT and
its associated session key can then be used for any subsequent
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, Kerberos authentication exchanges use symmetric-key
cryptography, in part for performance. One cost 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.
3. Extensions
This section describes extensions to [1] for supporting the use of
public-key cryptography in the initial request for a ticket.
Briefly, this document defines the following extensions to [1]:
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 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 symmetric encryption key, signed using the KDC's
signature key and encrypted using the client's encryption
key; or
b. a key generated through a Diffie-Hellman exchange with
the client, signed using the KDC's signature key.
Any keying material required by the client to obtain the
Encryption key is returned in a preauthentication field
accompanying the usual reply.
4. The client obtains the encryption key, decrypts the reply,
and then proceeds as usual.
Section 3.1 of this document defines the necessary message formats.
Section 3.2 describes their syntax and use in greater detail.
3.1. Definitions, Requirements, and Constants
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 RFC 2119 [12].
3.1.1. Required Algorithms
All PKINIT implementations MUST support the following algorithms:
- Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype.
- Signature algorithm: SHA-1 digest and RSA.
- Reply key delivery method: ephemeral-ephemeral Diffie-Hellman
with a non-zero nonce.
- Unkeyed checksum type for the paChecksum member of
PKAuthenticator: SHA1 (unkeyed), Kerberos checksum type 14
[11].
3.1.2. Defined Message and Encryption Types
PKINIT makes use of the following new preauthentication types:
PA-PK-AS-REQ TBD
PA-PK-AS-REP TBD
PKINIT also makes use of the following new authorization data type:
AD-INITIAL-VERIFIED-CAS TBD
PKINIT introduces the following new error codes:
KDC_ERR_CLIENT_NOT_TRUSTED 62
KDC_ERR_KDC_NOT_TRUSTED 63
KDC_ERR_INVALID_SIG 64
KDC_ERR_KEY_SIZE 65
KDC_ERR_CERTIFICATE_MISMATCH 66
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
PKINIT uses the following typed data types for errors:
TD-DH-PARAMETERS TBD
TD-TRUSTED-CERTIFIERS 104
TD-CERTIFICATE-INDEX 105
TD-UNKEYED-CHECKSUM-INFO 109
PKINIT defines the following encryption types, for use in the AS-REQ
message (to indicate acceptance of the corresponding encryption OIDs
in PKINIT):
dsaWithSHA1-CmsOID 9
md5WithRSAEncryption-CmsOID 10
sha1WithRSAEncryption-CmsOID 11
rc2CBC-EnvOID 12
rsaEncryption-EnvOID (PKCS1 v1.5) 13
rsaES-OAEP-EnvOID (PKCS1 v2.0) 14
des-ede3-cbc-EnvOID 15
The above encryption types are used by the client only within the
KDC-REQ-BODY to indicate which CMS [2] algorithms it supports. Their
use within Kerberos EncryptedData structures is not specified by this
document.
The ASN.1 module for all structures defined in this document (plus
IMPORT statements for all imported structures) are given in Appendix
A. In the event of a discrepancy between Appendix A and the portions
of ASN.1 in the main text, the appendix is normative.
All structures defined in this document MUST be encoded using
Distinguished Encoding Rules (DER). All imported data structures
must be encoded according to the rules specified in Kerberos [1] or
CMS [2] as appropriate.
Interoperability note: Some implementations may not be able to
decode CMS objects encoded with BER but not DER; specifically, they
may not be able to decode infinite 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 for Diffie-Hellman
key agreement [9]:
dhpublicnumber
PKINIT uses the following signature algorithm identifiers [8, 12]:
sha-1WithRSAEncryption (RSA with SHA1)
md5WithRSAEncryption (RSA with MD5)
id-dsa-with-sha1 (DSA with SHA1)
PKINIT uses the following encryption algorithm identifiers [5] for
encrypting the temporary key with a public key:
rsaEncryption (PKCS1 v1.5)
id-RSAES-OAEP (PKCS1 v2.0)
PKINIT uses the following algorithm identifiers [2] for encrypting
the reply key with the temporary key:
des-ede3-cbc (three-key 3DES, CBC mode)
rc2-cbc (RC2, CBC mode)
aes256_CBC (AES-256, CBC mode)
3.2. PKINIT Preauthentication Syntax and Use
This section defines the syntax and use of the various
preauthentication fields employed by PKINIT.
3.2.1. Client Request
The initial authentication request (AS-REQ) is sent as per [1]; in
addition, a preauthentication field contains data signed by the
client's private signature key, as follows:
WrapContentInfo ::= OCTET STRING (CONSTRAINED BY {
-- Contains a BER encoding of
-- ContentInfo
})
WrapIssuerAndSerial ::= OCTET STRING (CONSTRAINED BY {
-- Contains a BER encoding of
-- IssuerAndSerialNumber
})
PA-PK-AS-REQ ::= SEQUENCE {
signedAuthPack [0] IMPLICIT WrapContentInfo,
-- Type is SignedData.
-- Content is AuthPack
-- (defined below).
trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,
-- A list of CAs, trusted by
-- the client, used to certify
-- KDCs.
kdcCert [2] IMPLICIT WrapIssuerAndSerial
OPTIONAL,
-- Identifies a particular KDC
-- certificate, if the client
-- already has it.
...
}
TrustedCA ::= CHOICE {
caName [1] Name,
-- Fully qualified X.500 name
-- as defined in RFC 3280 [4].
issuerAndSerial [2] IMPLICIT WrapIssuerAndSerial,
-- Identifies a specific CA
-- certificate.
...
}
AuthPack ::= SEQUENCE {
pkAuthenticator [0] PKAuthenticator,
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
-- Defined in RFC 3280 [4].
-- Present only if the client
-- is using ephemeral-ephemeral
-- Diffie-Hellman.
supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
OPTIONAL,
-- List of CMS encryption types
-- supported by client in order
-- of (decreasing) preference.
...
}
PKAuthenticator ::= SEQUENCE {
cusec [0] INTEGER (0..999999),
ctime [1] KerberosTime,
-- cusec and ctime are used as
-- in [1], for replay
-- prevention.
nonce [2] INTEGER (0..4294967295),
-- Binds reply to request,
-- MUST be zero when client
-- will accept cached
-- Diffie-Hellman parameters
-- from KDC. MUST NOT be
-- zero otherwise.
paChecksum [3] Checksum,
-- Defined in [1].
-- Performed over KDC-REQ-BODY,
-- MUST be unkeyed.
...
}
[849 lines skipped]