INTERNET-DRAFT Clifford Neuman draft-ietf-cat-kerberos-pk-init-00.txt Brian Tung Updates: RFC 1510 ISI expires September 3, 1995 John Wray Digital Equipment 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-00.txt, and expires August 6, 1995. Please send comments to the authors. 1. Abstract This document defines extensions to the Kerberos protocol specifi- cation (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 provides 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 each other. In public key cryptography, however, neither key can be derived easily from the other; hence, the ability to encrypt a message does not imply the ability to decrypt it in turn. Additionally, each key is a full inverse of the other, so that either key can be used for encryption or decryption. The advantages provided by public key cryptography have produced a demand for its integration into the Kerberos authentication protocol. 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. This proposal will allow users with keys already registered for use with X.509, PEM, or PGP, to use those keys to obtain Kerberos credentials which can then be used for authentication with application servers supporting Kerberos. Use of public-key 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 public keys instead of the current secret key. The application request and response, between Kerberos clients and application servers, will continue to be based on conventional cryptography, and the application servers will continue to be registered with conventional keys. 3. Initial authentication of users with public keys This section proposes 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. The advantage of registering public keys with the KDC lies in the ease of recovery in case the KDC is compromised. With Kerberos as it currently stands, compromise of the security KDC is disastrous. All keys become known by the attacker and all keys must be changed. If users register public keys, compromise of the KDC does not divulge their private key. Compromise of security on the KDC is still disastrous, since the attacker can impersonate any user. An attacker with the private key of the KDC can use it to certify a bogus nonce key, and impersonate a user. Changing this key invalidates all bogus certifications. Legitimate users must re-certify their keys with the new KDC key, but users' public keys do not have to be changed. (Users who store their private keys in an encrypted form on the KDC do have to change their keys, since the encryption key is a symmetric key derived from a password (as described below) and hence vulnerable to dictionary attacks. The difference is that, assuming good password policy, site policy may allow the use of the old password only for the purpose of key change for a time after the compromise, which means that users can change their own passwords, rather than forcing the administrator to re-key everyone.) In the event of compromise of the KDC, recovery is simple since only the KDC's key, keys for application servers, and users' private keys stored in the KDC (as described above) must be changed. Since there are usually fewer servers than users, and since an organization usually has better procedures for updating servers, changing these keys is much easier than having to individually contact every user. This proposed extension will not require users to register with public keys. It is intended to allow them to do so, but we recognize that there are many reasons, including licensing terms, that users or an organization as a whole will choose not to use the public key option. Users registered will public keys will only be able to perform initial authentication from a client that support public key, and must be registered in a realm that supports public key. But they will be able to use services registered in realms that support only conventional Kerberos. Further, users registered with conventional Kerberos keys will be able to use all clients. This proposal specifically does not address the registration of public keys for services. The application request and response, between Kerberos clients and application servers, will continue to be based on conventional cryptography, and the application servers will continue to be registered with conventional keys. There are performance issues and other reasons that servers may be better off using conventional cryptography. There are also reasons that they may want to use public key. For this proposal, however, 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. This proposal address two ways in which users may use public key cryptography for initial authentication with Kerberos. 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. 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. We first consider the case where the user's key is registered with the KDC. 3.1 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 known to the user, or may be stored on the KDC, encrypted so that it can not be used by the KDC. We consider first the case where the user knows the private key, then add support for retrieving the private key from the KDC. The initial request to the KDC for a ticket granting ticket proceeds according to RFC 1510. Typically, preauthentication using a secret key would not be included, but if included it may be ignored by the KDC. (This may introduce a problem: even if the KDC should ignore the preauthentication, an attacker may not, and use an intercepted message to guess the password off-line.) If the private key is known to the client in advance, the response from the KDC would be identical to the response in RFC1510, 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. A preauthentication field (specified below) accompanies the response, containing a certificate with the public key for the KDC, and a package containing the secret key in which the rest of the response is encrypted, itself encrypted in the private key of the KDC, and the public key of the user. This package also contains the same nonce used in the rest of the response, in order to prevent replays of this part of the message, accompanied by a reconstructed response. PA-PK-AS-REP ::= SEQUENCE { kdc-cert SEQUENCE OF OCTET STRING, encryptPack EncryptedData -- EncPaPkAsRepPart } EncPaPkAsRepPart ::= SEQUENCE { enc-sess-key INTEGER, nonce INTEGER } 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. We solicit discussion on the form of the kdc-cert. If client systems are expected to know (by being hard-coded, for example) at least one public key, and to verify certificates from that key, then there should be at least some policy about which key that is, or alternatively some way to inform the KDC which key the client possesses. If the certificate checks out, the client then extracts the message key for the rest of the response by decrypting the field in the PA-PK-AS-REP with the public key of the KDC and the private key of the user. The client then uses the message key to decrypt the rest of the response, and continues as per RFC1510[1]. 3.1.1. Private key held by KDC 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. When the user's private key is registered with the KDC, the KDC record will also indicate whether preauthentication is required before returning the record (we recommend that it be required). If such preauthentication is required, when the initial request is received the KDC will respond with a KRB_ERROR message of type KDC_ERR_PREAUTH_REQUIRED and with an error data field set to: PA-PK-AS-INFO ::= SEQUENCE { kdc-cert OCTET STRING} } The kdc-cert field is identical to that in the PA-PK-AS-REP preauthentication data field returned with the KDC response, and must be validated as belonging to the KDC in the same manner. Upon receipt of the KRB_ERROR message with a PA-PK-AS-INFO field, the client will prompt the user for the password that will be used to decrypt the private key when returned, calculate a one way hash H1 of the key, and send a request to the KDC, including a timestamp and a client-generated nonce secret key that will be used to super-encrypt the encrypted private key before it is returned to the client. This information is sent to the KDC in a subsequent AS_REQ message in a preauthentication data field: PA-PK-AS-REQ ::= SEQUENCE { enc-part EncryptedData -- EncPaPkAsReqPart } EncPaPkAsReqPart ::= SEQUENCE { tstamp KerberosTime, noncekey INTEGER } encrypted first with the hash H1, then the public key of the KDC from the certificate in the PA-PK-AS-INFO field of the error response. Upon receipt of the authentication request with the PA-PK-AS-REQ the KDC verifies the hash of the user's DES encryption key by comparing it to the hash stored in the users database record. If valid, it generates the AS response as defined in RFC1510, but additionally includes a preauthentication field of type PA-PK-USER KEY. This response will also be included in response to the initial request without preauthentication if preauthentication is not required for the user and the user's encrypted private key is stored on the KDC. The KDC generates a preauthentication data field of type PA-PK-USER-KEY which will be returned with the KDC reply (together with the PA-PK-AS-REP that is already returned). PA-PK-USER-KEY ::= SEQUENCE { enc-priv-key OCTET STRING OPTIONAL } 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 noncekey from the PA-PK-AS-REQ message if preauthentication using that method was provided. Note that since H1 is a one-way hash, it is not possible for one to decrypt the message if one possesses H1 but not the noncekey that H1 is derived from. 3.2. Clients with a public key certified by an outside authority In the case where the client is not registered with the current KDC, the client is responsible for obtaining the private key on its own. The client will request initial tickets from the KDC using the TGS exchange, but instead of performing pre-authentication 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 { user-cert SEQUENCE OF OCTET STRING, authent EncryptedData -- PKAuthenticator } PKAuthenticator ::= SEQUENCE { cksum Checksum OPTIONAL, cusec INTEGER, ctime KerberosTime, } The fields in the encrypted authenticator are the same as those in the Kerberos authenticator. The structure is itself signed using the user's private key corresponding to the public key in the certificate. 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.1, 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 (e.g. PGP:)[2]. 4. Compatibility with One-Time Passcodes We solicit discussion on how the use of public key crytpgraphy for intial authentication will interact with the proposed use of one time passwords discussed in Internet Draft draft-ietf-cat-kerberos-passwords-00.txt 5. Expiration This Internet-Draft expires on August 6, 1995. 6. Authors' Addresses B. Clifford Neuman USC/Information Sciences Institute 4676 Admiralty Way #1001 Marina del Rey, CA 90292-6695 Phone: 310-822-1511 EMail: bcn@isi.edu Brian Tung USC/Information Sciences Institute 4676 Admiralty Way #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 [1] Note: We have not yet defined the public key encryption method for encrypting the enc-sess-key field in the PA-PK-AS-REP. [2] Note: We are soliciting input on the form of the name. We believe the name part must be taken without modification from the certificate, but the realm part is open for discussion.