INTERNET-DRAFT Clifford Neuman draft-ietf-cat-kerberos-pk-init-02.txt Brian Tung Updates: RFC 1510 ISI expires 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-02.txt, and expires April 19, 1997. Please send comments to the authors. 1. Abstract This document defines extensions to the Kerberos protocol 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 public key integration into Kerberos described in this document has three goals. First, by allowing users to register public keys with the KDC, the KDC can be recovered much more easily in the 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 creating a ticket granting ticket for the user. When the compromise is detected, the KDC can be 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 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 can therefore be vulnerable to dictionary attack if a good password policy is not used. Alternatively, if the encrypting symmetric key has 56 bits, then it may also be desirable to change the key pair after a short period due to the short key length. The KDC does not have access to 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. Roughly speaking, the following changes to RFC 1510 are proposed: Users can initially authenticate using public key 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 key. Users must authenticate using 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 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, 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 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 Implementation of the 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 features of the protocol are: (1) easy, automatic (for the clients) recovery after a KDC compromise, (2) the ability for a realm to support a mix of old and new Kerberos V5 clients with the new clients being a mix 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. The 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 brief overview of the four protocols in this section, we now give diagrams of the protocols. We denote encryption of message M with key K by {M}K and the 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, clientPubValue[6] SubjectPublicKeyInfo OPTIONAL, -- DH algorithm recoveryData[7] RecoveryData OPTIONAL -- Recovery Alg. } RecoveryData ::= SEQUENCE { clientRecovData[0] ClientRecovData, kdcPubValueId[1] INTEGER OPTIONAL -- DH algorithm, copied -- from KDC response } ClientRecovData ::= CHOICE { newPrincKey[0] EncryptedData, -- EncPaPkAsRoot -- encrypted with -- either KDC -- public key or -- DH shared key recovDoneFlag[1] INTEGER -- let KDC know that -- recovery is done -- when user uses a -- mix of clients or -- does not want to -- keep a symmetric -- key in the database } EncPaPkAsRoot ::= SEQUENCE { newSymmKey[0] EncryptionKey -- the principal's new -- 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 its reply, a sequence of certifications (see below), but since the KDC is likely to have more certifications than users have trusted root certifiers, we have chosen the first method.) In the event that the client believes it already possesses the current public key of the KDC, a zero-length root-cert field is sent. The fields in the signed authenticator are the same as those in the Kerberos authenticator; in addition, we include a client-generated nonce, and the name of the KDC. The structure is itself signed using the user's private key corresponding to the public key registered with the KDC. We include the newSymmKey field so clients can generate a new symmetric key (for users, this key is based on a password and a salt value generated by the KDC) and confidentially send this key to the KDC during the recovery phase. We now describe the recovery phase of the protocol. There is a bit associated with each principal in the database indicating whether recovery for that principal is necessary. After a KDC compromise, the KDC software is reloaded from backup media and a new backup KDC public/private pair is generated. The public half of this pair is then either made available to the KDC, or given to the appropriate certification authorities for certification. The private half is not made available to the KDC until after the next compromise clean-up. If clients are maintaining a copy of the KDC public key, they also have a copy of the backup public key. After the reload of KDC software, the bits associated with recovery of each principal are all set. The KDC clears the bit for each principal that undergoes the recovery phase. In addition, there is a bit associated with each principal to indicate whether there is a valid symmetric key in the database for the principal. These bits are all cleared after the reload of the KDC software (the old symmetric keys are no longer valid). Finally, there is a bit associated with each principal indicating whether that principal still uses non-public key capable clients. If a user principal falls into this category, a public key capable client cannot transparently re-establish a symmetric key for that user, since the older clients would not be able to compute the new symmetric key that includes hashing the password with a KDC supplied salt value. The re-establishment of the symmetric key in this case is outside the scope of this protocol. One method of re-establishing a symmetric key for public key capable clients is to generate a hash of the user password and a KDC supplied salt value. The KDC salt is changed after every compromise of the KDC. In the recovery protocol, if the principal does not still use old clients, the KDC supplied salt is sent to the client principal in a KRB_ERROR message with error code KDC_RECOVERY_NEEDED. The error data field of the message contains the following structure which is encoded into an octet string. PA-PK-KDC-ERR ::= CHOICE { recoveryDhErr SignedDHError, -- Used during recovery -- when algorithm is DH -- based recoveryPKEncErr SignedPKEncError -- Used during recovery -- for PK encryption -- (RSA,...) } SignedDHError ::= SEQUENCE { dhErr DHError, dhErrSig Signature } SignedPKEncError ::= SEQUENCE { pkEncErr PKEncryptError, pkEncErrSig Signature } DHError ::= SEQUENCE { nonce INTEGER, -- From AS_REQ algorithmId INTEGER, -- DH algorithm kdcPubValue SubjectPublicKeyInfo, -- DH algorithm kdcPubValueId INTEGER, -- DH algorithm kdcPublicKeyKvno INTEGER OPTIONAL, -- New KDC public -- key kvno kdcPublicKey OCTET STRING OPTIONAL, -- New KDC pubkey kdcSalt OCTET STRING OPTIONAL -- If user uses -- only new -- clients } PKEncryptError ::= SEQUENCE { nonce INTEGER, -- From AS_REQ algorithmId INTEGER, -- Public Key -- encryption alg kdcPublicKeyKvno INTEGER OPTIONAL, -- New KDC public -- key kvno kdcPublicKey OCTET STRING OPTIONAL, -- New KDC public -- key kdcSalt OCTET STRING OPTIONAL -- If user uses -- only new -- clients } The KDC_RECOVERY_NEEDED error message is sent in response to a client AS_REQ message if the client principal needs to be recovered, unless the client AS_REQ contains the PKAuthenticator with a nonempty RecoveryData field (in this case the client has already received the KDC_RECOVERY_NEEDED error message. We will also see in section 3.2.2 that a different error response is sent by the KDC if the encrypted user private key is stored in the KDC database.) If the client principal uses only new clients, then the kdcSalt field is returned; otherwise, the kdcSalt field is absent. If the client uses the Diffie Hellman algorithm during the recovery phase then the DHError field contains the public Diffie Hellman parameter (kdcPubValue) for the KDC along with an identifier (kdcPubValueID). The client will then send this identifier to the KDC in an AS_REQ message; the identifier allows the KDC to look up the Diffie Hellman private value corresponding to the identifier. Depending on how often the KDC updates its private Diffie Hellman parameters, it will have to store anywhere between a handful and several dozen of these identifiers and their parameters. The KDC must send its Diffie Hellman public value to the client first so the client can encrypt its new symmetric key. In the case where the user principal does not need to be recovered and the user still uses old clients as well as new clients, the KDC_ERR_NULL_KEY error is sent in response to symmetric AS_REQ messages when there is no valid symmetric key in the KDC database. This situation can occur if the user principal has been recovered but no new symmetric key has been established in the database. In addition, the two error messages with error codes KDC_ERR_PREAUTH_FAILED and KDC_ERR_PREAUTH_REQUIRED are modified so the error data contains the kdcSalt encoded as an OCTET STRING. The reason for the modification is to allow principals that use new clients only to have their symmetric key transparently updated by the client software during the recovery phase. The kdcSalt is used to create the new symmetric key. As a performance optimization, the kdcSalt is stored in the /krb5/salt file along with the realm. Thus the /krb5/salt file consists of realm-salt pairs. If the file is missing, or the salt is not correct, the above error messages allow the client to find out the correct salt. New clients which are configured for symmetric key authentication attempt to preauthenticate with the salt from the /krb5/salt file as an input into their key, and if the file is not present, the new client does not use preauthentication. The error messages above return either the correct salt to use, or no salt at all which indicates that the principal is still using old clients (the client software should use the existing mapping from the user password to the symmetric key). In order to assure interoperability between clients from different vendors and organizations, a standard algorithm is needed for creating the symmetric key from the principal password and kdcSalt. The algorithm for creating the symmetric key is as follows: take the SHA-1 hash of the kdcSalt concatenated with the principal password and use the 20 byte output as the input into the existing key generation process (string to key function). After a compromise, the KDC changes the kdcSalt; thus, the recovery algorithm allows users to obtain a new symmetric key without actually changing their password. The response from the KDC would be identical to the response in RFC 1510, except that instead of being encrypted in the secret key shared by the client and the KDC, it is encrypted in a random key freshly generated by the KDC (of type ENCTYPE_ENC_CBC_CRC). A preauthentication field (specified below) accompanies the response, optionally containing a certificate with the public key for the KDC (since we do not assume that the client knows this public key), and a package containing the secret key in which the rest of the response is encrypted, along with the same nonce used in the rest of the response, in order to prevent replays. This package is itself signed with the private key of the KDC, then encrypted with the symmetric key that is returned encrypted in the public key of the user (or for Diffie Hellman, encrypted in the shared secret Diffie Hellman symmetric key). Pictorially, in the public key encryption case we have: kdcCert, {[encReplyKey, nonce] Sig w/KDC privkey}EncReplyTmpKey, {EncReplyTmpKey}Userpubkey Pictorially, in the Diffie Hellman case we have: kdcCert, {encReplyKey, nonce}DH shared symmetric key, [DH public value]Sig w/KDC privkey PA-PK-AS-REP ::= SEQUENCE { kdcCert[0] SEQUENCE OF Certificate, encryptShell[1] EncryptedData, -- EncPaPkAsRepPartShell -- encrypted by -- encReplyTmpKey or DH -- shared symmetric key pubKeyExchange[2] PubKeyExchange OPTIONAL, -- a choice between -- a KDC signed DH -- value and a public -- key encrypted -- symmetric key. -- Not needed after -- recovery when -- DH is used. } PubKeyExchange ::= CHOICE { signedDHPubVal SignedDHPublicValue, encryptKey EncryptedData -- EncPaPkAsRepTmpKey -- encrypted by -- userPublicKey } SignedDHPublicValue ::= SEQUENCE { dhPublic[0] SubjectPublicKeyInfo, dhPublicSig[1] Signature } EncPaPkAsRepPartShell ::= SEQUENCE { encReplyPart[0] EncPaPkAsRepPart, encReplyPartSig[1] Signature OPTIONAL -- encReplyPart -- signed by kdcPrivateKey -- except not present in -- DH case } EncPaPkAsRepPart ::= SEQUENCE { encReplyKey[0] EncryptionKey, nonce[1] INTEGER, } EncPaPkAsRepTmpKey ::= SEQUENCE { encReplyTmpKey[0] EncryptionKey } The kdc-cert specification is lifted, with slight modifications, from v3 of the X.509 certificate specification: Certificate ::= SEQUENCE { version[0] Version DEFAULT v1 (1), serialNumber[1] CertificateSerialNumber, signature[2] AlgorithmIdentifier, issuer[3] PrincipalName, validity[4] Validity, subjectRealm[5] Realm, subject[6] PrincipalName, subjectPublicKeyInfo[7] SubjectPublicKeyInfo, issuerUniqueID[8] IMPLICIT UniqueIdentifier OPTIONAL, subjectUniqueID[9] IMPLICIT UniqueIdentifier OPTIONAL, authentSig[10] Signature } The kdc-cert must have as its root certification one of the certifiers sent to the KDC with the original request. If the KDC has no such certification, then it will instead reply with a KRB_ERROR of type KDC_ERROR_PREAUTH_FAILED. If a zero-length root-cert was sent by the client as part of the PA-PK-AS-ROOT, then a correspondingly zero-length kdc-cert may be absent, in which case the client uses its copy of the KDC's public key. In the case of recovery, the client uses its copy of the backup KDC public key. Upon receipt of the response from the KDC, the client will verify the public key for the KDC from PA-PK-AS-REP preauthentication data field. The certificate must certify the key as belonging to a principal whose name can be derived from the realm name. If the certificate checks out, the client then decrypts the EncPaPkAsRepPart and verifies the signature of the KDC. It then uses the random key contained therein to decrypt the rest of the response, and continues as per RFC 1510. Because there is direct trust between the user and the KDC, the transited field of the ticket returned by the KDC should remain empty. (Cf. Section 3.3.) Examples We now give several examples illustrating the protocols in this section. Encryption of message M with key K is denoted {M}K and the signature of message M with key K is denoted [M]K. Example 1: The requesting user principal needs to be recovered and uses only new clients. The recovery algorithm is Diffie Hellman (DH). Then the exchange sequence between the user principal and the KDC is: Client --------> AS_REQ (with or without preauth) --------> KDC Client <--- KRB_ERROR (error code KDC_RECOVERY_NEEDED) <--- KDC error data: [nonce, algID (DH), KDC DH public parameter, KDC DH ID, KDC PublicKey Kvno and PublicKey, KDC Salt]Signed with KDC PrivateKey At this point, the client validates the KDC signature, checks to see if the nonce is the same as the one in the AS_REQ, and stores the new KDC public key and public key version number. The client then generates a Diffie Hellman private parameter and computes the corresponding Diffie Hellman public parameter; the client also computes the shared Diffie Hellman symmetric key using the KDC Diffie Hellman public parameter and its own Diffie Hellman private parameter. Next, the client prompts the user for his/her password (if it does not already have the password). The password is concatenated with the KDC Salt and then SHA1 hashed; the result is fed into the string to key function to obtain the new user DES key. The new user DES key will be encrypted (along with the AS_REQ nonce) using the Diffie Hellman symmetric key and sent to the KDC in the new AS_REQ message: Client -> AS_REQ with preauth: rootCert, [PKAuthenticator with user DH public parameter, {newUser DES key, nonce}DH symmetric key, KDC DH ID]Signed with User PrivateKey -> KDC The KDC DH ID is copied by the client from the KDC_ERROR message received above. Upon receipt and validation of this message, the KDC first uses the KDC DH ID as an index to locate its private Diffie Hellman parameter; it uses this parameter in combination with the user public Diffie Hellman parameter to compute the symmetric Diffie Hellman key. The KDC checks if the encrypted nonce is the same as the one in the PKAuthenticator and the AS_REQ part. The KDC then enters the new user DES key into the database, resets the recovery needed bit, and sets the valid symmetric key in database bit. The KDC then creates the AS_REP message: Client <-- AS_REP with preauth: kdcCert, {encReplyKey, nonce}DH symmetric key <-------------------- KDC The AS_REP encrypted part is encrypted with the encReplyKey that is generated on the KDC. The nonces are copied from the client AS_REQ. The kdcCert is a sequence of certificates that have been certified by certifiers listed in the client rootCert field, unless a zero length rootCert field was sent. In the last case, the kdcCert will also have zero length. 3.2.2. Private key held by KDC Implementation of the changes in this section is RECOMMENDED. When the user's private key is not carried with the user, the user may encrypt the private key using conventional cryptography, and register the encrypted private key with the KDC. As described in the previous section, the SHA1 hash of the password concatenated with the kdcSalt is also stored in the KDC database if the user only uses new clients. We restrict users of this protocol to using new clients only. The reason for this restriction is that it is not secure to store both the user private key encrypted in the user's password and the user password on the KDC simultaneously. There are several options for storing private keys. If the user stores their private key on a removable disk, it is less convenient since they need to always carry the disk around with them; in addition, the procedures for extracting the key may vary between different operating systems. Alternatively, the user can store a private key on 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 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 on a smart card. Finally, the user can store his/her private key encrypted 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 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 principal sends its Diffie-Hellman public value encrypted in the key K1. The key K1 is derived by performing string to key on the SHA1 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 key K1 can be made more difficult [Jaspan]. If the requesting user principal needs recovery, the encrypted user 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 ::= 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 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 request with the PA-PK-AS-REQ, the KDC generates the AS response 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 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. 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 AS_REP message is encrypted using the Diffie Hellman derived symmetric key, as is the EncPaPkUserKeyPart. EncPaPkUserKeyPart ::= SEQUENCE { encUserKey OCTET STRING, nonce INTEGER -- From AS_REQ } Notationally, if encryption algorithm A is used, then enc-key-part is A ({encUserKey, nonce}, Diffie-Hellman-symmetric-key). If the client has used an incorrect kdcSalt to compute the 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 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 stores his/her encrypted private key on the KDC. Then the exchange sequence between the user principal and the KDC when the user principal wants to obtain his/her private key is: Client -> AS_REQ with preauth: algID, {DH public parameter}K1 -> KDC The key K1 is generated by using the 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 the KDC. The algID should indicate some type of Diffie Hellman algorithm. The KDC replies with the AS_REP message 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 the Diffie Hellman symmetric key. This key is used to decrypt the encUserKey field; the client checks if the nonce matches its AS_REQ nonce. At this point, the initial authentication protocol is complete. Example 3: The requesting user principal does not 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 to dictionary attacks; therefore, the 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 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 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 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 " 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/. 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, 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 . 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 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