1 2INTERNET-DRAFT Ari Medvinsky 3draft-ietf-cat-kerberos-err-msg-00.txt Matt Hur 4Updates: RFC 1510 Dominique Brezinski 5expires September 30, 1997 CyberSafe Corporation 6 Gene Tsudik 7 Brian Tung 8 ISI 9 10Integrity Protection for the Kerberos Error Message 11 120. Status Of this Memo 13 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its 16 areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 18 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or to cite them other than as "work in 23 progress." 24 25 To learn the current status of any Internet-Draft, please check 26 the "1id-abstracts.txt" listing contained in the Internet-Drafts 27 Shadow Directories on ds.internic.net (US East Coast), 28 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 29 munnari.oz.au (Pacific Rim). 30 31 The distribution of this memo is unlimited. It is filed as 32 draft-ietf-cat-kerberos-pk-init-03.txt, and expires June xx, 1997. 33 Please send comments to the authors. 34 351. Abstract 36 37 The Kerberos error message, as defined in RFC 1510, is transmitted 38 to the client without any integrity assurance. Therefore, the 39 client has no means to distinguish between a valid error message 40 sent from the KDC and one sent by an attacker. This draft describes 41 a method for assuring the integrity of Kerberos error messages, and 42 proposes a consistent format for the e-data field in the KRB_ERROR 43 message. This e-data format enables the storage of cryptographic 44 checksums by providing an extensible mechanism for specifying e-data 45 types. 46 47 482. Motivation 49 50 In the Kerberos protocol [1], if an error occurs for AS_REQ, 51 TGS_REQ, or AP_REQ, a clear text error message is returned to the 52 client. An attacker may exploit this vulnerability by sending a 53 false error message as a reply to any of the above requests. For 54 example, an attacker may send the KDC_ERR_KEY_EXPIRED error message 55 in order to force a user to change their password in hope that the 56 new key will not be as strong as the current key, and thus, easier 57 to break. 58 59 Since false error messages may be utilized by an attacker, a 60 Kerberos client should have a means for determining how much trust 61 to place in a given error message. The rest of this draft 62 describes a method for assuring the integrity of Kerberos error 63 messages. 64 65 663. Approach 67 68 We propose taking a cryptographic checksum over the entire KRB-ERROR 69 message. This checksum would be returned as part of the error 70 message and would enable the client to verify the integrity of the 71 error message. For interoperability reasons, no new fields are 72 added to the KRB-ERROR message. Instead, the e-data field (see 73 figure 1) is utilized to carry the cryptographic checksum. 74 75 763.1 Cryptographic checksums in error messages for AS_REQ, 77 TGS_REQ & AP_REQ 78 79 If an error occurs for the AS request, the only key that is 80 available to the KDC is the shared secret (the key derived from the 81 clients password) registered in the KDCs database. The KDC will 82 use this key to sign the error message, if and only if, the client 83 already proved knowledge of the shared secret in the AS request 84 (e.g. via PA-ENC-TIMESTAMP in preauth data). This policy is needed 85 to prevent an attacker from getting the KDC to send a signed error 86 message and then launching an off-line attack in order to obtain a 87 key of a given principal. 88 89 If an error occurs for a TGS or an AP request, the server will use 90 the session key sealed in the clients ticket granting ticket to 91 compute the checksum over the error message. If the checksum could 92 not be computed (e.g. error while decrypting the ticket) the error 93 message is returned to the client without the checksum. The client 94 then has the option to treat unprotected error messages differently. 95 96 97 KRB-ERROR ::= [APPLICATION 30] SEQUENCE { 98 pvno [0] integer, 99 msg-type [1] integer, 100 ctime [2] KerberosTime OPTIONAL, 101 cusec [3] INTEGER OPTIONAL, 102 stime [4] KerberosTime, 103 susec [5] INTEGER, 104 error-code [6] INTEGER, 105 crealm [7] Realm OPTIONAL, 106 cname [8] PrincipalName OPTIONAL, 107 realm [9] Realm, --Correct realm 108 sname [10] PrincipalName, --Correct name 109 e-text [11] GeneralString OPTIONAL, 110 e-data [12] OCTET STRING OPTIONAL 111 } 112 Figure 1 113 114 1153.2 Format of the e-data field 116 117 We propose to place the cryptographic checksum in the e-data field. 118 First, we review the format of the e-data field, as specified in 119 RFC 1510. The format of e-data is specified only in two cases [2]. 120 "If the error code is KDC_ERR_PREAUTH_REQUIRED, then the e-data 121 field will contain an encoding of a sequence of padata fields": 122 123 METHOD-DATA ::= SEQUENCE of PA-DATA 124 PA-DATA ::= SEQUENCE { 125 padata-type [1] INTEGER, 126 padata-value [2] OCTET STRING 127 } 128 129 The second case deals with the KRB_AP_ERR_METHOD error code. The 130 e-data field will contain an encoding of the following sequence: 131 132 METHOD-DATA ::= SEQUENCE { 133 method-type [0] INTEGER, 134 method-data [1] OCTET STRING OPTIONAL 135 } 136 137 method-type indicates the required alternate authentication method. 138 139 It should be noted that, in the case of KRB_AP_ERR_METHOD, a signed 140 checksum is not returned as part of the error message, since the 141 error code indicates that the Kerberos credentials provided in the 142 AP_REQ message are unacceptable. 143 144 We propose that the e-data field have the following format for all 145 error-codes (except KRB_AP_ERR_METHOD): 146 147 E-DATA ::= SEQUENCE { 148 data-type [1] INTEGER, 149 data-value [2] OCTET STRING, 150 } 151 152 The data-type field specifies the type of information that is 153 carried in the data-value field. Thus, to send a cryptographic 154 checksum back to the client, the data-type is set to CHECKSUM, the 155 data-value is set to the ASN.1 encoding of the following sequence: 156 157 Checksum ::= SEQUENCE { 158 cksumtype [0] INTEGER, 159 checksum [1] OCTET STRING 160 } 161 162 1633.3 Computing the checksum 164 165 After the error message is filled out, the error structure is 166 converted into ASN.1 representation. A cryptographic checksum is 167 then taken over the encoded error message; the result is placed in 168 the error message structure, as the last item in the e-data field. 169 To send the error message, ASN.1 encoding is again performed over 170 the error message, which now includes the cryptographic checksum. 171 172 1733.4 Verifying the integrity of the error message 174 175 In addition to verifying the cryptographic checksum for the error 176 message, the client must verify that the error message is bound to 177 its request. This is done by comparing the ctime field in the 178 error message to its counterpart in the request message. 179 180 1814. E-DATA types 182 183 Since the e-data types must not conflict with preauthentication data 184 types, we propose that the preauthentication data types in the range 185 of 2048 and above be reserved for use as e-data types. 186 187 We define the following e-data type in support of integrity checking 188 for the Kerberos error message: 189 190 CHECKSUM = 2048 -- the keyed checksum described above 191 192 1935. Discussion 194 195 1965.1 e-data types 197 198 The extension for Kerberos error messages, as outlined above, is 199 extensible to allow for definition of other error data types. 200 We propose that the following e-data types be reserved: 201 202 KDCTIME = 2049 203 The error data would consist of the KDCs time in KerberosTime. 204 This data would be used by the client to adjust for clock skew. 205 206 REDIRECT = 2050 207 The error data would consist of a hostname. The hostname would 208 indicate the authoritative KDC from which to obtain a TGT. 209 210 2115.2 e-data types vs. error code specific data formats 212 213 Since RFC 1510 does not define an error data type, the data format 214 must be explicitly specified for each error code. This draft has 215 proposed an extension to RFC 1510 that would introduce the concept 216 of error data types. This would allow for a manageable set of data 217 types to be used for any error message. The authors assume that 218 the introduction of this e-data structure will not break any 219 existing Kerberos implementations. 220 221 2226. Bibliography 223 224 [1] J. Kohl, C. Neuman. The Kerberos Network Authentication 225 Service (V5). Request for Comments: 1510 226 [2] J. Kohl, C. Neuman. The Kerberos Network Authentication 227 Service (V5). Request for Comments: 1510 p.67 228 229 2307. Authors 231 232 Ari Medvinsky <ari.medvinsky@cybersafe.com> 233 Matthew Hur <matt.hur@cybersafe.com> 234 Dominique Brezinski <dominique.brezinski@cybersafe.com> 235 236 CyberSafe Corporation 237 1605 NW Sammamish Road 238 Suite 310 239 Issaquah, WA 98027-5378 240 Phone: (206) 391-6000 241 Fax: (206) 391-0508 242 http:/www.cybersafe.com 243 244 245 Brian Tung <brian@isi.edu> 246 Gene Tsudik <gts@isi.edu> 247 248 USC Information Sciences Institute 249 4676 Admiralty Way Suite 1001 250 Marina del Rey CA 90292-6695 251 Phone: (310) 822-1511 252 253