diff options
Diffstat (limited to 'doc/standardisation/draft-ietf-cat-kerberos-pk-init-02.txt')
| -rw-r--r-- | doc/standardisation/draft-ietf-cat-kerberos-pk-init-02.txt | 1120 |
1 files changed, 0 insertions, 1120 deletions
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-02.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-02.txt deleted file mode 100644 index 1a15ae33e..000000000 --- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-02.txt +++ /dev/null @@ -1,1120 +0,0 @@ -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 <jqpublic@company.com>" if the certificate - was a PGP certificate. The realm will identify the kind of - certificate and the final certifier as follows: - - cert_type/final_certifier - - as in PGP/<endorser@company.com>. - - -3.4. Digital Signature - - Implementation of the changes in this section is OPTIONAL. - - We offer this option with the warning that it requires the client - process to generate a random DES key; this generation may not - be able to guarantee the same level of randomness as the KDC. - - If a user registered a digital signature key pair with the KDC, - a separate exchange may be used. The client sends a KRB_AS_REQ - as described in section 3.2.2. If the user's database record - indicates that a digital signature key is to be used, then the - KDC sends back a KRB_ERROR as in section 3.2.2. - - It is assumed here that the signature key is stored on local disk. - The client generates a random key of enctype ENCTYPE_DES_CBC_CRC, - signs it using the signature key (otherwise the signature is - performed as described in section 3.2.1), then encrypts the whole - with the public key of the KDC. This is returned with a separate - KRB_AS_REQ in a preauthentication of type - - PA-PK-AS-SIGNED ::= SEQUENCE { - signedKey[0] EncryptedData -- PaPkAsSignedData - } - - PaPkAsSignedData ::= SEQUENCE { - signedKeyPart[0] SignedKeyPart, - signedKeyAuth[1] PKAuthenticator, - sig[2] Signature - } - - SignedKeyPart ::= SEQUENCE { - encSignedKey[0] EncryptionKey, - nonce[1] INTEGER - } - - where the nonce is the one from the request. Upon receipt of the - request, the KDC decrypts, then verifies the random key. It then - replies as per RFC 1510, except that instead of being encrypted - with the password-derived DES key, the reply is encrypted using - the randomKey sent by the client. Since the client already knows - this key, there is no need to accompany the reply with an extra - preauthentication field. Because there is direct trust between - the user and the KDC, the transited field of the ticket returned - by the KDC should remain empty. (Cf. Section 3.3.) - - In the event that the KDC database indicates that the user - principal must be recovered, and the PKAuthenticator does not - contain the RecoveryData field, the KDC will reply with the - KDC_RECOVERY_NEEDED error. The user principal then sends - another AS_REQ message that includes the RecoveryData field - in the PKAuthenticator. The AS_REP message is the same as - in the basic Kerberos V5 protocol. - - -4. Preauthentication Data Types - - We propose that the following preauthentication types be allocated - for the preauthentication data packages described in this draft: - - #define KRB5_PADATA_ROOT_CERT 17 /* PA-PK-AS-ROOT */ - #define KRB5_PADATA_PUBLIC_REP 18 /* PA-PK-AS-REP */ - #define KRB5_PADATA_PUBLIC_REQ 19 /* PA-PK-AS-REQ */ - #define KRB5_PADATA_PRIVATE_REP 20 /* PA-PK-USER-KEY */ - #define KRB5_PADATA_PUBLIC_EXT 21 /* PA-PK-AS-EXT-CERT */ - #define KRB5_PADATA_PUBLIC_SIGN 22 /* PA-PK-AS-SIGNED */ - - -5. Encryption Information - - For the public key cryptography used in direct registration, we - used (in our implementation) the RSAREF library supplied with the - PGP 2.6.2 release. Encryption and decryption functions were - implemented directly on top of the primitives made available - therein, rather than the fully sealing operations in the API. - - -6. Compatibility with One-Time Passcodes - - We solicit discussion on how the use of public key cryptography - for initial authentication will interact with the proposed use of - one time passwords discussed in Internet Draft - <draft-ietf-cat-kerberos-passwords-00.txt>. - -7. Strength of Encryption and Signature Mechanisms - - In light of recent findings on the strengths of MD5 and various DES - modes, we solicit discussion on which modes to incorporate into the - protocol changes. - - -8. Expiration - - This Internet-Draft expires on 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 |