view Side-By-Side changes

INTERNET-DRAFT                                         Clifford Neuman
draft-ietf-cat-kerberos-pk-init-01.txt
draft-ietf-cat-kerberos-pk-init-02.txt                      Brian Tung
Updates: RFC 1510                                                  ISI
expires December 7, 1996 April 19, 1997                                       John Wray
                                         Digital Equipment Corporation
						      Jonathan Trostle
						 CyberSafe Corporation


    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 at any time.  It is inappropriate to use  Internet-Drafts  as
   reference  material  or  to  cite them other than as ``work in pro-
   gress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Sha-
   dow 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-01.txt,
   draft-ietf-cat-kerberos-pk-init-02.txt, and expires December 7, 1996. April 19, 1997.
   Please send comments to the authors.


1. Abstract

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

2. Motivation

   Public key cryptography presents a means by which a principal may
   demonstrate possession of a key, without ever having divulged this
   key to anyone else.  In conventional cryptography, the encryption
   key and decryption key are either identical or can easily be
   derived from one another. In public key cryptography, however,
   neither the public key nor the private key can be derived from the
   other (although the private key RECORD may include the information
   required to generate BOTH keys). Hence, a message encrypted with a
   public key is private, since only the person possessing the private

   key can decrypt it; similarly, someone possessing 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 is true that messages
   encrypted using public key cryptography are actually encrypted with
   a conventional secret key, which is in turn encrypted using the
   public key pair, the secret key is also randomly generated and is
   hence not vulnerable to a dictionary attack.

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

   First, by allowing users to register public keys with the KDC lies in KDC, the ease of recovery
   KDC can be recovered much more easily in case the KDC event it is
   compromised. With Kerberos as it currently stands, compromise of
   the KDC is disastrous. All keys become known by the attacker 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 certifying
   creating a
   bogus key with ticket granting ticket for the KDC's private key.  However, all bogus
   certificates can be invalidated by revoking and changing user. When the
   KDC's public key.  Legitimate users have to re-certify their public
   keys with compromise
   is detected, the new KDC key, but the users's keys themselves do not
   need to can be changed. cleaned up and restored 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 he does have it may be desirable to change the key pair, since the
   private key is encrypted using a symmetric key derived from a
   password (as described below), and is can therefore be vulnerable to
   dictionary attack.
   Assuming attack if a good password policy, however, legitimate users policy is not used. 
   Alternatively, if the encrypting symmetric key has 56 bits, then it
   may also be
   allowed desirable to use change the old password for key pair after a limited time, solely for the
   purpose of changing short period
   due to the short key pair. length. The realm administrator is then KDC does not forced have access to re-key all users. the
   user's unencrypted private key.

   There are two important areas where public key cryptography will
   have immediate use: in the initial authentication of users
   registered with the KDC or using public key certificates from
   outside authorities, and to establish inter-realm keys 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 a separate proposal.

   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 are drawn from the DASS system, and

   similar extensions have been discussed for use in DCE.  These
   changes are by no means endorsed by these groups.  This is an
   attempt to revive some of the goals of that group, and the
   proposal approaches those goals primarily from the Kerberos
   perspective.

3. Initial authentication of users with public keys

   This section describes the extensions to Version 5 of the Kerberos
   protocol that will support the use of public key cryptography by
   users in the initial request for a ticket granting ticket.  This
   proposal is based on the implementation already made available;
   nevertheless, we solicit any comments on modifications or additions
   to the protocol description below.  

   Roughly speaking, the following changes to RFC 1510 are proposed:
       a.  The KDC's response is encrypted
   Users can initially authenticate using public key or conventional
   (symmetric key) cryptography. After a random nonce key,
           rather than KDC compromise, the user's secret key.
       b.  This random key accompanies KDC
   replies with an error message that informs the response in a
           preauthentication field, encrypted and signed using client of the new
   KDC public backup key. Users must authenticate using public key pairs of 
   cryptography in response to the user and error message. If applicable, the KDC.
   Certificate and message formats are also defined in 
   client generates the new user secret key at this section. point as well. 

   Public key initial authentication is performed using either the 
   RSA encryption or Diffie Hellman public key algorithms. There is 
   also an option to allow the user to store his/her private key 
   encrypted in the user password in 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 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, and but they will then only still be able
   to perform initial authentication from a client that supports does not
   support public key,
   although they 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 ways in which users may use public
   key cryptography for initial authentication with Kerberos, with

   minimal change to the existing protocol.  Users may register keys
   directly with the KDC, or they may present certificates by outside
   certification authorities (or certifications by other users)
   attesting to the association of the public key with the named user.
   In both cases, the end result is that the user obtains a
   conventional ticket granting ticket or conventional server ticket
   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 the KDC.  We provide this option for the
   licensing benefits, as well as a simpler variant of the initial
   authentication exchange. However, this option relies on the client
   to generate random keys.

   We first consider the case where the user's key is registered with
   the KDC.

3.1 Definitions

   Before we proceed, we will lay some groundwork definitions for
   encryption and signatures.  We propose the following definitions
   of signature and encryption modes (and their corresponding values
   on the wire):

       #define ENCTYPE_SIGN_MD5_RSA      0x0011

       #define ENCTYPE_ENCRYPT_RSA_PRIV  0x0021
       #define ENCTYPE_ENCRYPT_RSA_PUB   0x0022

   allowing further modes to be defined accordingly.

   In the exposition below, we will use the notation E (T, K) to
   denote the encryption 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 is ENCTYPE_ENCRYPT_RSA_PUB, then

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


3.2 Initial request for user registered with public key on KDC 

   In this scenario it is assumed that the user is registered with a
   public key on the KDC.  The user's private key may be held by the
   user, or it may be stored on the KDC, encrypted so that it cannot
   be used by the KDC.

3.2.1 User's private key is stored locally

   If

   Implementation of the user stores his private changes in this section is REQUIRED.


   In this section, we present the basic Kerberos V5 pk-init protocol
   that all conforming implementations must support. The key locally, features 
   of the initial request to protocol are: (1) easy, automatic (for the clients) recovery 
   after a KDC compromise, (2) the ability for a ticket granting ticket proceeds according realm to RFC 1510,
   except that a preauthentication field containing support a nonce signed by
   mix of old and new Kerberos V5 clients with the user's private new clients being a
   mix of both public key is included. and symmetric key configured clients, and
   (3) support for Diffie-Hellman (DH) key exchange as well as RSA
   public key encryption. The preauthentication field
   may also include benefit of having new clients being able
   to use either symmetric key or public key initial authentication is
   that it allows an organization to roll out the new clients as
   rapidly 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 list brief overview of the root certifiers trusted four protocols in this
   section, we now give diagrams of the protocols. We denote
   encryption of message M with key K by {M}K and 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] signature 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          PrincipalName,
	   clientPubValue[6]   SubjectPublicKeyInfo OPTIONAL, 
                                  -- DH algorithm
	   recoveryData[7]     RecoveryData OPTIONAL          
                                  -- Recovery Alg.
   }

   Signature

   RecoveryData ::= SEQUENCE {
           sigType[0]          INTEGER,
           kvno[1]
           clientRecovData[0]  ClientRecovData, 
	   kdcPubValueId[1]    INTEGER OPTIONAL,
           sigHash[2]          OCTET STRING OPTIONAL 
                                   -- DH algorithm, copied
                                   -- from KDC response     
   }

   Notationally, sigHash is then

       sigType (authent, userPrivateKey)

   where userPrivateKey is the user's private key (corresponding to the

   ClientRecovData ::= CHOICE {
           newPrincKey[0]      EncryptedData, -- EncPaPkAsRoot
					      -- encrypted with 
                                              -- either KDC 
					      -- public key held 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 
                                              -- symmetric key
           nonce[1]            INTEGER        -- the same nonce as
                                              -- the one in the 
                                              -- PKAuthenticator  
   }

   Signature ::= SEQUENCE {
           sigType[0]          INTEGER,
           kvno[1]             INTEGER OPTIONAL,
           sigHash[2]          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 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 reply,
   a sequence copy of certifications (see below), but since the backup KDC is likely
   to have more certifications than users have trusted root certifiers,
   we have chosen public key. 

   Upon receipt of the first method.)  In response from the event that KDC, the client
   believes it already possesses will verify 
   the current public key of for the KDC,
   a zero-length root-cert field is sent. KDC from PA-PK-AS-REP preauthentication data 
   field. The fields in the signed authenticator are certificate must certify the same key as those
   in the Kerberos authenticator; in addition, we include belonging to a client-
   generated nonce,
   principal whose name can be derived from the realm name.  If the
   certificate checks out, the client then decrypts the EncPaPkAsRepPart
   and verifies the name signature of the KDC.  The structure is itself
   signed using  It then uses the user's private random key corresponding
   contained therein to decrypt the public key
   registered with rest of the KDC.

   Typically, preauthentication using a secret key would not be included,
   but if included it may be ignored by response, and continues
   as per RFC 1510. Because there is direct trust between the KDC.  (We recommend that it
   not be included: even if user and
   the KDC, the transited field of the ticket returned by the KDC should ignore
   remain empty. (Cf. Section 3.3.)

   Examples

   We now give several examples illustrating the preauthentication,
   an attacker may not, protocols in this 
   section. Encryption of message M with key K is denoted {M}K and use an intercepted
   the signature of message M with key K is denoted [M]K.

   Example 1: The requesting user principal needs to guess the
   password off-line.) be recovered and
   uses only new clients. The response from recovery algorithm is Diffie Hellman (DH).
   Then the KDC would be identical to exchange sequence between the response in RFC 1510,
   except that instead of being encrypted in user principal and the secret key shared by 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 and validates the KDC, it KDC signature, checks to 
   see if the nonce is encrypted the same as the one in a random key freshly generated
   by the KDC (of type ENCTYPE_ENC_CBC_CRC).  A preauthentication field
   (specified below) accompanies AS_REQ, and stores
   the response, optionally containing new KDC public key and public key version number. The client 
   then generates a
   certificate with Diffie Hellman private parameter and computes
   the corresponding Diffie Hellman public parameter; the client
   also computes the shared Diffie Hellman symmetric key for using the
   KDC (since we do not assume
   that the client knows this Diffie Hellman public key), parameter and a package containing its own Diffie Hellman 
   private parameter. Next, the
   secret key in which client prompts the rest of user for his/her
   password (if it does not already have the response password). The password
   is encrypted, along concatenated with the same nonce used in the rest of KDC Salt and then SHA1 hashed; the response, in order to prevent
   replays.  This package 
   result is itself encrypted with fed into the private string to key of function to obtain the
   KDC, then new
   user DES key.

   The new user DES key will be encrypted (along with the public AS_REQ
   nonce) using the Diffie Hellman symmetric key of and sent to the user.

   PA-PK-AS-REP ::= SEQUENCE {
           kdcCert[0]          SEQUENCE OF Certificate,
           encryptShell[1]     EncryptedData, -- EncPaPkAsRepPartShell
                                              -- encrypted by encReplyTmpKey
           encryptKey[2]       EncryptedData  -- EncPaPkAsRepTmpKey
                                              -- encrypted by userPubliKey
   }

   EncPaPkAsRepPartShell ::= SEQUENCE {
           encReplyPart[0]     EncPaPkAsRepPart,
           encReplyPartSig[1]  Signature -- encReplyPart
                                         -- signed by kdcPrivateKey
   }

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

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

   Notationally, assume that encryptPack is encrypted (or signed) 
   KDC in the new AS_REQ message:

   Client -> AS_REQ with
   algorithm Ak, and that encryptShell is encrypted preauth: rootCert, [PKAuthenticator with algorithm Au.
   Then, encryptShell is

       Au (Ak ({encReplyKey, nonce}, kdcPrivateKey), userPublicKey)

   where kdcPrivateKey
             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's
   KDC first uses the KDC DH ID as an index to locate its
   private key, and userPublicKey is Diffie Hellman parameter; it uses this parameter in 
   combination with the
   user's user public Diffie Hellman parameter
   to compute the symmetric Diffie Hellman key. The kdc-cert specification KDC checks
   if the encrypted nonce 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 same as its root certification the one of in the certifiers
   sent to 
   PKAuthenticator and the AS_REQ part. The KDC with then enters
   the original request.  If new user DES key into the database, resets the recovery 
   needed bit, and sets the valid symmetric key in database
   bit. The KDC has no such
   certification, then it will instead reply 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 KRB_ERROR sequence of type
   KDC_ERROR_PREAUTH_FAILED.  If a zero-length root-cert was sent certificates
   that have been certified by certifiers listed in the client as part of the PA-PK-AS-ROOT, then
   rootCert field, unless a correspondingly zero-length
   kdc-cert may be absent, in which case zero length rootCert field was sent.
   In the client uses its copy of last case, the
   KDC's public key.

   Upon receipt kdcCert will also have zero length.   

3.2.2. Private key held by KDC

   Implementation of the response from changes in this section is RECOMMENDED.


   When the KDC, user's private key is not carried with the client will verify user, the
   public 
   user may encrypt the private key for using conventional cryptography, 
   and register the KDC from PA-PK-AS-REP preauthentication data field,
   The certificate must certify encrypted private key with the KDC.  As
   described in the key as belonging to a principal whose
   name can be derived from previous section, the realm name.  If SHA1 hash of the certificate checks
   out, password
   concatenated with the client then decrypts kdcSalt is also stored in the EncPaPkAsRepPart 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 of 
   encrypted in the user, user's password and verifies the signature of user password on the KDC.  It then uses KDC 
   simultaneously.

   There are several options for storing private keys. If the random 
   user stores their private key contained therein on a removable disk, it is 
   less convenient since they need to decrypt always carry the rest of disk 
   around with them; in addition, the response,
   and continues as per RFC 1510.  Because there is direct trust procedures for extracting 
   the key may vary between different operating systems. 
   Alternatively, the user and the KDC, can store a private key on the transited field hard
   disks of systems that he/she uses; besides limiting the ticket returned by 
   systems that the KDC should remain empty. (Cf. Section 3.3.)


3.2.2. Private user can login from there is also a 
   greater security risk to the private key. If smart card 
   readers or slots are deployed in an organization, then the 
   user can store his/her private key held by KDC

   Implementation of on a smart card. Finally, 
   the changes user can store his/her private key encrypted in this section a password 
   on the KDC. This last option is OPTIONAL. probably the most practical
   option currently; it is important that a good password policy 
   be used.

   When the user's private key is not carried with the user, the stored on the KDC, 
   preauthentication is required. There are two cases depending on 
   whether the requesting user principal needs to be recovered. 

   In order to obtain its private key, a user principal includes the
   padata type PA-PK-AS-REQ in the preauthentication data
   field of the AS_REQ message. The accompanying pa-data 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 may
   encrypt the private key using conventional cryptography, and register
   the principal sends its Diffie-Hellman public value encrypted private key with
   in the KDC. key K1. The MD5 hash of the DES key
   used K1 is derived by performing string to encrypt the private key must also be registered with on
   the KDC.

   We provide this option SHA1 hash of the user password concatenated with the warning that storing kdcSalt 
   which is stored in the private key
   on /krb5/salt file. If the KDC carries file is absent, 
   the risk of exposure concatenation step is skipped in case the KDC is compromised.
   If a suffiently good password is chosen to encrypt above algorithm. The 
   Diffie Hellman parameters g and p are implied by the key, then this
   password algorithmID
   field. By choosing g and p correctly, dictionary attacks against
   the key K1 can be used for a limited time to change the private key. made more difficult [Jaspan].


   If the requesting user wishes to authenticate himself without storing principal needs recovery, the encrypted 
   user private key on each local disk, then a safer, albeit possibly less practical,
   alternative is to use a smart card to store stored in the keys.

   When KDC database, and the user's private key AS_REQ 
   RecoveryData field is stored on not present in the KDC, PKAuthenticator, then 
   the KDC record
   will also indicate whether preauthentication is required before
   returning replies with 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 by KDC
           encUserKey          OCTET STRING OPTIONAL  -- encrypted by
                                                      -- user password 
                                                      -- key; (recovery
                                                      -- response)

   }

   The user principal should then continue with the key (we recommend section 3.2.1.1
   protocol using the Diffie Hellman algorithm. 

   We now assume that it be required).  If such
   preauthentication is required, when the initial requesting user principal does not need
   recovery. 

   Upon receipt of the authentication request is received, with the PA-PK-AS-REQ, 
   the KDC will respond with generates the AS response as defined in RFC 1510, but 
   additionally includes a KRB_ERROR message, with msg-type set
   to KDC_ERR_PREAUTH_REQUIRED, and e-data set to:

   PA-PK-AS-INFO preauthentication field of type 
   PA-PK-USER-KEY. 

   PA-PK-USER-KEY ::= SEQUENCE {
           kdcCert[0]
           kdcCert            SEQUENCE OF Certificate Certificate,
           encUserKeyPart     EncryptedData, -- EncPaPkUserKeyPart           
           kdcPrivKey         KDCPrivKey,
           kdcPrivKeySig      Signature
   }

   The kdc-cert field is identical to that in the PA-PK-AS-REP
   preauthentication data field returned with the KDC response, and 
   must be validated as belonging to the KDC in the same manner.

   Upon receipt

   KDCPrivKey ::= SEQUENCE {
           nonce	      INTEGER,		     -- From AS_REQ
           algorithmId        INTEGER,               -- DH algorithm
           kdcPubValue        SubjectPublicKeyInfo,  -- DH algorithm
	   kdcSalt            OCTET STRING           -- Since user
                                                     -- uses only new
                                                     -- clients
   }

   The KDCPrivKey field is signed using the KDC private key.
   The encrypted part of the KRB_ERROR AS_REP message with a PA-PK-AS-INFO field, is encrypted using the
   client will prompt 
   Diffie Hellman derived symmetric key, as is the user for 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 the password that was client has used an incorrect kdcSalt to
   encrypt the private key, derive compute the DES
   key K1, then the client needs to resubmit the above AS_REQ
   message using the correct kdcSalt field from the KDCPrivKey
   field. 

   This message contains the encrypted private key that password, has been
   registered with the KDC by the user, as encrypted by the user,
   super-encrypted with the Diffie Hellman derived symmetric key.
   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.

   Example 1: The requesting user principal needs to be recovered
   and stores his/her encrypted private key on the KDC. 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_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 the second AS_REQ as in Example
   1 of section 3.2.1.1.
   
   Example 2: The requesting user principal does not need to be 
   recovered and calculate stores his/her encrypted private key on the MD5 hash H1 of KDC. 
   Then the DES key.  The client then sends
   a request to exchange sequence between the KDC, which includes a timestamp user principal and a
   client-generated random secret key that will be used by the KDC
   to super-encrypt 
   when the encrypted user principal wants to obtain his/her private key before it is returned
   to the client.  This information is sent to the KDC in a subsequent is:

   Client  -> AS_REQ message in a preauthentication data field:

   PA-PK-AS-REQ ::= SEQUENCE {
           encHashShell[0]     EncryptedData -- EncPaPkAsReqShell
   }

   EncPaPkAsReqShell ::= SEQUENCE {
           encHashPart[0]      EncryptedData -- EncPaPkAsReqPart
   }

   EncPaPkAsReqPart ::= SEQUENCE {
           encHashKey[0]       EncryptionKey,
           nonce[1]            INTEGER
   }

   The EncPaPkAsReqPart is first encrypted with a DES preauth: algID, 
              {DH public parameter}K1 -> KDC

   The key K1, derived K1 is generated by string_to_key from using the string to key function 
   on the SHA1 hash H1 (with null salt), then encrypted
   again of the password concatenated with the KDC's public key kdcSalt
   from the certificate in the
   PA-PK-AS-INFO field of /krb5/salt file. If the error response.

   Notationally, if encryption algorithm A file is used for DES encryption,
   and Ak is used for the public key encryption, absent, then enc-shell is

       Ak (A ({encHashKey, nonce}, K1), kdcPublicKey)

   Upon receipt of the authentication request with 
   the PA-PK-AS-REQ, concatenation step is skipped, and the
   KDC verifies client will learn 
   the hash of correct kdcSalt in the user's DES encryption key by attempting
   to decrypt following AS_REP message from the EncPaPkAsReqPart
   KDC. The algID should indicate some type of the PA-PK-AS-REQ.  If decryption
   is successful, the Diffie Hellman
   algorithm.

   The KDC generates replies with the AS response as defined in
   RFC 1510, but additionally includes AS_REP message with a preauthentication field of type
   PA-PK-USER-KEY.  (This response will also be included
   data field:

   Client <-- AS_REP with preauth: kdcCert, {encUserKey, <-- KDC
              nonce}DH symmetric key, [nonce, algID, DH
              public parameter, kdcSalt]KDC privateKey


   The client validates the KDC's signature and checks that
   the nonce matches the nonce in response to its AS_REQ message.
   If the initial request without preauthentication if preauthentication is kdcSalt does not required for match what the user and client used, it
   starts the user's encrypted protocol over. The client then uses the KDC
   Diffie Hellman public parameter along with its own Diffie
   Hellman private parameter to compute the Diffie Hellman 
   symmetric key. This key is
   stored on used to decrypt the KDC.)

   PA-PK-USER-KEY ::= SEQUENCE {
           encUserKeyPart[0]   EncryptedData -- EncPaPkUserKeyPart
   }

   EncPaPkUserKeyPart ::= SEQUENCE {
           encUserKey[0]       OCTET STRING,
           nonce[1]            INTEGER
   }

   Notationally, encUserKey
   field; the client checks if encryption algorithm A is used, then enc-key-part the nonce matches its AS_REQ
   nonce. At this point, the initial authentication protocol
   is

       A ({encUserKey, nonce}, enc-hash-key)

   (where A could complete.  

   Example 3: The requesting user principal does not need to be null encryption).

   This message contains the 
   recovered and stores his/her encrypted private key that has been
   registered with on the KDC by KDC.
   In this example, the user, as encrypted by user principal uses the user,
   optionally super-encrypted with conventional
   symmetric key Kerberos V5 initial authentication protocol
   exchange. 

   We note that the enc-hash-key from conventional protocol exposes the PA-PK-AS-REQ
   message if preauthentication using that method was provided (otherwise, user 
   password to dictionary attacks; therefore, the EncryptedData should denote null encryption).  Note that since
   H1 is a one-way hash, it user password 
   must be changed more often. An example of when this protocol 
   would be used is when new clients have been installed but an 
   organization has not possible phased in public key authentication for one 
   all clients due to decrypt the
   message if one possesses H1 but not the DES performance concerns.

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

   Client <--------------------  AS_REP <------------------ KDC

   The key that H1 K1 is derived
   from.  Because there is direct trust between the user and the
   KDC, the transited field of the ticket returned by as in the KDC should
   remain empty.  (Cf. Section 3.3.) preceding two examples. 


3.3. Clients with a public key certified by an outside authority

   Implementation of the changes in this section is OPTIONAL.

   In the case where the client is not registered with the current
   KDC, the client is responsible for obtaining the private key on
   its own. The client will request initial tickets from the KDC
   using the TGS exchange, but instead of performing pre-authentication
   preauthentication using a Kerberos ticket granting ticket, or
   with the PA-PK-AS-REQ that is used when the public key is known
   to the KDC, the client performs preauthentication using the
   preauthentication data field 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 of
   certificate that the user possesses.  In cases where the service
   has separate key pairs for digital signature and for encryption,
   we recommend that the signature keys be used for the purposes 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 the private key corresponding
   to the public key in the user-cert.

   The KDC will verify the preauthentication authenticator, and check the
   certification path against its own policy of legitimate certifiers.
   This may be based on a certification hierarchy, or simply a list of
   recognized certifiers in a system like PGP.

   If all checks out, the KDC will issue Kerberos credentials, as 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 the certificate (this might be a long path for X.509, or a
   string like "John Q. Public <jqpublic@company.com>" if the certificate
   was a PGP certificate.  The realm will identify the kind of
   certificate and the final certifier as follows:

       cert_type/final_certifier

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


3.4. Digital Signature

   Implementation of the changes in this section is OPTIONAL.

   We offer this option with the warning 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 in section 3.2.2.  If the user's database record
   indicates that a digital signature key is to be used, then the
   KDC sends back a KRB_ERROR as in section 3.2.2.

   It is assumed here that the signature key is stored on local disk.
   The client generates a random key 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
   with the public key of the KDC.  This is returned with a separate
   KRB_AS_REQ in a preauthentication of type

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

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

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

   where the nonce is the one from the request.  Upon receipt of the
   request, the KDC decrypts, then verifies the random key.  It then
   replies as per RFC 1510, except that instead of being encrypted
   with the password-derived DES key, the reply is encrypted using
   the randomKey sent by the client.  Since the client already knows
   this key, there is no need to accompany the reply with an extra
   preauthentication field.  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.)

   In the event that the KDC database indicates that the user 
   principal must be recovered, and the PKAuthenticator does not 
   contain the RecoveryData field, the KDC will reply with the
   KDC_RECOVERY_NEEDED error. The user principal then sends
   another AS_REQ message that includes the RecoveryData field
   in the PKAuthenticator. The AS_REP message is the same as
   in the basic Kerberos V5 protocol. 


4. Preauthentication Data Types

   We propose that the following preauthentication types be allocated
   for the preauthentication data packages 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 the public key cryptography used 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 the fully sealing operations in the API.


6. Compatibility with One-Time Passcodes

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

7. Strength of Encryption and Signature Mechanisms

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



8. Expiration

   This Internet-Draft expires on December 7, 1996. April 19, 1997.


9. Authors' Addresses

   B. 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 Sciences Institute
   4676 Admiralty Way Suite 1001
   Marina del Rey, CA 90292-6695

   Phone: 310-822-1511
   EMail: brian@isi.edu

   John Wray
   Digital Equipment Corporation
   550 King Street, LKG2-2/Z7
   Littleton, MA 01460

   Phone: 508-486-5210
   EMail: wray@tuxedo.enet.dec.com

   Jonathan Trostle
   CyberSafe Corporation
   1605 NW Sammamish Rd., Suite 310
   Issaquah, WA 98027-5378

   Phone: 206-391-6000
   EMail: jonathan.trostle@cybersafe.com


----