view Side-By-Side changes

INTERNET-DRAFT                                         Clifford Neuman
draft-ietf-cat-kerberos-pk-init-02.txt
draft-ietf-cat-kerberos-pk-init-03.txt                      Brian Tung
Updates: RFC 1510                                                  ISI
expires April 19, September 30, 1997                                   John Wray
                                         Digital Equipment Corporation
						      Jonathan Trostle
                                                         Ari Medvinsky
                                                           Matthew Hur
                                                 CyberSafe Corporation
                                                      Jonathan Trostle
                                                                Novell


    Public Key Cryptography for Initial Authentication in Kerberos


0.  Status Of this Memo

    This document is an Internet-Draft.  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 docu-
   ments
    documents at any time.  It is inappropriate to use Internet-Drafts
    as reference material or to cite them other than as ``work "work in pro-
   gress.''
    progress."

    To learn the current status of any Internet-Draft, please check
    the
   ``1id-abstracts.txt'' "1id-abstracts.txt" listing contained in the Internet-Drafts Sha-
   dow
    Shadow Directories on ds.internic.net (US East Coast),
    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
    munnari.oz.au (Pacific Rim).

    The distribution of this memo is unlimited.  It is filed as
   draft-ietf-cat-kerberos-pk-init-02.txt,
    draft-ietf-cat-kerberos-pk-init-03.txt, and expires April 19, September 30,
    1997.  Please send comments to the authors.


1.  Abstract

    This document defines extensions (PKINIT) to the Kerberos protocol
    specification (RFC 1510, "The Kerberos Network Authentication
   Service (V5)", September 1993) 1510 [1]) to provide a method for using public
    key cryptography during initial authentication.  The method methods
    defined
   specifies specify the way ways in which preauthentication data fields and
    error data fields in Kerberos messages are to be used to transport
    public key data.


2. Motivation

   Public  Introduction

    The popularity of public key cryptography presents has produced a means desire for
    its support in Kerberos [2].  The advantages provided by which a principal may
   demonstrate possession of a key, without ever having divulged this public key to anyone else.  In conventional cryptography, the encryption
    cryptography include simplified key management (from the Kerberos
    perspective) and decryption key are either identical or can easily be
   derived from one another. In public key cryptography, however,
   neither the ability to leverage existing and developing
    public key nor the private certification infrastructures.

    Public key cryptography can be derived from the
   other (although the private integrated into Kerberos in a number
    of ways.  One is to to associate a key RECORD may include pair with each realm, which
    can then be used to facilitate cross-realm authentication; this is
    the information
   required topic of another draft proposal.  Another way is to generate BOTH keys). Hence, a message encrypted allow users
    with a public key certificates to use them in initial authentication.
    This is private, since only the person possessing concern of the private

   key can decrypt it; similarly, someone possessing current document.

    One of the private key
   can also encrypt a message, thus providing a digital signature.

   Furthermore, conventional keys are often derived from passwords, so
   messages encrypted with these keys are susceptible to dictionary
   attacks, whereas public key pairs are generated from a
   pseudo-random number sequence.  While it guiding principles in the design of PKINIT is true that messages
   encrypted using public key cryptography are actually encrypted with
    changes should be as minimal as possible.  As a conventional secret key, which is in turn encrypted using the
   public key pair, result, the secret key basic
    mechanism of PKINIT is also randomly generated and as follows:  The user sends a request to the
    KDC as before, except that if that user is
   hence not vulnerable to a dictionary attack.

   The advantages provided by use public key
    cryptography have produced a
   demand for its integration into in the Kerberos initial authentication
   protocol. The public key integration into Kerberos described in
   this document has three goals. 

   First, by allowing users to register public keys with the KDC, the
   KDC can be recovered much more easily step, his certificate
    accompanies the initial request, in the event it is
   compromised. With Kerberos as it currently stands, compromise preauthentication fields.

    Upon receipt of this request, the KDC is disastrous. All keys become known by verifies the attacker certificate and
   all keys must be changed. Second, we allow users that have public
   key certificates signed by outside authorities to obtain Kerberos
   credentials for access to Kerberized services. Third, we obtain the
   above benefits while maintaining the performance advantages of
   Kerberos over protocols that use only public key authentication. 

   If users register public keys, compromise of the KDC does not
   divulge their private key.  Compromise of security on the KDC is
   still a problem, since an attacker can impersonate any user by
   creating
    issues a ticket granting ticket for the user. When (TGT) as before, except that instead
    of being encrypted in the compromise user's long-term key (which is detected, the KDC can be cleaned up and restored derived
    from backup
   media and loaded with a backup private/public key pair. Keys for
   application servers are conventional symmetric keys and must be
   changed.

   Note: If a user stores his private key, in an encrypted form, on
   the KDC, then password), it may be desirable to change the key pair, since the
   private key is encrypted using in a symmetric randomly-generated key.  This
    random key derived from a
   password (as described below), and can therefore be vulnerable to
   dictionary attack if a good password policy is not used. 
   Alternatively, if in turn encrypted using the encrypting symmetric public key has 56 bits, then it
   may also be desirable to change certificate
    that came with the key pair after a short period
   due to request and signed using the short key length. The KDC does not have access to KDC's signature key,
    and accompanies the
   user's unencrypted private key.

   There are two important areas where public key cryptography will
   have immediate use: reply, in the initial authentication of preauthentication fields.

    PKINIT also allows for users
   registered with the KDC or only digital signature keys to
    authenticate using public key certificates from
   outside authorities, those keys, and for users to establish inter-realm store and retrieve
    private keys on the KDC.

    The PKINIT specification may also be used for
   cross-realm authentication. This memo describes a method by which
   the first of these can be done. The second case will be the topic
   for direct peer to peer
    authentication without contacting a separate proposal.

   Some central KDC. This application
    of the ideas on which this proposal PKINIT is described in PKTAPP [4] and is based arose during
   discussions over several years between members of the SAAG, on concepts
    introduced in [5, 6]. For direct client-to-server authentication,
    the
   IETF-CAT working group, and client uses PKINIT to authenticate to the PSRG, regarding integration end server (instead
    of
   Kerberos and SPX.  Some ideas are drawn from the DASS system, and

   similar extensions have been discussed a central KDC), which then issues a ticket for use in DCE.  These
   changes are by no means endorsed by these groups. itself.  This is
    approach has an
   attempt to revive some of the goals of advantage over SSL [7] in that group, and the
   proposal approaches those goals primarily from the server does not
    need to save state (cache session keys).  Furthermore, an
    additional benefit is that Kerberos
   perspective. tickets can facilitate
    delegation (see [8]).


3. Initial authentication of users with public keys  Proposed Extensions

    This section describes the extensions to Version 5 of the Kerberos
   protocol that will support RFC 1510 for supporting the
    use of public key cryptography by
   users in the initial request for a ticket
    granting ticket.  

   Roughly speaking, ticket (TGT).

    In summary, the following changes to RFC 1510 are proposed:

        --> Users can initially may authenticate using either a public key pair or conventional
   (symmetric key) cryptography. After a KDC compromise, the KDC
   replies with an error message that informs the client of the new
   KDC public backup
            conventional (symmetric) key. Users must authenticate using  If public key cryptography in response to the error message. If applicable, the 
   client generates the new user secret key at this point as well. 

   Public key initial authentication is performed using either the 
   RSA encryption or Diffie Hellman
            used, public key algorithms. There data is 
   also an option to allow the user transported in preauthentication
            data fields to help establish identity.
        --> Users may store his/her private key 
   encrypted in the user password in keys on the KDC database; this option 
   solves the problem of transporting the user private key to
   different workstations. The combination of this option and the
   provision for conventional symmetric key authentication allows
   organizations to smoothly migrate to public key cryptography.

   This proposal will allow users either to use keys registered
   directly with the KDC, or to use keys already registered for use
   with X.509, PEM, or PGP, to obtain Kerberos credentials.  These
   credentials can then be used, as before, with application servers
   supporting Kerberos. Use of public key cryptography will not be a
   requirement for Kerberos, but if one's organization runs a KDC
   supporting public key, then users may choose to be registered with
   a public key pair, instead of or in addition to the current secret
   key.

   The application request and response between Kerberos clients and
   application servers will continue to be based on conventional
   cryptography, or will be converted to use user-to-user
   authentication.  There are performance issues and other reasons
   that servers may be better off using conventional cryptography.
   For this proposal, we feel that 80 percent of the benefits of
   integrating public key with retrieval during
            Kerberos can be attained for 20 percent
   of the effort, by addressing only initial authentication.

    This proposal does not preclude separate extensions.

   With these changes, users will be able to register public keys,
   only in realms that support public key, but they will still be able
   to perform initial authentication from a client that does not
   support public key. They will be able to use services registered in
   any realm. Furthermore, users registered with conventional keys
   will be able to use any client.

   This proposal addresses three two ways in which that users may use public key
    cryptography for initial authentication with Kerberos, with

   minimal change to the existing protocol. authentication.  Users may register keys
   directly with the KDC, present public
    key certificates, or they may present certificates by outside
   certification authorities (or certifications generate their own session key,
    signed by other users)
   attesting to the association of the public key with the named user. their digital signature key.  In both cases, either case, the end
    result is that the user obtains a
   conventional ticket granting ticket or conventional server ticket an ordinary TGT that may be used for
    subsequent authentication, with such
   subsequent authentication using only
    conventional cryptography.

   Additionally, users may also register a digital signature
   verification key with

    Section 3.1 provides definitions to help specify message formats.
    Section 3.2 and 3.3 describe the KDC.  We provide this option extensions for the
   licensing benefits, as well as a simpler variant of the two initial
    authentication exchange. However, this option relies on methods.  Section 3.3 describes a way for the client user to generate random keys.

   We first consider the case where the user's
    store and retrieve his private key is registered with on the KDC.

3.1


3.1.  Definitions

   Before we proceed, we will lay some groundwork definitions for
   encryption

    Hash and signatures.  We encryption types will be specified using ENCTYPE tags; we
    propose the following definitions addition of signature and encryption modes (and their corresponding values
   on the wire): following types:

        #define ENCTYPE_SIGN_MD5_RSA ENCTYPE_SIGN_DSA_GENERATE   0x0011
        #define ENCTYPE_SIGN_DSA_VERIFY     0x0012
        #define ENCTYPE_ENCRYPT_RSA_PRIV    0x0021
        #define ENCTYPE_ENCRYPT_RSA_PUB     0x0022

    allowing further modes signature types to be defined in the range 0x0011
    through 0x001f, and further encryption types to be defined accordingly. in the
    range 0x0021 through 0x002f.

    The extensions involve new preauthentication fields.  The
    preauthentication data types are in the range 17 through 21.
    These values are also specified along with their corresponding
    ASN.1 definition.

        #define PA-PK-AS-REQ                17
        #define PA-PK-AS-REP                18
        #define PA-PK-AS-SIGN               19
        #define PA-PK-KEY-REQ               20
        #define PA-PK-KEY-REP               21

    The extensions also involve new error types.  The new error types
    are in the range 227 through 229.  They are:

        #define KDC_ERROR_CLIENT_NOT_TRUSTED    227
        #define KDC_ERROR_KDC_NOT_TRUSTED       228
        #define KDC_ERROR_INVALID_SIG           229

    In the exposition below, we will use the notation E (T, K) to
   denote the following terms: encryption key,
    decryption key, signature key, verification key.  It should be
    understood that encryption and verification keys are essentially
    public keys, and decryption and signature keys are essentially
    private keys.  The fact that they are logically distinct does
    not preclude the assignment of data T, with key (or parameters) K.

   If E is ENCTYPE_SIGN_MD5_RSA, then

       E (T, K) = {T, RSAEncryptPrivate (MD5Hash (T), K)}

   If E is ENCTYPE_ENCRYPT_RSA_PRIV, then

       E (T, K) = RSAEncryptPrivate (T, K)

   Correspondingly, if E bitwise identical keys.


3.2.  Standard Public Key Authentication

    Implementation of the changes in this section is ENCTYPE_ENCRYPT_RSA_PUB, then

       E (T, K) = RSAEncryptPublic (T, K)


3.2 Initial request REQUIRED for user registered
    compliance with public key on KDC 

   In this scenario it pk-init.

    It is assumed that the user is registered with a all public key on the KDC.  The user's private key may be held keys are signed by the
   user, or it may be stored on the KDC, encrypted so some certification
    authority (CA).  The initial authentication request is sent as per
    RFC 1510, except that it cannot
   be used a preauthentication field containing data
    signed by the KDC.

3.2.1 User's private user's signature key is stored locally

   Implementation of accompanies the changes in this section is REQUIRED.


   In this section, we present request:

    PA-PK-AS-REQ ::- SEQUENCE {
                                -- PA TYPE 17
        signedPKAuth            [0] SignedPKAuthenticator,
        userCert                [1] SEQUENCE OF Certificate OPTIONAL,
                                    -- the basic Kerberos V5 pk-init protocol user's certificate
                                    -- optionally followed by that
                                    -- certificate's certifier chain
        trustedCertifiers       [2] SEQUENCE OF PrincipalName OPTIONAL
                                    -- CAs that all conforming implementations must support. The key features 
   of the protocol are: (1) easy, automatic (for the clients) recovery 
   after a KDC compromise, (2) the ability for a realm to support a
   mix of old and new Kerberos V5 clients with the new clients being a
   mix client trusts
    }

    SignedPKAuthenticator ::= SEQUENCE {
        pkAuth                  [0] PKAuthenticator,
        pkAuthSig               [1] Signature,
                                    -- of both public key and symmetric pkAuth
                                    -- using user's signature key configured clients, and
   (3) support
    }

    PKAuthenticator ::= SEQUENCE {
        cusec                   [0] INTEGER,
                                    -- for replay prevention
        ctime                   [1] KerberosTime,
                                    -- for replay prevention
        nonce                   [2] INTEGER,
                                    -- binds response to this request
        kdcName                 [3] PrincipalName,
        clientPubValue          [4] SubjectPublicKeyInfo OPTIONAL,
                                    -- for Diffie-Hellman (DH) key exchange as well as RSA
   public key encryption. The benefit algorithm
    }

    Signature ::= SEQUENCE {
        signedHash              [0] EncryptedData
                                    -- of having new clients being able
   to use either symmetric key or public type Checksum
                                    -- encrypted under signature key initial authentication is
   that it allows an organization to roll out the new clients
    }

    Checksum ::=   SEQUENCE {
        cksumtype               [0] INTEGER,
        checksum                [1] OCTET STRING
    }   -- as
   rapidly specified by RFC 1510

    SubjectPublicKeyInfo ::= SEQUENCE {
        algorithm               [0] algorithmIdentifier,
        subjectPublicKey        [1] BIT STRING
    }   -- as possible without having to be concerned about the need
   to purchase additional hardware to support the CPU intensive public
   key cryptographic operations. 

   In order to give a brief overview of the four protocols in this
   section, we now give diagrams of the protocols. We denote
   encryption of message M with key K specified by {M}K and the signature X.509 recommendation [9]

    Certificate ::= SEQUENCE {
        CertType                [0] INTEGER,
                                    -- type of
   message M with key K by [M]K. All messages from the KDC to the
   client are AS_REP messages unless denoted otherwise; similarly, all
   messages from the client to the KDC are AS_REQ messages unless
   denoted otherwise. Since only the padata fields are affected by
   this specification in the AS_REQ and AS_REP messages, we do not
   show the other fields. We first show the RSA encryption option in
   normal mode:
       
      certifier list, [cksum, time, nonce, kdcRealm, 
      kdcName]User PrivateKey
   C ------------------------------------------------------> KDC

      list of cert's, {[encReplyKey, nonce]KDC privkey}
      EncReplyTmpKey, {EncReplyTmpKey}Userpubkey
   C <------------------------------------------------------ KDC


   We now show RSA encryption in recovery mode:

      certifier list, [cksum, time, nonce, kdcRealm, 
      kdcName]User PrivateKey
   C ------------------------------------------------------> KDC


      KRB_ERROR (error code KDC_RECOVERY_NEEDED) 
                 error data: [nonce, algID (RSA), 
                 KDC PublicKey Kvno and PublicKey, KDC Salt]
                 Signed with KDC PrivateKey
   C <------------------------------------------------------ KDC


      certifier list, [cksum, time, nonce, kdcRealm, kdcName, 
      {newUserSymmKey, nonce}KDC public key]User PrivateKey
   C ------------------------------------------------------> KDC


      list of cert's, {[encReplyKey, nonce]KDC privkey}
      EncReplyTmpKey, {EncReplyTmpKey}Userpubkey
   C <------------------------------------------------------ KDC


   Next, we show Diffie Hellman in normal mode:

      certifier list, [cksum, time, nonce, kdcRealm, kdcName, 
      User DH public parameter]User PrivateKey
   C ------------------------------------------------------> KDC


      list of cert's, {encReplyKey, nonce}DH shared symmetric 
      key, [KDC DH public parameter]KDC Private Key
   C <------------------------------------------------------ KDC


   Finally, we show Diffie Hellman in recovery mode:

      certifier list, [cksum, time, nonce, kdcRealm, kdcName, 
      User DH public parameter]User PrivateKey
   C ------------------------------------------------------> KDC


      KRB_ERROR (error code KDC_RECOVERY_NEEDED)
                error data: [nonce, algID (DH), KDC DH public 
                             parameter, KDC DH ID, KDC PublicKey 
                             Kvno and PublicKey, KDC Salt]
                             Signed with KDC PrivateKey
   C <------------------------------------------------------ KDC


      certifier list, [cksum, time, nonce, kdcRealm, 
      kdcName, User DH public parameter, {newUserSymmKey, 
      nonce}DH shared key, KDC DH ID]User PrivateKey
   C ------------------------------------------------------> KDC


      list of cert's, {encReplyKey, nonce}DH shared 
      symmetric key
   C <------------------------------------------------------ KDC



   If the user stores his private key locally, the initial request 
   to the KDC for a ticket granting ticket proceeds according to 
   RFC 1510, except that a preauthentication field containing a 
   nonce signed by the user's private key is included.  The 
   preauthentication field may also include a list of the root 
   certifiers trusted by the user.

   PA-PK-AS-ROOT ::= SEQUENCE {
           rootCert[0]         SEQUENCE OF OCTET STRING,
           signedAuth[1]       SignedPKAuthenticator
   }

   SignedPKAuthenticator ::= SEQUENCE {
           authent[0]          PKAuthenticator,
           authentSig[1]       Signature
   }

   PKAuthenticator ::= SEQUENCE {
           cksum[0]            Checksum OPTIONAL,
           cusec[1]            INTEGER,
           ctime[2]            KerberosTime,
           nonce[3]            INTEGER,
           kdcRealm[4]         Realm,
           kdcName[5]          PrincipalName,
	   clientPubValue[6]   SubjectPublicKeyInfo OPTIONAL, 
                                  -- DH algorithm
	   recoveryData[7]     RecoveryData OPTIONAL          
                                  -- Recovery Alg.
   }

   RecoveryData ::= SEQUENCE {
           clientRecovData[0]  ClientRecovData, 
	   kdcPubValueId[1]    INTEGER OPTIONAL 
                                   -- DH algorithm, copied
                                   -- from KDC response     
   }

   ClientRecovData ::= CHOICE {
           newPrincKey[0]      EncryptedData, -- EncPaPkAsRoot
					      -- encrypted with 
                                              -- either KDC 
					      -- public key or 
                                              -- DH shared key   
           recovDoneFlag[1]    INTEGER        -- let KDC know that
                                              -- recovery is done
                                              -- when user uses a
                                              -- mix of clients or
                                              -- does not want to
                                              -- keep a symmetric
                                              -- key in the database
   }

   EncPaPkAsRoot ::= SEQUENCE {
           newSymmKey[0]       EncryptionKey  -- the principal's new certificate
                                    -- symmetric key
           nonce[1]            INTEGER 1 = X.509v3 (DER encoding)
                                    -- the same nonce as
                                              -- the one in the 
                                              -- PKAuthenticator  
   }

   Signature ::= SEQUENCE {
           sigType[0]          INTEGER,
           kvno[1]             INTEGER OPTIONAL,
           sigHash[2] 2 = PGP (per PGP draft)
        CertData                [1] OCTET STRING
   }

   Notationally, sigHash is then

       sigType (authent, userPrivateKey)

   where userPrivateKey is the user's private key (corresponding to the
   public key held in the user's database record). Valid sigTypes are
   thus far limited to the above-listed ENCTYPE_SIGN_MD5_RSA; we expect
   that other types may be listed (and given on-the-wire values between
   0x0011 and 0x001f).


   The format of each certificate depends on the particular service
   used.  (Alternatively, the KDC could send, with its reply, a
   sequence of certifications (see below), but since the KDC is likely
   to have more certifications than users have trusted root certifiers,
   we have chosen the first method.)  In the event that the client
   believes it already possesses the current public key of the KDC, a
   zero-length root-cert field is sent.

   The fields in the signed authenticator are the same as those in the
   Kerberos authenticator; in addition, we include a client-generated
   nonce, and the name of the KDC.  The structure is itself signed
   using the user's private key corresponding to the public key 
   registered with the KDC. We include the newSymmKey field so clients
   can generate a new symmetric key (for users, this key is based on
   a password and a salt value generated by the KDC) and
   confidentially send this key to the KDC during the recovery phase. 

   We now describe the recovery phase of the protocol. There is a bit
   associated with each principal in the database indicating whether
   recovery for that principal is necessary. After a KDC compromise,
   the KDC software is reloaded from backup media and a new backup
   KDC public/private pair is generated. The public half of this pair
   is then either made available to the KDC, or given to the
   appropriate certification authorities for certification. The private
   half is not made available to the KDC until after the next
   compromise clean-up. If clients are maintaining a copy of the KDC
   public key, they also have a copy of the backup public key.

   After the reload of KDC software, the bits associated with
   recovery of each principal are all set. The KDC clears the bit
   for each principal that undergoes the recovery phase. In addition,
   there is a bit associated with each principal to indicate whether
   there is a valid symmetric key in the database for the principal.
   These bits are all cleared after the reload of the KDC software
   (the old symmetric keys are no longer valid). Finally, there is a
   bit associated with each principal indicating whether that
   principal still uses non-public key capable clients. If a user
   principal falls into this category, a public key capable client
   cannot transparently re-establish a symmetric key for that user,
   since the older clients would not be able to compute the new
   symmetric key that includes hashing the password with a KDC
   supplied salt value. The re-establishment of the symmetric key 
   in this case is outside the scope of this protocol. 

   One method of re-establishing a symmetric key for public key
   capable clients is to generate a hash of the user password and a
   KDC supplied salt value. The KDC salt is changed after every
   compromise of the KDC. In the recovery protocol, if the principal
   does not still use old clients, the KDC supplied salt is sent to
   the client principal in a KRB_ERROR message with error code
   KDC_RECOVERY_NEEDED. The error data field of the message contains
   the following structure which is encoded into an octet string.


   PA-PK-KDC-ERR ::= CHOICE {
           recoveryDhErr      SignedDHError,   -- Used during recovery   
                                               -- when algorithm is DH 
                                               -- based
           recoveryPKEncErr   SignedPKEncError -- Used during recovery
                                               -- for PK encryption 
                                               -- (RSA,...)
   }

   SignedDHError ::= SEQUENCE {
           dhErr              DHError,
           dhErrSig           Signature
   }

   SignedPKEncError ::= SEQUENCE {
           pkEncErr           PKEncryptError,
           pkEncErrSig        Signature
   }

   DHError ::= SEQUENCE {
           nonce	      INTEGER,		     -- From AS_REQ
           algorithmId        INTEGER,               -- DH algorithm
           kdcPubValue        SubjectPublicKeyInfo,  -- DH algorithm
           kdcPubValueId      INTEGER,               -- DH algorithm
           kdcPublicKeyKvno   INTEGER OPTIONAL,      -- New KDC public
                                                     -- key kvno
           kdcPublicKey       OCTET STRING OPTIONAL, -- New KDC pubkey
	   kdcSalt            OCTET STRING OPTIONAL  -- If user uses 
                                                     -- only new
                                                     -- clients
   }

   PKEncryptError ::= SEQUENCE {
           nonce              INTEGER,               -- From AS_REQ
           algorithmId        INTEGER,               -- Public Key
                                                     -- encryption alg
           kdcPublicKeyKvno   INTEGER OPTIONAL,      -- New KDC public 
                                                     -- key kvno
           kdcPublicKey       OCTET STRING OPTIONAL, -- New KDC public
                                                     -- key
	   kdcSalt            OCTET STRING OPTIONAL  -- If user uses 
                                                     -- only new
                                                     -- clients
   }

   The KDC_RECOVERY_NEEDED error message is sent in response to a 
   client AS_REQ message if the client principal needs to be 
   recovered, unless the client AS_REQ contains the PKAuthenticator
   with a nonempty RecoveryData field (in this case the client has
   already received the KDC_RECOVERY_NEEDED error message. We will
   also see in section 3.2.2 that a different error response is
   sent by the KDC if the encrypted user private key is stored in
   the KDC database.) If the client principal uses only new clients, 
   then the kdcSalt field is returned; otherwise, the kdcSalt field
   is absent. 

   If the client uses the Diffie Hellman algorithm during the recovery
   phase then the DHError field contains the public Diffie Hellman 

   parameter (kdcPubValue) for the KDC along with an identifier 
   (kdcPubValueID). The client will then send this identifier to 
   the KDC in an AS_REQ message; the identifier allows the KDC to 
   look up the Diffie Hellman private value corresponding to the
   identifier. Depending on how often the KDC updates its private
   Diffie Hellman parameters, it will have to store anywhere between a
   handful and several dozen of these identifiers and their parameters.
   The KDC must send its Diffie Hellman public value to the client
   first so the client can encrypt its new symmetric key.

   In the case where the user principal does not need to be recovered
   and the user still uses old clients as well as new clients, the 
   KDC_ERR_NULL_KEY error is sent in response to symmetric AS_REQ 
   messages when there is no valid symmetric key in the KDC database. 
   This situation can occur if the user principal has been recovered 
   but no new symmetric key has been established in the database.
 
   In addition, the two error messages with error codes 
   KDC_ERR_PREAUTH_FAILED and KDC_ERR_PREAUTH_REQUIRED are modified 
   so the error data contains the kdcSalt encoded as an OCTET STRING. 
   The reason for the modification is to allow principals that use 
   new clients only to have their symmetric key transparently updated
   by the client software during the recovery phase. The kdcSalt is
   used to create the new symmetric key. As a performance optimization,
   the kdcSalt is stored in the /krb5/salt file along with the realm.
   Thus the /krb5/salt file consists of realm-salt pairs. If the file
   is missing, or the salt is not correct, the above error messages
   allow the client to find out the correct salt. New clients which 
   are configured for symmetric key authentication attempt to 
   preauthenticate with the salt from the /krb5/salt file as an 
   input into their key, and if the file is not present, the new client
   does not use preauthentication. The error messages above return
   either the correct salt to use, or no salt at all which indicates
   that the principal is still using old clients (the client software
   should use the existing mapping from the user password to the
   symmetric key).

   In order to assure interoperability between clients from different
   vendors and organizations, a standard algorithm is needed for
   creating the symmetric key from the principal password and kdcSalt.
   The algorithm for creating the symmetric key is as follows: take the
   SHA-1 hash of the kdcSalt concatenated with the principal password
   and use the 20 byte output as the input into the existing key
   generation process (string to key function). After a compromise, the
   KDC changes the kdcSalt; thus, the recovery algorithm allows users
   to obtain a new symmetric key without actually changing their
   password.

   The response from the KDC would be identical to the response in RFC
   1510, except that instead of being encrypted in the secret key
   shared by the client and the KDC, it is encrypted in a random key
   freshly generated by the KDC (of type ENCTYPE_ENC_CBC_CRC). A 
   preauthentication field (specified below) accompanies the response, 
   optionally containing a certificate with the public key for the KDC 
   (since we do not assume that the client knows this public key), and
   a package containing the secret key in which the rest of the 
   response is encrypted, along with the same nonce used in the rest
   of the response, in order to prevent replays. This package is itself

   signed with the private key of the KDC, then encrypted with the
   symmetric key that is returned encrypted in the public key of the
   user (or for Diffie Hellman, encrypted in the shared secret Diffie
   Hellman symmetric key). 

   Pictorially, in the public key encryption case we have:

   kdcCert, {[encReplyKey, nonce] Sig w/KDC 
   privkey}EncReplyTmpKey, {EncReplyTmpKey}Userpubkey

   Pictorially, in the Diffie Hellman case we have:

   kdcCert, {encReplyKey, nonce}DH shared symmetric key,
   [DH public value]Sig w/KDC privkey

   PA-PK-AS-REP ::= SEQUENCE {
           kdcCert[0]          SEQUENCE OF Certificate,
           encryptShell[1]     EncryptedData, 
                                           -- EncPaPkAsRepPartShell
                                           -- encrypted by 
                                           -- encReplyTmpKey or DH 
                                           -- shared symmetric key
           pubKeyExchange[2]   PubKeyExchange OPTIONAL, 
                                           -- a choice between 
                                           -- a KDC signed DH 
                                           -- value and a public 
                                           -- key encrypted 
                                           -- symmetric key.
                                           -- Not needed after
                                           -- recovery when
                                           -- DH is used.
   }                                         

   PubKeyExchange ::= CHOICE {
           signedDHPubVal      SignedDHPublicValue, 
           encryptKey          EncryptedData  
                                           -- EncPaPkAsRepTmpKey
                                           -- encrypted by 
                                           -- userPublicKey
   }

   SignedDHPublicValue ::= SEQUENCE {
           dhPublic[0]         SubjectPublicKeyInfo,
           dhPublicSig[1]      Signature
   }

   EncPaPkAsRepPartShell ::= SEQUENCE {
           encReplyPart[0]     EncPaPkAsRepPart,
           encReplyPartSig[1]  Signature OPTIONAL 
                                    -- encReplyPart
                                    -- signed by kdcPrivateKey
                                    -- except not present in 
                                    -- DH case
   }


   EncPaPkAsRepPart ::= SEQUENCE {
           encReplyKey[0]      EncryptionKey,
           nonce[1]            INTEGER,
   }

   EncPaPkAsRepTmpKey ::= SEQUENCE {
           encReplyTmpKey[0]   EncryptionKey
   }

   The kdc-cert specification is lifted, with slight modifications,
   from v3 of the X.509 certificate specification:

   Certificate ::= SEQUENCE {
           version[0]          Version DEFAULT v1 (1),
           serialNumber[1]     CertificateSerialNumber,
           signature[2]        AlgorithmIdentifier,
           issuer[3]           PrincipalName,
           validity[4]         Validity,
           subjectRealm[5]     Realm,
           subject[6]          PrincipalName,
           subjectPublicKeyInfo[7] SubjectPublicKeyInfo,
           issuerUniqueID[8]   IMPLICIT UniqueIdentifier OPTIONAL,
           subjectUniqueID[9]  IMPLICIT UniqueIdentifier OPTIONAL,
           authentSig[10]      Signature
   }

   The kdc-cert must have as its root certification one of the
   certifiers sent to the KDC with the original request.  If the KDC
   has no such certification, then it will instead reply with a
   KRB_ERROR of type KDC_ERROR_PREAUTH_FAILED.  If a zero-length
   root-cert was sent by the client as part of the PA-PK-AS-ROOT, then
   a correspondingly zero-length kdc-cert may be absent, in which case
   the client uses its copy of the KDC's public key. In the case of
   recovery, the client uses its copy of the backup KDC public key. 

   Upon receipt of the response from the KDC, the client will verify 
   the public key for the KDC from PA-PK-AS-REP preauthentication data 
   field. The certificate must certify the key as belonging to a
   principal whose name can be derived from the realm name.  If the
   certificate checks out, the client then decrypts the EncPaPkAsRepPart
   and verifies the signature of the KDC.  It then uses the random key
   contained therein to decrypt the rest of the response, and continues
   as per RFC 1510. Because there is direct trust between the user and
   the KDC, the transited field of the ticket returned by the KDC should
   remain empty. (Cf. Section 3.3.)

   Examples

   We now give several examples illustrating the protocols in this 
   section. Encryption of message M with key K is denoted {M}K and
   the signature of message M with key K is denoted [M]K.

   Example 1: The requesting user principal needs to be recovered and
   uses only new clients. The recovery algorithm is Diffie Hellman (DH).
   Then the exchange sequence between the user principal and the KDC is:


   
   Client  --------> AS_REQ (with or without preauth) --------> KDC

   Client  <--- KRB_ERROR (error code KDC_RECOVERY_NEEDED) <--- KDC
                error data: [nonce, algID (DH), KDC DH public parameter,
                            KDC DH ID, KDC PublicKey Kvno and PublicKey,
                            KDC Salt]Signed with KDC PrivateKey

   At this point, the client validates the KDC signature, checks to 
   see if the nonce is the same as the one in the AS_REQ, and stores
   the new KDC public key and public key version number. The client 
   then generates a Diffie Hellman private parameter and computes
   the corresponding Diffie Hellman public parameter; the client
   also computes the shared Diffie Hellman symmetric key using the
   KDC Diffie Hellman public parameter and its own Diffie Hellman 
   private parameter. Next, the client prompts the user for his/her
   password (if it does not already have the password). The password
   is concatenated with the KDC Salt and then SHA1 hashed; the 
   result is fed into the string to key function to obtain the new
   user DES key.

   The new user DES key will be encrypted (along with the AS_REQ
   nonce) using the Diffie Hellman symmetric key and sent to the 
   KDC in the new AS_REQ message:

   Client -> AS_REQ with preauth: rootCert, [PKAuthenticator with
             user DH public parameter, {newUser DES key, nonce}DH 
             symmetric key, KDC DH ID]Signed with User PrivateKey 
                                                        -> KDC

   The KDC DH ID is copied by the client from the KDC_ERROR message
   received above. Upon receipt and validation of this message, the
   KDC first uses the KDC DH ID as an index to locate its
   private Diffie Hellman parameter; it uses this parameter in 
   combination with the user public Diffie Hellman parameter
   to compute the symmetric Diffie Hellman key. The KDC checks
   if the encrypted nonce is the same as the one in the 
   PKAuthenticator and the AS_REQ part. The KDC then enters
   the new user DES key into the database, resets the recovery 
   needed bit, and sets the valid symmetric key in database
   bit. The KDC then creates the AS_REP message:

   Client <-- AS_REP with preauth: kdcCert, {encReplyKey,
              nonce}DH symmetric key <-------------------- KDC

   
   The AS_REP encrypted part is encrypted with the encReplyKey
   that is generated on the KDC. The nonces are copied from the
   client AS_REQ. The kdcCert is a sequence of certificates
   that have been certified by certifiers listed in the client
   rootCert field, unless a zero length rootCert field was sent.
   In the last case, the kdcCert will also have zero length.   

3.2.2. Private key held by KDC

   Implementation of the changes in this section is RECOMMENDED.


   When the user's private key is not carried with the user, the 
   user may encrypt the private key using conventional cryptography, 
   and register the encrypted private key with the KDC.  As
   described in the previous section, the SHA1 hash of the password
   concatenated with the kdcSalt is also stored in the KDC database
   if the user only uses new clients. We restrict users of this
   protocol to using new clients only. The reason for this restriction
   is that it is not secure to store both the user private key 
   encrypted in the user's password and the user password on the KDC 
   simultaneously.

   There are several options for storing private keys. STRING
                                    -- actual certificate
                                    -- type determined by CertType
    }

    Note: If the 
   user stores their private key on a removable disk, signature uses RSA keys, then it is 
   less convenient since they need to always carry be performed
    as per PKCS #1.

    The PKAuthenticator carries information to foil replay attacks,
    to bind the disk 
   around with them; in addition, request and response, and to optionally pass the procedures
    client's Diffie-Hellman public value (i.e. for extracting using DSA in
    combination with Diffie-Hellman).  The PKAuthenticator is signed
    with the private key may vary between different operating systems. 
   Alternatively, corresponding to the user can store a private public key on in the hard
   disks of systems that he/she uses; besides limiting
    certificate found in userCert (or cached by the 
   systems that KDC).

    In the user can login from there is also a 
   greater security risk to PKAuthenticator, the private key. If smart card 
   readers or slots are deployed in an organization, then client may specify the 
   user can store his/her private key on KDC name in one
    of two ways: 1) a smart card. Finally, Kerberos principal name, or 2) the user can store his/her private key encrypted name in the
    KDC's certificate (e.g., an X.500 name, or a password 
   on PGP name).  Note that
    case #1 requires that the KDC. This last option is probably certificate name and the most practical
   option currently; it Kerberos principal
    name be bound together (e.g., via an X.509v3 extension).

    The userCert field is important that a good password policy sequence of certificates, the first of which
    must be used.

   When the user's private public key is stored on certificate. Any subsequent
    certificates will be certificates of the KDC, 
   preauthentication is required. There are two cases depending on 
   whether certifiers of the requesting user principal needs to user's
    certificate.  These cerificates may be recovered. 

   In order to obtain its private key, a user principal includes used by the
   padata type PA-PK-AS-REQ in KDC to verify the preauthentication data
    user's public key.  This field of is empty if the AS_REQ message. KDC already has the
    user's certifcate.

    The accompanying pa-data trustedCertifiers field is:

   PA-PK-AS-REQ ::= SEQUENCE {
           algorithmId[0]       INTEGER,      -- Public Key Alg.
           encClientPubVal[1]   EncryptedData -- EncPaPkAsReqDH
                                              -- (encrypted with key
                                              -- K1)
   }

   EncPaPkAsReqDH ::= SEQUENCE {
           clientPubValue[0]    SubjectPublicKeyInfo 
   }

   Pictorially, PA-PK-AS-REQ is algorithmID, {clientPubValue}K1.

   The user principal sends its Diffie-Hellman public value encrypted contains a list of certification
    authorities trusted by the client, in the key K1. The key K1 is derived by performing string to key on case that the SHA1 hash client does
    not possess the KDC's public key certificate.

    Upon receipt of the user password concatenated AS_REQ with PA-PK-AS-REQ pre-authentication
    type, the kdcSalt 
   which is stored in the /krb5/salt file. If the file is absent, KDC attempts to verify the concatenation step user's certificate chain
    (userCert), if one is skipped provided in the above algorithm. The 
   Diffie Hellman parameters g and p are implied request.  This is done by
    verifying the algorithmID
   field. By choosing g and p correctly, dictionary attacks certification path against the key K1 can KDC's policy of
    legitimate certifiers.  This may be based on a certification
    hierarchy, or it may be made more difficult [Jaspan]. simply a list of recognized certifiers in a
    system like PGP.  If the requesting user principal needs recovery, certification path does not match one of
    the encrypted 
   user private key is stored in KDC's trusted certifiers, the KDC database, sends back an error message of
    type KDC_ERROR_CLIENT_NOT_TRUSTED, and it includes in the AS_REQ 
   RecoveryData error data
    field a list of its own trusted certifiers, upon which the client
    resends the request.

    If  trustedCertifiers is not present provided in the PKAuthenticator, then PA-PK-AS-REQ, the KDC replies with
    verifies that it has a KRB_ERROR message, with msg-type set to 
   KDC_ERR_PREAUTH_REQUIRED, and e-data set to:

   PA-PK-AS-INFO ::= SEQUENCE {
           signedDHErr         SignedDHError,         -- signed certificate issued by KDC
           encUserKey          OCTET STRING OPTIONAL  -- encrypted one of the certifiers
    trusted by
                                                      -- user password 
                                                      -- key; (recovery
                                                      -- response)

   }

   The user principal should then continue with the section 3.2.1.1
   protocol using client.  If it does not have a suitable certificate,
    the Diffie Hellman algorithm. 

   We now assume KDC returns an error message of type KDC_ERROR_KDC_NOT_TRUSTED
    to the client. 

    If a trust relationship exists, the KDC then verifies the client's
    signature on PKAuthenticator.  If that fails, the requesting user principal does not need
   recovery. 

   Upon receipt KDC returns an
    error message of type KDC_ERROR_INVALID_SIG.  Otherwise, the authentication request with KDC
    uses the PA-PK-AS-REQ, timestamp in the PKAuthenticator to assure that the request
    is not a replay.   The KDC generates also verifies that its name is specified
    in PKAuthenticator.

    Assuming no errors, the AS response KDC replies as defined in per RFC 1510, except that it
    encrypts the reply not with the user's key, but 
   additionally includes with a random key
    generated only for this particular response.  This random key
    is sealed in the preauthentication field of type 
   PA-PK-USER-KEY. 

   PA-PK-USER-KEY field:

    PA-PK-AS-REP ::= SEQUENCE {
                               -- PA TYPE 18
        kdcCert                 [0] SEQUENCE OF Certificate,
           encUserKeyPart     EncryptedData, Certificate OPTIONAL,
                                    -- EncPaPkUserKeyPart           
           kdcPrivKey         KDCPrivKey,
           kdcPrivKeySig      Signature
   }

   The kdc-cert field is identical to the KDC's certificate
                                    -- optionally followed by that in
                                    -- certificate's certifier chain
        encPaReply              [1] EncryptedData,
                                    -- of type PaReply
                                    -- using either the PA-PK-AS-REP
   preauthentication data field returned with client public
                                    -- key or the KDC response, and 
   must be validated as belonging Diffie-Hellman key
                                    -- specified by SignedDHPublicValue
        signedDHPublicValue     [2] SignedDHPublicValue OPTIONAL
    }


    PaReply ::= SEQUENCE {
        replyEncKeyPack         [0] ReplyEncKeyPack,
        replyEncKeyPackSig      [1] Signature,
                                    -- of replyEncKeyPack
                                    -- using KDC's signature key
    }

    ReplyEncKeyPack ::= SEQUENCE {
        replyEncKey             [0] EncryptionKey,
                                    -- used to encrypt main reply
        nonce                   [1] INTEGER
                                    -- binds response to the KDC request
                                    -- passed in the same manner.

   KDCPrivKey PKAuthenticator
    }

    SignedDHPublicValue ::= SEQUENCE {
           nonce	      INTEGER,		     -- From AS_REQ
           algorithmId        INTEGER,               -- DH algorithm
           kdcPubValue
        dhPublicValue           [0] SubjectPublicKeyInfo,
        dhPublicValueSig        [1] Signature
                                    -- DH algorithm
	   kdcSalt            OCTET STRING           -- Since user
                                                     -- uses only new of dhPublicValue
                                    -- clients using KDC's signature key
    }

    The KDCPrivKey kdcCert field is signed using a sequence of certificates, the KDC private key.
   The encrypted part first of which
    must have as its root certifier one of the AS_REP message is encrypted using certifiers sent to the 
   Diffie Hellman derived symmetric key, as is
    KDC in the EncPaPkUserKeyPart.

   EncPaPkUserKeyPart ::= SEQUENCE {
           encUserKey         OCTET STRING,
           nonce              INTEGER                -- From AS_REQ
   }

   Notationally, if encryption algorithm A is used, then enc-key-part
   is


       A ({encUserKey, nonce}, Diffie-Hellman-symmetric-key).

   If PA-PK-AS-REQ. Any subsequent certificates will be 
    certificates of the client has used an incorrect kdcSalt to compute certifiers of the
   key K1, then KDC's certificate.  These
    cerificates may be used by the client needs to resubmit the above AS_REQ
   message using the correct kdcSalt field from verify the KDCPrivKey
   field. KDC's public
    key.  This message contains field is empty if the encrypted private key that has been
   registered with client did not send to the KDC by the user, as encrypted by the user,
   super-encrypted with a
    list of trusted certifiers (the trustedCertifiers field was empty).
    
    Since each certifier in the Diffie Hellman derived symmetric key.
   Because there certification path of a user's
    certificate is direct trust between the user and essentially a separate realm, the KDC, name of each
    certifier shall be added to the transited field of the ticket returned by the KDC should remain 
   empty.  (Cf. Section 3.3.)

   Examples

   We now give several examples illustrating ticket.  The
    format of these realm names shall follow the protocols naming constraints set
    forth in RFC 1510 (sections 7.1 and 3.3.3.1).  Note that this 
   section.

   Example 1: The requesting user principal needs will
    require new nametypes to be recovered
   and stores his/her encrypted private key on the KDC. Then the 
   exchange sequence between the user principal defined for PGP certifiers and other
    types of realms as they arise.

    The KDC's certificate must bind the KDC is:

   Client  --------> AS_REQ (with or without preauth) -----> KDC

   Client  <--- KRB_ERROR (error code KDC_ERR_PREAUTH_REQUIRED)
                error data: [nonce, algID (DH), KDC DH public 
                            parameter, KDC DH ID, KDC PublicKey 
                            Kvno and PublicKey, KDC Salt]Signed 
                            with KDC PrivateKey, {user private 
                            key}user password <------------- KDC

   The protocol now continues with key to a name derivable
    from the second AS_REQ as in Example
   1 name of section 3.2.1.1.
   
   Example 2: The requesting user principal does not need to be 
   recovered and stores his/her encrypted private key on the realm for that KDC. 
   Then the exchange sequence between the user principal and the KDC 
   when  The client then extracts
    the user principal wants random key used to obtain his/her private encrypt the main reply.  This random key is:

   Client  -> AS_REQ (in
    encPaReply) is encrypted with preauth: algID, 
              {DH either the client's public parameter}K1 -> KDC

   The key K1 is generated by using the string to or
    with a key function 
   on the SHA1 hash of derived from the password concatenated with DH values exchanged between the kdcSalt
   from client
    and the /krb5/salt file. If KDC.


3.3.  Digital Signature

    Implementation of the file is absent, then changes in this section are OPTIONAL for
    compliance with pk-init.

    We offer this option with the concatenation step is skipped, and warning that it requires the client will learn to
    generate a random key; the correct kdcSalt in client may not be able to guarantee the following AS_REP message from
    same level of randomness as the KDC. The algID should indicate some type of Diffie Hellman
   algorithm.

   The KDC replies with

    If the AS_REP message with user registered a preauthentication
   data field:

   Client <-- AS_REP digital signature key with preauth: kdcCert, {encUserKey, <-- the KDC
              nonce}DH symmetric instead
    of an encryption key, [nonce, algID, DH
              public parameter, kdcSalt]KDC privateKey then a separate exchange must be used.  The
    client validates the KDC's signature and checks sends a request for a TGT as usual, except that
   the nonce matches the nonce in its AS_REQ message.
   If the kdcSalt does not match what the client used, it
   starts (rather
    than the protocol over. The client then uses KDC) generates the KDC
   Diffie Hellman public parameter along with its own Diffie
   Hellman private parameter random key that will be used to compute encrypt
    the Diffie Hellman 
   symmetric key. KDC response.  This key is used sent to decrypt the encUserKey
   field; KDC along with the client checks if
    request in a preauthentication field:

    PA-PK-AS-SIGN ::= SEQUENCE {
                                -- PA TYPE 19
        encSignedKeyPack        [0] EncryptedData
                                    -- of SignedKeyPack
                                    -- using the KDC's public key
    }

    SignedKeyPack ::= SEQUENCE {
        signedKey               [0] KeyPack,
        signedKeyAuth           [1] PKAuthenticator,
        signedKeySig            [2] Signature
                                    -- of signedKey.signedKeyAuth
                                    -- using user's signature key
    }

    KeyPack ::= SEQUENCE {
        randomKey               [0] EncryptionKey,
                                    -- will be used to encrypt reply
        nonce matches its AS_REQ
   nonce. At this point,                   [1] INTEGER
    }

    where the initial authentication protocol nonce is complete.  

   Example 3: The requesting user principal does not need to be 
   recovered and stores his/her encrypted private key on copied from the KDC.
   In this example, request.

    Upon receipt of the user principal uses PA-PK-AS-SIGN, the conventional
   symmetric key Kerberos V5 initial authentication protocol
   exchange. 

   We note that KDC decrypts then verifies
    the conventional protocol exposes randomKey.  It then replies as per RFC 1510, except that the
    reply is encrypted not with a password-derived user 
   password to dictionary attacks; therefore, key, but with
    the user password 
   must be changed more often. An example of when randomKey sent in the request.  Since the client already knows
    this protocol 
   would be used key, there is when new clients have been installed but an 
   organization has not phased in public key authentication for 
   all clients due no need to performance concerns.

   Client ----> AS_REQ accompany the reply with preauthentication: {time}K1 --> KDC

   Client <--------------------  AS_REP <------------------ KDC an extra
    preauthentication field.  The key K1 is derived transited field of the ticket should
    specify the certification path as described in Section 3.2.


3.4.  Retrieving the preceding two examples. 


3.3. Clients with a public key certified by an outside authority Private Key From the KDC

    Implementation of the changes in this section is OPTIONAL.

   In the case where RECOMMENDED for
    compliance with pk-init.

    When the client user's private key is not registered with the current
   KDC, stored local to the client is responsible for obtaining user, he may
    choose to store the private key (normally encrypted using a
    password-derived key) on
   its own. The client will request initial tickets from the KDC
   using KDC.  We provide this option to present
    the TGS exchange, but instead of performing
   preauthentication using a Kerberos ticket granting ticket, or user with an alternative to storing the PA-PK-AS-REQ that is used when the public private key is known on local
    disk at each machine where he expects to the KDC, the client performs preauthentication authenticate himself using
    pk-init.  It should be noted that it replaces the
   preauthentication data field added risk of type PA-PK-AS-EXT-CERT:

   PA-PK-AS-EXT-CERT ::= SEQUENCE {
           userCert[0]         SEQUENCE OF OCTET STRING,
           signedAuth[1]       SignedPKAuthenticator
   }

   where the user-cert specification depends on the type
    long-term storage of
   certificate that the user possesses.  In cases where the service
   has separate private key pairs for digital signature and for encryption,
   we recommend that the signature keys be used for on possibly many workstations
    with the purposes added risk of
   sending the preauthentication (and deciphering the response).


   The authenticator is the one used from the exchange in section
   3.2.1, except that it is signed using storing the private key corresponding
   to the public key in on the user-cert.

   The KDC will verify in a
    form vulnerable to brute-force attack.

    In order to obtain a private key, the client includes a
    preauthentication authenticator, and check field with the
   certification path against its own policy of legitimate certifiers.
   This may be based on a certification hierarchy, or simply AS-REQ message:

    PA-PK-KEY-REQ ::= SEQUENCE {
                                -- PA TYPE 20
        patimestamp             [0] KerberosTime OPTIONAL, 
                                    -- used to address replay attacks.
        pausec                  [1] INTEGER OPTIONAL,
                                    -- used to address replay attacks.
        nonce                   [2] INTEGER,
                                    -- binds the reply to this request
        privkeyID               [3] SEQUENCE OF KeyID OPTIONAL
                                    -- constructed as a list hash of
   recognized certifiers in
                                    -- public key corresponding to
                                    -- desired private key
    }

    KeyID ::= SEQUENCE {
        KeyIdentifier           [0] OCTET STRING
    }

    The client may request a system like PGP. specific private key by sending the
    corresponding ID.  If this field is left empty, then all
    private keys are returned.

    If all checks out, the KDC will issue Kerberos credentials, responds as described in 3.2,
   but with the names of all the certifiers in the certification path
   added to the transited field of the ticket, with a principal name
   taken from above
    sections, except that an additional preauthentication field,
    containing the certificate (this might be a long path for X.509, or a
   string like "John Q. Public <jqpublic@company.com>" if user's private key, accompanies the certificate
   was a PGP certificate.  The realm will identify reply:

    PA-PK-KEY-REP ::= SEQUENCE {
                                -- PA TYPE 21
        nonce                   [0] INTEGER,
                                    -- binds the kind of
   certificate and reply to the final certifier as follows:

       cert_type/final_certifier

   as in PGP/<endorser@company.com>.


3.4. Digital Signature

   Implementation request
        KeyData                 [1] SEQUENCE OF KeyPair
    }

    KeyPair ::= SEQUENCE {
        privKeyID               [0] OCTET STRING,
                                    -- corresponding to encPrivKey
        encPrivKey              [1] OCTET STRING
    }


3.4.1.  Additional Protection of the changes in this section is OPTIONAL. Retrieved Private Keys

    We offer this option with solicit discussion on the warning following proposal: that it requires the client
   process to generate a random DES key; this generation may not
   be able to guarantee the same level of randomness as the KDC.

   If a user registered a digital signature key pair with the KDC,
   a separate exchange may be used.  The client sends a KRB_AS_REQ 
   as described
    optionally include in section 3.2.2.  If its request additional data to encrypt the user's database record
   indicates that a digital signature key
    private key, which is to be used, then currently only protected by the
   KDC sends back a KRB_ERROR as in section 3.2.2.

   It user's
    password.  One possibility is assumed here that the signature key is stored on local disk.
   The client generates might generate a
    random key string of enctype ENCTYPE_DES_CBC_CRC,
   signs it using the signature key (otherwise the signature is
   performed as described in section 3.2.1), then encrypts the whole bits, encrypt it with the public key of the KDC.  This is returned KDC (as
    in the SignedKeyPack, but with a separate
   KRB_AS_REQ an ordinary OCTET STRING in a preauthentication place of type

   PA-PK-AS-SIGNED ::= SEQUENCE {
           signedKey[0]        EncryptedData -- PaPkAsSignedData
   }

   PaPkAsSignedData ::= SEQUENCE {
           signedKeyPart[0]    SignedKeyPart,
           signedKeyAuth[1]    PKAuthenticator,
           sig[2]              Signature
   }

   SignedKeyPart ::= SEQUENCE {
           encSignedKey[0]     EncryptionKey,
           nonce[1]            INTEGER
   }


   where the nonce is the one from
    an EncryptionKey), and include this with the request.  Upon receipt of the
   request, the  The KDC decrypts, then verifies the random key.  It then
   replies as per RFC 1510, except that instead of being encrypted
    XORs each returned key with this random bit string.  (If the password-derived DES key, the reply bit
    string is encrypted using too short, the randomKey sent by KDC could either return an error, or XOR
    the client.  Since returned key with a repetition of the client already knows bit string.)

    In order to make this key, there is no work, additional means of preauthentication
    need to accompany the reply with an extra
   preauthentication field.  Because there be devised in order to prevent attackers from simply
    inserting their own bit string.  One way to do this is direct trust between
   the user and the KDC, the transited field to store
    a hash of the ticket returned
   by password-derived key (the one used to encrypt the KDC should remain empty.  (Cf. Section 3.3.)

   In
    private key).  This hash is then used in turn to derive a second
    key (called the event that hash-key); the KDC database indicates that hash-key is used to encrypt an ASN.1
    structure containing the user 
   principal must be recovered, generated bit string and a nonce value
    that binds it to the PKAuthenticator does not 
   contain the RecoveryData field, request.

    Since the KDC will reply with the
   KDC_RECOVERY_NEEDED error. The user principal then sends
   another AS_REQ message that includes possesses the RecoveryData field
   in hash, it can generate the PKAuthenticator. The AS_REP message is hash-key and
    verify this (weaker) preauthentication, and yet cannot reproduce
    the same as
   in private key itself, since the basic Kerberos V5 protocol. hash is a one-way function.


4. Preauthentication Data Types  Logistics and Policy Issues

    We propose that the following preauthentication types solicit discussion on how clients and KDCs should be allocated
   for configured
    in order to determine which of the preauthentication data packages options described in this draft:

       #define KRB5_PADATA_ROOT_CERT     17  /* PA-PK-AS-ROOT */
       #define KRB5_PADATA_PUBLIC_REP    18  /* PA-PK-AS-REP */
       #define KRB5_PADATA_PUBLIC_REQ    19  /* PA-PK-AS-REQ */
       #define KRB5_PADATA_PRIVATE_REP   20  /* PA-PK-USER-KEY */
       #define KRB5_PADATA_PUBLIC_EXT    21  /* PA-PK-AS-EXT-CERT */
       #define KRB5_PADATA_PUBLIC_SIGN   22  /* PA-PK-AS-SIGNED */


5. Encryption Information

   For above (if any)
    should be used.  One possibility is to set the user's database
    record to indicate that authentication is to use public key cryptography used
    cryptography; this will not work, however, in direct registration, we
   used (in our implementation) the RSAREF library supplied with the
   PGP 2.6.2 release.  Encryption and decryption functions were
   implemented directly on top of the primitives made available
   therein, rather than event that the fully sealing operations in
    client needs to know before making the API.


6. initial request.

5.  Compatibility with One-Time Passcodes

    We solicit discussion on how the use of public key cryptography
   for initial authentication protocol changes proposed in this
    draft will interact with the proposed use of
   one time passwords one-time passcodes
    discussed in Internet Draft
   <draft-ietf-cat-kerberos-passwords-00.txt>.

7. draft-ietf-cat-kerberos-passwords-00.txt.


6.  Strength of Encryption and Signature Mechanisms Cryptographic Schemes

    In light of recent findings on the strengths strength of MD5 and various DES
   modes, DES,
    we solicit discussion on which modes encryption types to incorporate
    into the protocol changes.


7.  Bibliography

    [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication
    Service (V5).  Request for Comments: 1510

    [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
    for Computer Networks, IEEE Communications, 32(9):33-38.
    September 1994.

    [3] A. Medvinsky, M. Hur.  Addition of Kerberos Cipher Suites to
    Transport Layer Security (TLS).
    draft-ietf-tls-kerb-cipher-suites-00.txt

    [4] A. Medvinsky, M. Hur, B. Clifford Neuman.  Public Key Utilizing
    Tickets for Application Servers (PKTAPP).
    draft-ietf-cat-pktapp-00.txt

    [5] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos Using 
    Public Key Cryptography.  Symposium On Network and Distributed System 
    Security, 1997.

    [6] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction 
    Protocol.  In Proceedings of the USENIX Workshop on Electronic Commerce,
    July 1995.

    [7] Alan O. Freier, Philip Karlton and Paul C. Kocher.
    The SSL Protocol, Version 3.0 - IETF Draft. 

    [8] B.C. Neuman, Proxy-Based Authorization and Accounting for 
    Distributed Systems.  In Proceedings of the 13th International 
    Conference on Distributed Computing Systems, May 1993

    [9] ITU-T (formerly CCITT)
    Information technology - Open Systems Interconnection -
    The Directory: Authentication Framework Recommendation X.509
    ISO/IEC 9594-8


8.  Acknowledgements

    Some of the ideas on which this proposal 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
    proposal approaches those goals primarily from the Kerberos
    perspective.  Lastly, comments from groups working on similar ideas
    in DCE have been invaluable.


9.  Expiration Date

    This Internet-Draft draft expires on April 19, September 30, 1997.


9. Authors' Addresses

   B.


10.  Authors

    Clifford Neuman
   USC/Information Sciences Institute
   4676 Admiralty Way Suite 1001
   Marina del Rey, CA 90292-6695

   Phone: 310-822-1511
   EMail: bcn@isi.edu
    Brian Tung
   USC/Information
    USC Information Sciences Institute
    4676 Admiralty Way Suite 1001
    Marina del Rey, Rey CA 90292-6695
    Phone: 310-822-1511
   EMail: brian@isi.edu +1 310 822 1511
    E-mail: {bcn, brian}@isi.edu

    John Wray
    Digital Equipment Corporation
    550 King Street, LKG2-2/Z7
    Littleton, MA 01460
    Phone: 508-486-5210
   EMail: +1 508 486 5210
    E-mail: wray@tuxedo.enet.dec.com

   Jonathan Trostle

    Ari Medvinsky
    Matthew Hur
    CyberSafe Corporation
    1605 NW Sammamish Rd., Road Suite 310
   Issaquah,
    Issaquah WA 98027-5378
    Phone: 206-391-6000
   EMail: jonathan.trostle@cybersafe.com +1 206 391 6000
    E-mail: {ari.medvinsky, matt.hur}@cybersafe.com

    Jonathan Trostle
    Novell
    E-mail: jonathan.trostle@novell.com

----