idnits 2.17.1 draft-ietf-cat-kerberos-err-msg-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 252 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 95: '... ctime [2] KerberosTime OPTIONAL,...' RFC 2119 keyword, line 96: '... cusec [3] INTEGER OPTIONAL,...' RFC 2119 keyword, line 100: '... crealm [7] Realm OPTIONAL,...' RFC 2119 keyword, line 101: '... cname [8] PrincipalName OPTIONAL,...' RFC 2119 keyword, line 104: '... e-text [11] GeneralString OPTIONAL,...' (2 more instances...) == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC1510, but the abstract doesn't seem to directly say this. It does mention RFC1510 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- (Using the creation date from RFC1510, updated by this document, for RFC5378 checks: 1993-09-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 211 looks like a reference -- Missing reference section? 'APPLICATION 30' on line 92 looks like a reference -- Missing reference section? '0' on line 152 looks like a reference -- Missing reference section? '2' on line 213 looks like a reference -- Missing reference section? '3' on line 96 looks like a reference -- Missing reference section? '4' on line 97 looks like a reference -- Missing reference section? '5' on line 98 looks like a reference -- Missing reference section? '6' on line 99 looks like a reference -- Missing reference section? '7' on line 100 looks like a reference -- Missing reference section? '8' on line 101 looks like a reference -- Missing reference section? '9' on line 102 looks like a reference -- Missing reference section? '10' on line 103 looks like a reference -- Missing reference section? '11' on line 104 looks like a reference -- Missing reference section? '12' on line 105 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Ari Medvinsky 2 draft-ietf-cat-kerberos-err-msg-00.txt Matt Hur 3 Updates: RFC 1510 Dominique Brezinski 4 expires September 30, 1997 CyberSafe Corporation 5 Gene Tsudik 6 Brian Tung 7 ISI 9 Integrity Protection for the Kerberos Error Message 11 0. Status Of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 To learn the current status of any Internet-Draft, please check 25 the "1id-abstracts.txt" listing contained in the Internet-Drafts 26 Shadow Directories on ds.internic.net (US East Coast), 27 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 28 munnari.oz.au (Pacific Rim). 30 The distribution of this memo is unlimited. It is filed as 31 draft-ietf-cat-kerberos-pk-init-03.txt, and expires June xx, 1997. 32 Please send comments to the authors. 34 1. Abstract 36 The Kerberos error message, as defined in RFC 1510, is transmitted 37 to the client without any integrity assurance. Therefore, the 38 client has no means to distinguish between a valid error message 39 sent from the KDC and one sent by an attacker. This draft describes 40 a method for assuring the integrity of Kerberos error messages, and 41 proposes a consistent format for the e-data field in the KRB_ERROR 42 message. This e-data format enables the storage of cryptographic 43 checksums by providing an extensible mechanism for specifying e-data 44 types. 46 2. Motivation 48 In the Kerberos protocol [1], if an error occurs for AS_REQ, 49 TGS_REQ, or AP_REQ, a clear text error message is returned to the 50 client. An attacker may exploit this vulnerability by sending a 51 false error message as a reply to any of the above requests. For 52 example, an attacker may send the KDC_ERR_KEY_EXPIRED error message 53 in order to force a user to change their password in hope that the 54 new key will not be as strong as the current key, and thus, easier 55 to break. 57 Since false error messages may be utilized by an attacker, a 58 Kerberos client should have a means for determining how much trust 59 to place in a given error message. The rest of this draft 60 describes a method for assuring the integrity of Kerberos error 61 messages. 63 3. Approach 65 We propose taking a cryptographic checksum over the entire KRB-ERROR 66 message. This checksum would be returned as part of the error 67 message and would enable the client to verify the integrity of the 68 error message. For interoperability reasons, no new fields are 69 added to the KRB-ERROR message. Instead, the e-data field (see 70 figure 1) is utilized to carry the cryptographic checksum. 72 3.1 Cryptographic checksums in error messages for AS_REQ, 73 TGS_REQ & AP_REQ 75 If an error occurs for the AS request, the only key that is 76 available to the KDC is the shared secret (the key derived from the 77 clients password) registered in the KDCs database. The KDC will 78 use this key to sign the error message, if and only if, the client 79 already proved knowledge of the shared secret in the AS request 80 (e.g. via PA-ENC-TIMESTAMP in preauth data). This policy is needed 81 to prevent an attacker from getting the KDC to send a signed error 82 message and then launching an off-line attack in order to obtain a 83 key of a given principal. 85 If an error occurs for a TGS or an AP request, the server will use 86 the session key sealed in the clients ticket granting ticket to 87 compute the checksum over the error message. If the checksum could 88 not be computed (e.g. error while decrypting the ticket) the error 89 message is returned to the client without the checksum. The client 90 then has the option to treat unprotected error messages differently. 92 KRB-ERROR ::= [APPLICATION 30] SEQUENCE { 93 pvno [0] integer, 94 msg-type [1] integer, 95 ctime [2] KerberosTime OPTIONAL, 96 cusec [3] INTEGER OPTIONAL, 97 stime [4] KerberosTime, 98 susec [5] INTEGER, 99 error-code [6] INTEGER, 100 crealm [7] Realm OPTIONAL, 101 cname [8] PrincipalName OPTIONAL, 102 realm [9] Realm, --Correct realm 103 sname [10] PrincipalName, --Correct name 104 e-text [11] GeneralString OPTIONAL, 105 e-data [12] OCTET STRING OPTIONAL 106 } 107 Figure 1 109 3.2 Format of the e-data field 111 We propose to place the cryptographic checksum in the e-data field. 112 First, we review the format of the e-data field, as specified in 113 RFC 1510. The format of e-data is specified only in two cases [2]. 114 "If the error code is KDC_ERR_PREAUTH_REQUIRED, then the e-data 115 field will contain an encoding of a sequence of padata fields": 117 METHOD-DATA ::= SEQUENCE of PA-DATA 118 PA-DATA ::= SEQUENCE { 119 padata-type [1] INTEGER, 120 padata-value [2] OCTET STRING 121 } 123 The second case deals with the KRB_AP_ERR_METHOD error code. The 124 e-data field will contain an encoding of the following sequence: 126 METHOD-DATA ::= SEQUENCE { 127 method-type [0] INTEGER, 128 method-data [1] OCTET STRING OPTIONAL 129 } 131 method-type indicates the required alternate authentication method. 133 It should be noted that, in the case of KRB_AP_ERR_METHOD, a signed 134 checksum is not returned as part of the error message, since the 135 error code indicates that the Kerberos credentials provided in the 136 AP_REQ message are unacceptable. 138 We propose that the e-data field have the following format for all 139 error-codes (except KRB_AP_ERR_METHOD): 141 E-DATA ::= SEQUENCE { 142 data-type [1] INTEGER, 143 data-value [2] OCTET STRING, 144 } 146 The data-type field specifies the type of information that is 147 carried in the data-value field. Thus, to send a cryptographic 148 checksum back to the client, the data-type is set to CHECKSUM, the 149 data-value is set to the ASN.1 encoding of the following sequence: 151 Checksum ::= SEQUENCE { 152 cksumtype [0] INTEGER, 153 checksum [1] OCTET STRING 154 } 156 3.3 Computing the checksum 158 After the error message is filled out, the error structure is 159 converted into ASN.1 representation. A cryptographic checksum is 160 then taken over the encoded error message; the result is placed in 161 the error message structure, as the last item in the e-data field. 162 To send the error message, ASN.1 encoding is again performed over 163 the error message, which now includes the cryptographic checksum. 165 3.4 Verifying the integrity of the error message 167 In addition to verifying the cryptographic checksum for the error 168 message, the client must verify that the error message is bound to 169 its request. This is done by comparing the ctime field in the 170 error message to its counterpart in the request message. 172 4. E-DATA types 174 Since the e-data types must not conflict with preauthentication data 175 types, we propose that the preauthentication data types in the range 176 of 2048 and above be reserved for use as e-data types. 178 We define the following e-data type in support of integrity checking 179 for the Kerberos error message: 181 CHECKSUM = 2048 -- the keyed checksum described above 183 5. Discussion 185 5.1 e-data types 187 The extension for Kerberos error messages, as outlined above, is 188 extensible to allow for definition of other error data types. 189 We propose that the following e-data types be reserved: 191 KDCTIME = 2049 192 The error data would consist of the KDCs time in KerberosTime. 193 This data would be used by the client to adjust for clock skew. 195 REDIRECT = 2050 196 The error data would consist of a hostname. The hostname would 197 indicate the authoritative KDC from which to obtain a TGT. 199 5.2 e-data types vs. error code specific data formats 201 Since RFC 1510 does not define an error data type, the data format 202 must be explicitly specified for each error code. This draft has 203 proposed an extension to RFC 1510 that would introduce the concept 204 of error data types. This would allow for a manageable set of data 205 types to be used for any error message. The authors assume that 206 the introduction of this e-data structure will not break any 207 existing Kerberos implementations. 209 6. Bibliography 211 [1] J. Kohl, C. Neuman. The Kerberos Network Authentication 212 Service (V5). Request for Comments: 1510 213 [2] J. Kohl, C. Neuman. The Kerberos Network Authentication 214 Service (V5). Request for Comments: 1510 p.67 216 7. Authors 218 Ari Medvinsky 219 Matthew Hur 220 Dominique Brezinski 222 CyberSafe Corporation 223 1605 NW Sammamish Road 224 Suite 310 225 Issaquah, WA 98027-5378 226 Phone: (206) 391-6000 227 Fax: (206) 391-0508 228 http:/www.cybersafe.com 230 Brian Tung 231 Gene Tsudik 233 USC Information Sciences Institute 234 4676 Admiralty Way Suite 1001 235 Marina del Rey CA 90292-6695 236 Phone: (310) 822-1511