INTERNET-DRAFT Ari Medvinsky draft-ietf-cat-kerberos-err-msg-00.txt Matt Hur Updates: RFC 1510 Dominique Brezinski expires September 30, 1997 CyberSafe Corporation Gene Tsudik Brian Tung ISI Integrity Protection for the Kerberos Error Message 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 documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). The distribution of this memo is unlimited. It is filed as draft-ietf-cat-kerberos-pk-init-03.txt, and expires June xx, 1997. Please send comments to the authors. 1. Abstract The Kerberos error message, as defined in RFC 1510, is transmitted to the client without any integrity assurance. Therefore, the client has no means to distinguish between a valid error message sent from the KDC and one sent by an attacker. This draft describes a method for assuring the integrity of Kerberos error messages, and proposes a consistent format for the e-data field in the KRB_ERROR message. This e-data format enables the storage of cryptographic checksums by providing an extensible mechanism for specifying e-data types. 2. Motivation In the Kerberos protocol [1], if an error occurs for AS_REQ, TGS_REQ, or AP_REQ, a clear text error message is returned to the client. An attacker may exploit this vulnerability by sending a false error message as a reply to any of the above requests. For example, an attacker may send the KDC_ERR_KEY_EXPIRED error message in order to force a user to change their password in hope that the new key will not be as strong as the current key, and thus, easier to break. Since false error messages may be utilized by an attacker, a Kerberos client should have a means for determining how much trust to place in a given error message. The rest of this draft describes a method for assuring the integrity of Kerberos error messages. 3. Approach We propose taking a cryptographic checksum over the entire KRB-ERROR message. This checksum would be returned as part of the error message and would enable the client to verify the integrity of the error message. For interoperability reasons, no new fields are added to the KRB-ERROR message. Instead, the e-data field (see figure 1) is utilized to carry the cryptographic checksum. 3.1 Cryptographic checksums in error messages for AS_REQ, TGS_REQ & AP_REQ If an error occurs for the AS request, the only key that is available to the KDC is the shared secret (the key derived from the clients password) registered in the KDCs database. The KDC will use this key to sign the error message, if and only if, the client already proved knowledge of the shared secret in the AS request (e.g. via PA-ENC-TIMESTAMP in preauth data). This policy is needed to prevent an attacker from getting the KDC to send a signed error message and then launching an off-line attack in order to obtain a key of a given principal. If an error occurs for a TGS or an AP request, the server will use the session key sealed in the clients ticket granting ticket to compute the checksum over the error message. If the checksum could not be computed (e.g. error while decrypting the ticket) the error message is returned to the client without the checksum. The client then has the option to treat unprotected error messages differently. KRB-ERROR ::= [APPLICATION 30] SEQUENCE { pvno [0] integer, msg-type [1] integer, ctime [2] KerberosTime OPTIONAL, cusec [3] INTEGER OPTIONAL, stime [4] KerberosTime, susec [5] INTEGER, error-code [6] INTEGER, crealm [7] Realm OPTIONAL, cname [8] PrincipalName OPTIONAL, realm [9] Realm, --Correct realm sname [10] PrincipalName, --Correct name e-text [11] GeneralString OPTIONAL, e-data [12] OCTET STRING OPTIONAL } Figure 1 3.2 Format of the e-data field We propose to place the cryptographic checksum in the e-data field. First, we review the format of the e-data field, as specified in RFC 1510. The format of e-data is specified only in two cases [2]. "If the error code is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will contain an encoding of a sequence of padata fields": METHOD-DATA ::= SEQUENCE of PA-DATA PA-DATA ::= SEQUENCE { padata-type [1] INTEGER, padata-value [2] OCTET STRING } The second case deals with the KRB_AP_ERR_METHOD error code. The e-data field will contain an encoding of the following sequence: METHOD-DATA ::= SEQUENCE { method-type [0] INTEGER, method-data [1] OCTET STRING OPTIONAL } method-type indicates the required alternate authentication method. It should be noted that, in the case of KRB_AP_ERR_METHOD, a signed checksum is not returned as part of the error message, since the error code indicates that the Kerberos credentials provided in the AP_REQ message are unacceptable. We propose that the e-data field have the following format for all error-codes (except KRB_AP_ERR_METHOD): E-DATA ::= SEQUENCE { data-type [1] INTEGER, data-value [2] OCTET STRING, } The data-type field specifies the type of information that is carried in the data-value field. Thus, to send a cryptographic checksum back to the client, the data-type is set to CHECKSUM, the data-value is set to the ASN.1 encoding of the following sequence: Checksum ::= SEQUENCE { cksumtype [0] INTEGER, checksum [1] OCTET STRING } 3.3 Computing the checksum After the error message is filled out, the error structure is converted into ASN.1 representation. A cryptographic checksum is then taken over the encoded error message; the result is placed in the error message structure, as the last item in the e-data field. To send the error message, ASN.1 encoding is again performed over the error message, which now includes the cryptographic checksum. 3.4 Verifying the integrity of the error message In addition to verifying the cryptographic checksum for the error message, the client must verify that the error message is bound to its request. This is done by comparing the ctime field in the error message to its counterpart in the request message. 4. E-DATA types Since the e-data types must not conflict with preauthentication data types, we propose that the preauthentication data types in the range of 2048 and above be reserved for use as e-data types. We define the following e-data type in support of integrity checking for the Kerberos error message: CHECKSUM = 2048 -- the keyed checksum described above 5. Discussion 5.1 e-data types The extension for Kerberos error messages, as outlined above, is extensible to allow for definition of other error data types. We propose that the following e-data types be reserved: KDCTIME = 2049 The error data would consist of the KDCs time in KerberosTime. This data would be used by the client to adjust for clock skew. REDIRECT = 2050 The error data would consist of a hostname. The hostname would indicate the authoritative KDC from which to obtain a TGT. 5.2 e-data types vs. error code specific data formats Since RFC 1510 does not define an error data type, the data format must be explicitly specified for each error code. This draft has proposed an extension to RFC 1510 that would introduce the concept of error data types. This would allow for a manageable set of data types to be used for any error message. The authors assume that the introduction of this e-data structure will not break any existing Kerberos implementations. 6. Bibliography [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service (V5). Request for Comments: 1510 [2] J. Kohl, C. Neuman. The Kerberos Network Authentication Service (V5). Request for Comments: 1510 p.67 7. Authors Ari Medvinsky Matthew Hur Dominique Brezinski CyberSafe Corporation 1605 NW Sammamish Road Suite 310 Issaquah, WA 98027-5378 Phone: (206) 391-6000 Fax: (206) 391-0508 http:/www.cybersafe.com Brian Tung Gene Tsudik USC Information Sciences Institute 4676 Admiralty Way Suite 1001 Marina del Rey CA 90292-6695 Phone: (310) 822-1511