CVS shishi/doc/specifications

[shishi-commit]

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]