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
   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
    cryptography include simplified key can be derived from management (from the
   other (although the private key RECORD may include Kerberos
    perspective) and the information
   required ability to generate BOTH keys). Hence, a message encrypted with a leverage existing and developing
    public key is private, since only the person possessing the private
   key can decrypt it; similarly, someone possessing the private certification infrastructures.

    Public key cryptography 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 be integrated into Kerberos in a
   pseudo-random number sequence.  While it
    of ways.  One is true that messages
   encrypted using public to to associate a key cryptography are actually encrypted pair with
   a conventional secret key, each realm, which
    can then be used to facilitate cross-realm authentication; this is in turn encrypted using
    the
   public key pair, the secret key is also randomly generated and topic of another draft proposal.  Another way 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 allow users
    with public key integration into Kerberos described in
   this document has three goals.

   First, by allowing users certificates to register public keys with use them in initial authentication.
    This is the KDC, concern of the
   KDC can be recovered much more easily current document.

    One of the guiding principles in the event it design of PKINIT is
   compromised. With Kerberos that
    changes should be as it currently stands, compromise of minimal as possible.  As a result, the KDC basic
    mechanism of PKINIT 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 as follows:  The user sends a request to Kerberized services. Third, we obtain the
   above benefits while maintaining the performance advantages of
   Kerberos over protocols
    KDC as before, except that if that user is to use only public key authentication.

   If users register public keys, compromise of
    cryptography in the KDC does not
   divulge their private key.  Compromise initial authentication step, his certificate
    accompanies the initial request, in the preauthentication fields.

    Upon receipt of security on this request, the KDC is
   still a problem, since an attacker can impersonate any user by
   creating verifies the certificate and
    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 for
   cross-realm authentication. This memo describes a method by which on the first of these can be done. KDC.

    The second case will PKINIT specification may also be the topic used 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 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 KDC for 20 percent
   of the effort, by addressing only retrieval during
            Kerberos 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 accordingly.

   In the exposition below, we will use the notation E (T, K) to
   denote in the range 0x0011
    through 0x001f, and further 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 types to be used by the KDC.

3.2.1 User's private key is stored locally

   Implementation of the changes defined in this section is REQUIRED.

   In this section, we present the basic Kerberos V5 pk-init protocol
   that all conforming implementations must support.
    range 0x0021 through 0x002f.

    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 extensions involve new Kerberos V5 clients with preauthentication fields.  The
    preauthentication data types are in the new clients being a
   mix of both public key and symmetric key configured clients, and
   (3) support for Diffie-Hellman (DH) key exchange as well as RSA
   public key encryption. 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 benefit of having extensions also involve new clients being able
   to use either symmetric key or public key initial authentication is
   that it allows an organization to roll out the error types.  The new clients as
   rapidly as possible without having to be concerned about the need
   to purchase additional hardware to support error types
    are in the CPU intensive public
   key cryptographic operations. 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 order to give a brief overview of the four protocols in this
   section, exposition below, we now give diagrams of use the protocols. We denote following terms: encryption of message M with key K by {M}K and the key,
    decryption key, signature of
   message M with key K by [M]K. All messages from the KDC to the
   client key, verification key.  It should be
    understood that encryption and verification keys are AS_REP messages unless denoted otherwise; similarly, all
   messages from the client to the KDC essentially
    public keys, and decryption and signature keys are AS_REQ messages unless
   denoted otherwise. Since only the padata fields essentially
    private keys.  The fact that they are affected by
   this specification in the AS_REQ and AS_REP messages, we do logically distinct does
    not
   show the other fields. We first show preclude 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 assignment of cert's, {encReplyKey, nonce}DH shared symmetric
      key, [KDC DH public parameter]KDC Private bitwise identical keys.

3.2.  Standard Public Key
   C <------------------------------------------------------ KDC

   Finally, we show Diffie Hellman Authentication

    Implementation of the changes 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 this section is REQUIRED for
    compliance with KDC PrivateKey
   C <------------------------------------------------------ KDC

      certifier list, [cksum, time, nonce, kdcRealm,
      kdcName, User DH pk-init.

    It is assumed that all 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 keys are signed by some certification
    authority (CA).  The initial authentication request
   to the KDC for a ticket granting ticket proceeds according to is sent as per
    RFC 1510, except that a preauthentication field containing a
   nonce data
    signed by the user's private signature key is included.  The
   preauthentication field may also include a list of the root
   certifiers trusted by accompanies the user.

   PA-PK-AS-ROOT ::= request:

    PA-PK-AS-REQ ::- SEQUENCE {
           rootCert[0]
                                -- PA TYPE 17
        signedPKAuth            [0] SignedPKAuthenticator,
        userCert                [1] SEQUENCE OF OCTET STRING,
           signedAuth[1]       SignedPKAuthenticator Certificate OPTIONAL,
                                    -- the user's certificate
                                    -- optionally followed by that
                                    -- certificate's certifier chain
        trustedCertifiers       [2] SEQUENCE OF PrincipalName OPTIONAL
                                    -- CAs that the client trusts
    }

    SignedPKAuthenticator ::= SEQUENCE {
           authent[0]
        pkAuth                  [0] PKAuthenticator,
           authentSig[1]       Signature
        pkAuthSig               [1] Signature,
                                    -- of pkAuth
                                    -- using user's signature key
    }

    PKAuthenticator ::= SEQUENCE {
           cksum[0]            Checksum OPTIONAL,
           cusec[1]
        cusec                   [0] INTEGER,
           ctime[2]
                                    -- for replay prevention
        ctime                   [1] KerberosTime,
           nonce[3]
                                    -- for replay prevention
        nonce                   [2] INTEGER,
           kdcRealm[4]         Realm,
           kdcName[5]
                                    -- binds response to this request
        kdcName                 [3] PrincipalName,
	   clientPubValue[6]
        clientPubValue          [4] SubjectPublicKeyInfo OPTIONAL,
                                    -- DH for Diffie-Hellman algorithm
	   recoveryData[7]     RecoveryData OPTIONAL
                                  -- Recovery Alg.
    }

   RecoveryData

    Signature ::= 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
        signedHash              [0] EncryptedData
                                    -- mix of clients or
                                              -- does not want to
                                              -- keep a symmetric type Checksum
                                    -- encrypted under signature key in the database
    }

   EncPaPkAsRoot

    Checksum ::=   SEQUENCE {
           newSymmKey[0]       EncryptionKey  -- the principal's new
                                              -- symmetric key
           nonce[1]            INTEGER
        cksumtype               [0] INTEGER,
        checksum                [1] OCTET STRING
    }   -- the same nonce as specified by RFC 1510

    SubjectPublicKeyInfo ::= SEQUENCE {
        algorithm               [0] algorithmIdentifier,
        subjectPublicKey        [1] BIT STRING
    }   -- as specified by the one in the
                                              -- PKAuthenticator
   }

   Signature X.509 recommendation [9]

    Certificate ::= SEQUENCE {
           sigType[0]
        CertType                [0] INTEGER,
           kvno[1]             INTEGER OPTIONAL,
           sigHash[2]
                                    -- type of certificate
                                    -- 1 = X.509v3 (DER encoding)
                                    -- 2 = PGP (per PGP draft)
        CertData                [1] OCTET STRING
                                    -- actual certificate
                                    -- type determined by CertType
    }

   Notationally, sigHash is

    Note: If the signature uses RSA keys, then

       sigType (authent, userPrivateKey)

   where userPrivateKey it 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). performed
    as per PKCS #1.

    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 PKAuthenticator carries information to have more certifications than users have trusted root certifiers,
   we have chosen the first method.)  In the event that foil replay attacks,
    to bind the client
   believes it already possesses request and response, and to optionally pass the current
    client's Diffie-Hellman 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; value (i.e. for using DSA in addition, we include a client-generated
   nonce, and the name of the KDC.
    combination with Diffie-Hellman).  The structure PKAuthenticator is itself signed
   using
    with the user's private key corresponding to the public key
   registered with the KDC. We include in 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
    certificate found in userCert (or cached by the KDC) and
   confidentially send this key to KDC).

    In the KDC during PKAuthenticator, the recovery phase.

   We now describe client may specify the recovery phase KDC name in one
    of the protocol. There is two ways: 1) a bit
   associated with each Kerberos principal name, or 2) the name in the database indicating whether
   recovery for that principal is necessary. After
    KDC's certificate (e.g., an X.500 name, or a KDC compromise, PGP name).  Note that
    case #1 requires that the KDC software is reloaded from backup media certificate name 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. Kerberos principal
    name be bound together (e.g., via an X.509v3 extension).

    The private
   half userCert field is not made available to the KDC until after the next
   compromise clean-up. If clients are maintaining a copy sequence of certificates, the KDC
   public key, they also have a copy first of which
    must be the backup user's public key.

   After the reload key certificate. Any subsequent
    certificates will be certificates of KDC software, the bits associated with
   recovery certifiers 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. user's
    certificate.  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 cerificates may be able to compute the new
   symmetric key that includes hashing used by 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 verify the user password and a
   KDC supplied salt value. The KDC salt
    user's public key.  This field is changed after every
   compromise of the KDC. In the recovery protocol, empty if the principal
   does not still use old clients, the KDC supplied salt is sent to already has the client principal in a KRB_ERROR message with error code
   KDC_RECOVERY_NEEDED.
    user's certifcate.

    The error data trustedCertifiers 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 list of certification
    authorities trusted by the KDC if the encrypted user private key is stored client, 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 case that the client uses the Diffie Hellman algorithm during the recovery
   phase then the DHError field contains does
    not possess the KDC's public Diffie Hellman
   parameter (kdcPubValue) for key certificate.

    Upon receipt of the KDC along AS_REQ with an identifier
   (kdcPubValueID). The client will then send this identifier to PA-PK-AS-REQ pre-authentication
    type, the KDC in an AS_REQ message; attempts to verify the identifier allows user's certificate chain
    (userCert), if one is provided in the KDC to
   look up request.  This is done by
    verifying the Diffie Hellman private value corresponding to certification path against the
   identifier. Depending KDC's policy of
    legitimate certifiers.  This may be based on how often the KDC updates its private
   Diffie Hellman parameters, a certification
    hierarchy, or it will have to store anywhere between may be simply a
   handful and several dozen list 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 recognized certifiers in a
    system like PGP.  If the user principal certification path does not need to be recovered
   and the user still uses old clients as well as new clients, match one of
    the
   KDC_ERR_NULL_KEY error is sent in response to symmetric AS_REQ
   messages when there is no valid symmetric key in KDC's trusted certifiers, 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 sends back an error codes
   KDC_ERR_PREAUTH_FAILED message of
    type KDC_ERROR_CLIENT_NOT_TRUSTED, and KDC_ERR_PREAUTH_REQUIRED are modified
   so it includes in 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
    field a list of its own trusted certifiers, upon which the client software during the recovery phase. The kdcSalt is
   used to create
    resends the new symmetric key. As a performance optimization,
   the kdcSalt request.

    If  trustedCertifiers is stored provided in the /krb5/salt file along with the realm.
   Thus PA-PK-AS-REQ, the /krb5/salt file consists KDC
    verifies that it has a certificate issued by one of realm-salt pairs. If the file
   is missing, or certifiers
    trusted by the salt is client.  If it does 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 have a suitable certificate,
    the /krb5/salt file as KDC returns 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 message of type KDC_ERROR_KDC_NOT_TRUSTED
    to the
   symmetric key).

   In order to assure interoperability between clients from different
   vendors and organizations, client.

    If a standard algorithm is needed for
   creating the symmetric key from trust relationship exists, the principal password and kdcSalt.
   The algorithm for creating KDC then verifies the symmetric key is as follows: take client's
    signature on PKAuthenticator.  If that fails, the
   SHA-1 hash KDC returns an
    error message 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, type KDC_ERROR_INVALID_SIG.  Otherwise, the KDC changes
    uses the kdcSalt; thus, timestamp in the recovery algorithm allows users PKAuthenticator to obtain assure that the request
    is not a new symmetric key without actually changing their
   password. replay.   The response from the KDC would be identical to the response also verifies that its name is specified
    in PKAuthenticator.

    Assuming no errors, the KDC replies as per RFC 1510, except that instead of being encrypted in the secret key
   shared by it
    encrypts the client and reply not with the KDC, it is encrypted in user's key, but with 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 only 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. particular response.  This package is itself
   signed with the private key of the KDC, then encrypted with the
   symmetric random key that
    is returned encrypted sealed 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 preauthentication field:

    PA-PK-AS-REP ::= SEQUENCE {
           kdcCert[0]
                               -- PA TYPE 18
        kdcCert                 [0] SEQUENCE OF Certificate,
           encryptShell[1]     EncryptedData, Certificate OPTIONAL,
                                    -- EncPaPkAsRepPartShell the KDC's certificate
                                    -- encrypted optionally followed by that
                                    -- encReplyTmpKey or DH
                                           -- shared symmetric key
           pubKeyExchange[2]   PubKeyExchange OPTIONAL,
                                           -- a choice between certificate's certifier chain
        encPaReply              [1] EncryptedData,
                                    -- a KDC signed DH of type PaReply
                                    -- value and a using either the client public
                                    -- key encrypted
                                           -- symmetric key.
                                           -- Not needed after
                                           -- recovery when
                                           -- DH is used.
   }

   PubKeyExchange ::= CHOICE {
           signedDHPubVal      SignedDHPublicValue,
           encryptKey          EncryptedData
                                           -- EncPaPkAsRepTmpKey or the Diffie-Hellman key
                                    -- encrypted specified by
                                           -- userPublicKey
   } SignedDHPublicValue ::= SEQUENCE {
           dhPublic[0]         SubjectPublicKeyInfo,
           dhPublicSig[1]      Signature
        signedDHPublicValue     [2] SignedDHPublicValue OPTIONAL
    }

   EncPaPkAsRepPartShell

    PaReply ::= SEQUENCE {
           encReplyPart[0]     EncPaPkAsRepPart,
           encReplyPartSig[1]  Signature OPTIONAL
                                    -- encReplyPart
        replyEncKeyPack         [0] ReplyEncKeyPack,
        replyEncKeyPackSig      [1] Signature,
                                    -- signed by kdcPrivateKey
                                    -- except not present in of replyEncKeyPack
                                    -- DH case using KDC's signature key
    }
   EncPaPkAsRepPart

    ReplyEncKeyPack ::= SEQUENCE {
           encReplyKey[0]
        replyEncKey             [0] EncryptionKey,
           nonce[1]            INTEGER,
                                    -- used to encrypt main reply
        nonce                   [1] INTEGER
                                    -- binds response to the request
                                    -- passed in the PKAuthenticator
    }

   EncPaPkAsRepTmpKey

    SignedDHPublicValue ::= SEQUENCE {
           encReplyTmpKey[0]   EncryptionKey
        dhPublicValue           [0] SubjectPublicKeyInfo,
        dhPublicValueSig        [1] Signature
                                    -- of dhPublicValue
                                    -- using KDC's signature key
    }

    The kdc-cert specification kdcCert field is lifted, with slight modifications,
   from v3 a sequence of certificates, 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 first of which
    must have as its root certification certifier one of the certifiers sent to the
    KDC with the original request.  If in the KDC
   has no such certification, then it PA-PK-AS-REQ. Any subsequent certificates will instead reply with a
   KRB_ERROR be
    certificates of type KDC_ERROR_PREAUTH_FAILED.  If a zero-length
   root-cert was sent by the client as part certifiers of the PA-PK-AS-ROOT, then
   a correspondingly zero-length kdc-cert KDC's certificate.  These
    cerificates may be absent, in which case used by the client uses its copy of to verify the KDC's public
    key. In  This field is empty if the case client did not send to the KDC a
    list of
   recovery, trusted certifiers (the trustedCertifiers field was empty).

    Since each certifier in the client uses its copy certification path of a user's
    certificate is essentially a separate realm, the backup KDC public key.

   Upon receipt name of each
    certifier shall be added to the response from transited field of the KDC, ticket.  The
    format of these realm names shall follow the client naming constraints set
    forth in RFC 1510 (sections 7.1 and 3.3.3.1).  Note that this will verify
   the public key
    require new nametypes to be defined for the KDC from PA-PK-AS-REP preauthentication data
   field. PGP certifiers and other
    types of realms as they arise.

    The KDC's certificate must certify bind the public key as belonging to a
   principal whose name can be derived derivable
    from the realm name.  If the
   certificate checks out, the client then decrypts the EncPaPkAsRepPart
   and verifies the signature name of the realm for that KDC.  It  The client then uses extracts
    the random key
   contained therein used 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 encrypt the protocols in this
   section. Encryption of message M with main reply.  This random key K (in
    encPaReply) is denoted {M}K and encrypted with either the signature of message M client's public key or
    with a 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 derived from the exchange sequence DH values exchanged between the user principal client
    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 KDC.

3.3.  Digital Signature

    Implementation of the changes in this section are OPTIONAL for
    compliance with KDC PrivateKey

   At pk-init.

    We offer this point, option with the client validates warning that it requires the KDC signature, checks client to
   see if
    generate a random key; the nonce is client may not be able to guarantee the
    same level of randomness as the one in the AS_REQ, and stores KDC.

    If the new KDC public key and public key version number. The client
   then generates user registered a Diffie Hellman private parameter and computes
   the corresponding Diffie Hellman public parameter; the client
   also computes the shared Diffie Hellman symmetric digital signature key using with the KDC Diffie Hellman public parameter and its own Diffie Hellman
   private parameter. Next, the instead
    of an encryption key, then a separate exchange must be used.  The
    client prompts the user sends a request for his/her
   password (if a TGT as usual, except that it does not already have the password). The password
   is concatenated with the KDC Salt and then SHA1 hashed; the
   result is fed into (rather
    than the string to key function to obtain KDC) generates the new
   user DES key.

   The new user DES random key that will be encrypted (along with the AS_REQ
   nonce) using used to encrypt
    the Diffie Hellman symmetric KDC response.  This key and is sent to the KDC along with the
    request in a preauthentication field:

    PA-PK-AS-SIGN ::= SEQUENCE {
                                -- PA TYPE 19
        encSignedKeyPack        [0] EncryptedData
                                    -- of SignedKeyPack
                                    -- using the new AS_REQ message:

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

   The KDC DH ID 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                   [1] INTEGER
    }

    where the nonce is copied by the client from the KDC_ERROR message
   received above. request.

    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 PA-PK-AS-SIGN, the same as the one in the
   PKAuthenticator and the AS_REQ part. The KDC decrypts then enters
   the new user DES key into the database, resets the recovery
   needed bit, and sets verifies
    the valid symmetric key in database
   bit. The KDC randomKey.  It then creates replies as per RFC 1510, except that the AS_REP message:

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

   The AS_REP encrypted part
    reply is encrypted not with a password-derived user key, but with
    the encReplyKey
   that is generated on randomKey sent in the KDC. The nonces are copied from request.  Since the client AS_REQ. The kdcCert already knows
    this key, there is a sequence of certificates
   that have been certified by certifiers listed in no need to accompany the client
   rootCert field, unless a zero length rootCert reply with an extra
    preauthentication field.  The transited field was sent.
   In of the last case, ticket should
    specify the certification path as described in Section 3.2.

3.4.  Retrieving the kdcCert will also have zero length.

3.2.2. Private key held by Key From the KDC

    Implementation of the changes in this section is RECOMMENDED. RECOMMENDED for
    compliance with pk-init.

    When the user's private key is not carried with stored local to the user, the
   user he may encrypt
    choose to store the private key using conventional cryptography,
   and register the (normally encrypted private key with using a
    password-derived key) on 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 provide this restriction
   is that it is not secure option to store both the user private key
   encrypted in the user's password and present
    the user password on the KDC
   simultaneously.

   There are several options for with an alternative to storing private keys. If the
   user stores their private key on a removable disk, it is
   less convenient since they need to always carry the local
    disk
   around with them; in addition, the procedures for extracting at each machine where he expects to authenticate himself using
    pk-init.  It should be noted that it replaces the key may vary between different operating systems.
   Alternatively, added risk of
    long-term storage of the user can store a private key on possibly many workstations
    with the hard
   disks of systems that he/she uses; besides limiting the
   systems that the user can login from there is also a
   greater security added risk to the private key. If smart card
   readers or slots are deployed in an organization, then of storing the
   user can store his/her private key on a smart card. Finally, the user can store his/her private key encrypted KDC in a password
   on the KDC. This last option is probably the most practical
   option currently; it is important that a good password policy
   be used.

   When the user's private key is stored on the KDC,
   preauthentication is required. There are two cases depending on
   whether the requesting user principal needs
    form vulnerable to be recovered. brute-force attack.

    In order to obtain its a private key, a user principal includes the
   padata type PA-PK-AS-REQ in the client includes a
    preauthentication data field of with the AS_REQ message. The accompanying pa-data field is:

   PA-PK-AS-REQ AS-REQ message:

    PA-PK-KEY-REQ ::= SEQUENCE {
           algorithmId[0]       INTEGER,
                                -- Public Key Alg.
           encClientPubVal[1]   EncryptedData PA TYPE 20
        patimestamp             [0] KerberosTime OPTIONAL,
                                    -- EncPaPkAsReqDH used to address replay attacks.
        pausec                  [1] INTEGER OPTIONAL,
                                    -- (encrypted with key used to address replay attacks.
        nonce                   [2] INTEGER,
                                    -- 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
   in binds the key K1. The key K1 is derived by performing string reply to key on
   the SHA1 this request
        privkeyID               [3] SEQUENCE OF KeyID OPTIONAL
                                    -- constructed as a hash of the user password concatenated with the kdcSalt
   which is stored in the /krb5/salt file. If the file is absent,
   the concatenation step is skipped in the above algorithm. The
   Diffie Hellman parameters g and p are implied by the algorithmID
   field. By choosing g and p correctly, dictionary attacks against
   the
                                    -- public key K1 can be made more difficult [Jaspan].

   If the requesting user principal needs recovery, the encrypted
   user corresponding to
                                    -- desired private key is stored in the KDC database, and the AS_REQ
   RecoveryData field is not present in the PKAuthenticator, then
   the KDC replies with a KRB_ERROR message, with msg-type set to
   KDC_ERR_PREAUTH_REQUIRED, and e-data set to:

   PA-PK-AS-INFO
    }

    KeyID ::= SEQUENCE {
           signedDHErr         SignedDHError,         -- signed by KDC
           encUserKey
        KeyIdentifier           [0] OCTET STRING OPTIONAL  -- encrypted by
                                                      -- user password
                                                      -- key; (recovery
                                                      -- response)
    }

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

   We now assume that the requesting user principal does not need
   recovery.

   Upon receipt of the authentication client may request with a specific private key by sending the PA-PK-AS-REQ,
    corresponding ID.  If this field is left empty, then all
    private keys are returned.

    If all checks out, the KDC generates the AS response responds as defined in RFC 1510, but
   additionally includes a preauthentication field of type
   PA-PK-USER-KEY.

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

   The kdc-cert field is identical to that described in the PA-PK-AS-REP above
    sections, except that an additional preauthentication data field returned with the KDC response, and
   must be validated as belonging to field,
    containing the KDC in user's private key, accompanies the same manner.

   KDCPrivKey reply:

    PA-PK-KEY-REP ::= SEQUENCE {
           nonce	      INTEGER,
                                -- From AS_REQ
           algorithmId PA TYPE 21
        nonce                   [0] INTEGER,
                                    -- DH algorithm
           kdcPubValue        SubjectPublicKeyInfo,  -- DH algorithm
	   kdcSalt            OCTET STRING           -- Since user
                                                     -- uses only new
                                                     -- clients
   }

   The KDCPrivKey field is signed using binds the KDC private key.
   The encrypted part of the AS_REP message is encrypted using the
   Diffie Hellman derived symmetric key, as is reply to the EncPaPkUserKeyPart.

   EncPaPkUserKeyPart request
        KeyData                 [1] SEQUENCE OF KeyPair
    }

    KeyPair ::= SEQUENCE {
           encUserKey
        privKeyID               [0] 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 client has used an incorrect kdcSalt corresponding to compute encPrivKey
        encPrivKey              [1] OCTET STRING
    }

3.4.1.  Additional Protection of Retrieved Private Keys

    We solicit discussion on the
   key K1, then following proposal: that the client needs may
    optionally include in its request additional data to resubmit the above AS_REQ
   message using the correct kdcSalt field from the KDCPrivKey
   field.

   This message contains encrypt the encrypted
    private key that has been
   registered with the KDC by the user, as encrypted key, which is currently only protected by the user,
   super-encrypted with the Diffie Hellman derived symmetric key.
   Because there user's
    password.  One possibility is direct trust between the user and the KDC, that the
   transited field client might generate a
    random string of bits, encrypt it with the ticket returned by public key of the KDC should remain
   empty.  (Cf. Section 3.3.)

   Examples

   We now give several examples illustrating the protocols (as
    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 SignedKeyPack, but with the second AS_REQ as an ordinary OCTET STRING in Example
   1 place 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 KDC.
   Then the exchange sequence between the user principal
    an EncryptionKey), and include this with the request.  The KDC
   when the user principal wants to obtain his/her private then
    XORs each returned key is:

   Client  -> AS_REQ with preauth: algID,
              {DH public parameter}K1 -> KDC

   The key K1 is generated by using this random bit string.  (If the bit
    string to key function
   on the SHA1 hash of the password concatenated with the kdcSalt
   from the /krb5/salt file. If the file is absent, then
   the concatenation step is skipped, and the client will learn
   the correct kdcSalt in the following AS_REP message from too short, the
   KDC. The algID should indicate some type of Diffie Hellman
   algorithm.

   The KDC replies with could either return an error, or XOR
    the AS_REP message returned key with a preauthentication
   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 its AS_REQ message.
   If the kdcSalt does not match what the client used, it
   starts the protocol over. The client then uses the KDC
   Diffie Hellman public parameter along with its own Diffie
   Hellman private parameter to compute repetition of the Diffie Hellman
   symmetric key. This key is used bit string.)

    In order to decrypt the encUserKey
   field; the client checks if the nonce matches its AS_REQ
   nonce. At make this point, the initial authentication protocol
   is complete.

   Example 3: The requesting user principal does not work, additional means of preauthentication
    need to be
   recovered and stores his/her encrypted private key on the KDC.
   In this example, the user principal uses the conventional
   symmetric key Kerberos V5 initial authentication protocol
   exchange.

   We note that the conventional protocol exposes the user
   password devised in order to dictionary attacks; therefore, the user password
   must be changed more often. An example of when prevent attackers from simply
    inserting their own bit string.  One way to do this protocol
   would be used is when new clients have been installed but an
   organization has not phased in public key authentication for
   all clients due to performance concerns.

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

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

   The key K1 is derived as in the preceding two examples.

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

   Implementation hash 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 password-derived key on
   its own. The client will request initial tickets from the KDC
   using the TGS exchange, but instead of performing
   preauthentication using a Kerberos ticket granting ticket, or
   with the PA-PK-AS-REQ that is (the one used when to encrypt the public key
    private key).  This hash is known then used in turn 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 derive a second
    key pairs for digital signature and for encryption,
   we recommend that the signature keys be used for (called the purposes of
   sending hash-key); the preauthentication (and deciphering the response).

   The authenticator hash-key is the one used from the exchange in section
   3.2.1, except that it is signed using the private key corresponding to encrypt an ASN.1
    structure containing the public key in the user-cert.

   The KDC will verify the preauthentication authenticator, generated bit string 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 nonce value
    that binds it to the transited field of the ticket, with a principal name
   taken from request.

    Since the certificate (this might be a long path for X.509, or a
   string like "John Q. Public <jqpublic@company.com>" if KDC possesses the certificate
   was a PGP certificate.  The realm will identify hash, it can generate the kind of
   certificate hash-key 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
    verify this option with (weaker) preauthentication, and yet cannot reproduce
    the warning that it requires private key itself, since the client
   process to generate hash is a random DES key; this generation may not one-way function.

4.  Logistics and Policy Issues

    We solicit discussion on how clients and KDCs should be able configured
    in order to guarantee the same level determine which of randomness as the KDC.

   If a user registered a digital signature key pair with the KDC,
   a separate exchange may options described above (if any)
    should be used.  The client sends a KRB_AS_REQ
   as described in section 3.2.2.  If  One possibility is to set 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 indicate 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 authentication is
   performed as described in section 3.2.1), then encrypts the whole
   with the to use 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,
           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
    cryptography; 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 not work, however, in the basic Kerberos V5 protocol.

4. Preauthentication Data Types

   We propose event that the following preauthentication types be allocated
   for
    client needs to know before making 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 */ initial request.

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 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