idnits 2.17.1 draft-ietf-ipsec-ike-hash-revised-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC-2407], [RFC-2408], [RFC-2409]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- The document date (19 November 2001) is 8187 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IP Security Protocol Working Group (IPSEC) T. Kivinen 2 INTERNET-DRAFT SSH Communications Security 3 draft-ietf-ipsec-ike-hash-revised-03.txt 19 November 2001 4 Expires: 19 May 2002 6 Fixing IKE Phase 1 & 2 Authentication HASHs 8 Status of This Memo 10 This document is a submission to the IETF IP Security Protocol 11 (IPSEC) Working Group. Comments are solicited and should be 12 addressed to the working group mailing list (ipsec@lists.tislabs.com) 13 or to the editor. 15 This document is an Internet-Draft and is in full conformance 16 with all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- 26 Drafts as reference material or to cite them other than as 27 "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document defines new method of calculating the authentication HASH 38 of the IKE [RFC-2409] protocol. It fixes known problems with the IKE. 39 The way the HASH is currently defined in the [RFC-2409] does not authen- 40 ticate the ISAKMP [RFC-2408] packet header, nor does it authenticate any 41 extra ISAKMP payloads inside phase 1 ISAKMP packets. This causes a secu- 42 rity problem when using extra ISAKMP payloads as already defined in the 43 IKE and DOI [RFC-2407] (vendor ID payload, INITIAL-CONTACT notification 44 etc). There is also suggestion how to fix the Phase 2 authentication 45 hashes so that they will also authenticate the ISAKMP packet header. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Specification of Requirements . . . . . . . . . . . . . . . . . 3 51 3. Revised HASH Calculation . . . . . . . . . . . . . . . . . . . . 3 52 4. Using of Revised HASH . . . . . . . . . . . . . . . . . . . . . 4 53 5. Fixing the Phase 2 authentication HASHs . . . . . . . . . . . . 5 54 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 55 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 58 1. Introduction 60 In the IKE [RFC-2409] protocol there is a clear security problem, 61 because of the way the authentication HASH is calculated. 63 The HASH is defined in the [RFC-2409] like this: 65 HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b ) 66 HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b ) 68 The HASH does not include all ISAKMP payloads, nor it does not include 69 ISAKMP packet header, which contains version numbers, exchange type etc. 71 In this document we use following terms to refer different parts of the 72 ISAKMP / IKE packets: 74 ISAKMP packet 75 A packet that contains the full ISAKMP packet. This includes the 76 ISAKMP packet header, and all ISAKMP payloads inside the ISAKMP 77 packet and the padding added because of the encryption (if 78 payloads are encrypted). This is the packet whose length is given 79 inside the ISAKMP packet header. 81 ISAKMP packet header 82 Generic header which is before any ISAKMP payloads inside the all 83 ISAKMP packet. It includes cookies, first payload type, major and 84 minor version numbers, exchange type, flags, message id and 85 length. 87 ISAKMP payload 88 One ISAKMP payload inside the ISAKMP packet. This includes the 89 ISAKMP payload header and the ISAKMP payload data. 91 ISAKMP payload header 92 Generic header inside the ISAKMP payload. This includes the next 93 payload type, and payload length fields. 95 ISAKMP payload data 96 Data inside one ISAKMP payload. 98 2. Specification of Requirements 100 This document shall use the keywords "MUST", "MUST NOT", "REQUIRED", 101 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED, "MAY", and 102 "OPTIONAL" to describe requirements. They are to be interpreted as 103 described in [RFC-2119] document. 105 3. Revised HASH Calculation 107 The new HASH is defined so that all ISAKMP packets received and sent are 108 included in the HASH calculation. This also includes the ISAKMP packet 109 currently being generated. The final authentication HASH is HASH of 110 concatenation of HASHes of individiual ISAKMP packets. The benefit of 111 this is that quite a lot of implementations already calculate the HASH 112 of the ISAKMP packet they are receiving just to detect retransmissions, 113 thus no extra step is needed on those implementations. This method also 114 makes the memory consumption smaller. 116 Each HASH of ISAKMP packet includes the ISAKMP packet header, all ISAKMP 117 payloads and the padding, i.e the exact bits sent to the wire from the 118 beginning of the ISAKMP packet header to the end of the ISAKMP packet. 119 If the ISAKMP packet is encrypted then the HASH also includes the 120 encryption padding. When the length of the ISAKMP packet (inside the 121 ISAKMP packet header) is calculated in to the HASH, it MUST be set to 122 the real length of ISAKMP packet including the padding. Packet is added 123 to the HASH as plaintext (before encryption or after decryption). 125 The authentication payload (HASH or SIG) MUST be the last ISAKMP payload 126 in the ISAKMP packet, and when it is calculated to the authentication 127 HASH it MUST have proper ISAKMP payload header, but the ISAKMP payload 128 data MUST be all zeros, with proper length (either determined by the 129 HASH algorithm or the public key used in the authentication). 131 So in the main mode the initiator HASH is calculated as follows: 133 HASH_I = prf(SKEYID, HASH(packet_1) | HASH(packet_2) | HASH(packet_3) | 134 HASH(packet_4) | HASH(packet_5_template)) 136 Where the HASH() is the negotiated hash algorithm. Note, that the 137 initiator has to save the first ISAKMP packet he sends out, because he 138 might not be able calculate the hash of the packet before he receives 139 the responders packet and can find out the negotiated hash algorithm. 140 Retransmission packets are not added to the HASH. 142 The packet 1 is the first packet initiator sends to the network 143 (starting from the beginning of the ISAKMP packet header and continuing 144 to the length specified in the ISAKMP packet header). Same goes for 145 packets 2 to 4. The packet 5 template is special, because it is this 146 packet we are currently sending out. 148 The HASH of the packet 5 template is calculated before encryption, but 149 including the padding. The HASH/SIG payload MUST be in its place and 150 MUST contain all zeros. 152 After the HASH of the packet has been calculated, then we calculate the 153 actual HASH_I value. When the HASH_I has been calculated the place 154 holder inside the packet is filled with the proper hash or signature, 155 and the packet is encrypted before sent out. 157 When the responder is checking the HASH it first decrypts the packet 5 158 and then it copies the HASH/SIG away and clears it from the packet 159 creating the packet 5 template. Then it calculates the exactly same 160 HASH_I the initiator did, which can then be used authenticate the 161 exchange (either direct comparison of the HASH, or signature 162 verification). 164 In the main mode the responder HASH is calculated as follows: 166 HASH_R = prf(SKEYID, HASH(packet_1) | HASH(packet_2) | HASH(packet_3) | 167 HASH(packet_4) | HASH(packet_5_template) | HASH(packet_6_template)) 169 The packets 1 to 5 are identical to initiator case, i.e the SIG/HASH 170 payload inside the packet 5 template contains zeros. The packet 6 171 template is similar than packet 5 template in the initiator case, i.e 172 the HASH/SIG payload is in its place and must contain all zeros. 174 In the aggressive mode the HASH is calculated as follows: 176 HASH_I = prf(SKEYID, HASH(packet_1) | HASH(packet_2_template)) 177 HASH_R = prf(SKEYID, HASH(packet_1) | HASH(packet_2_template) | 178 HASH(packet_3_template)) 180 With same kind of processing of packet 2 and 3 than was for packets 5 181 and 6 in the main mode. Note, that the encryption of the final packet in 182 the aggressive mode does affect the HASH, because there might be padding 183 added to the packet 3 which must be then be included to the HASH and the 184 padding also affects the length field inside the ISAKMP packet header 185 which is included in the HASH. 187 4. Using of Revised HASH 189 The revised HASH is used for all new negotiations that are defined in 190 the new IKE. This means that revised HASH is used if the phase 1 191 transform ID is specifying the next IKE version. Other new exchanges can 192 define that they are also using the new revised HASH calculation method 193 instead of the old HASH calculation method. 195 Each authentication method is exactly identical to the old ones, except 196 the HASH_I and HASH_R are calculated as described in the section 197 ``Revised HASH Calculation''. 199 In the signature modes the final SIG_I or SIG_R is the result of the 200 negotiated digital signature algorithm applied to HASH_I or HASH_R 201 respectively. 203 In the RSA Encryption mode the authentication of the other party takes 204 place in the generation of the SKEYID, because to generate it correctly 205 the other end must be able to decrypt the encrypted NONCE payload. Note 206 that the ID and NONCE payloads are already encrypted using public key 207 when they are calculated to the authentication HASH. 209 5. Fixing the Phase 2 authentication HASHs 211 For most of the Phase 2 exchanges the authentication hash is defined as 212 follows: 214 HASH = prf(SKEYID_a, M-ID | rest of the packet after hash payload) 216 The new proposal for the authentication hash is: 218 HASH = prf(SKEYID_a, HASH(packet_template)) 220 Where the packet template is the whole ISAKMP packet before encryption, 221 but after adding encryption padding. The HASH payload inside the ISAKMP 222 packet MUST be in its place and its contents MUST be all zeros (ISAKMP 223 payload header is properly filled in). Because the packet template 224 includes the ISAKMP packet header, which contains the message id field, 225 there is no need to add that field to the hash separately. 227 This authentication hash SHOULD be used for all new exchange modes. I.e 228 when new Phase 2 exchange mode is added it SHOULD use this kind of hash 229 instead of old style hash, regardless of the phase 1 authentication 230 style. 232 If the exchange contains multiple packets then the packets MUST be tied 233 together in the HASH calculation. This means that the HASH is calculated 234 in the similar manner than in phase 1, i.e. the HASHes of the previous 235 packets in the exchange are added before the HASH of the outgoing packet 236 template. For example the authentication HASHes for ficticious exchange 237 having 4 packets are calculated as follows: 239 HASH(1) = prf(SKEYID_a, HASH(packet_1_template)) 240 HASH(2) = prf(SKEYID_a, HASH(packet_1_template) | 241 HASH(packet_2_template)) 242 HASH(3) = prf(SKEYID_a, HASH(packet_1_template) | 243 HASH(packet_2_template) | HASH(packet_3_template)) 244 HASH(4) = prf(SKEYID_a, HASH(packet_1_template) | 245 HASH(packet_2_template) | HASH(packet_3_template) | 246 HASH(packet_4_template)) 248 The packet templates are generated in same way than for one packet phase 249 2 exchange case. 251 For already existing phase 2 exchanges (quick mode, new group mode and 252 informational exchange), this new hash MUST be used only and only if the 253 ISAKMP SA is negotiated using transform ID specifying new IKE version. 254 This will provide the backward compatibility with old implementations. 256 In the quick mode the HASH(2) and HASH(3) includes the nonce payloads, 257 but if we include the complate hashes of 1st and 2nd packets to the 258 HASH(2) and HASH(3) there is no need to add them separately to the HASH. 259 Thus for the quick mode the new authentication HASH is defined to be: 261 HASH(1) = prf(SKEYID_a, HASH(packet_1_template)) 262 HASH(2) = prf(SKEYID_a, HASH(packet_1_template) | 263 HASH(packet_2_template)) 264 HASH(3) = prf(SKEYID_a, HASH(packet_1_template) | 265 HASH(packet_2_template) | HASH(packet_3_template)) 267 6. Security Considerations 269 This document describes a way to fix the security problem inside the 270 IKE. In the IKE defined in RFC2409 only some ISAKMP payloads are 271 authenticated. This means that ISAKMP packet header (version numbers, 272 exchange type, flags etc) and extra ISAKMP payloads (Notifications, 273 Vendor ID, CERT, and CR payloads) are not authenticated. This document 274 fixes that security problem. 276 7. References 278 [RFC-2408] Maughan D., Schertler M., Schneider M., Turner J., "Internet 279 Security Association and Key Management Protocol (ISAKMP)", November 280 1998. 282 [RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange (IKE)", 283 November 1998 285 [RFC-2119] Bradner, S., "Key words for use in RFCs to indicate 286 Requirement Levels", March 1997 288 [RFC-2407] Piper D., "The Internet IP Security Domain of Interpretation 289 for ISAKMP", November 1998 291 8. Authors' Addresses 293 Tero Kivinen 294 SSH Communications Security Corp 295 Fredrikinkatu 42 296 FIN-00100 HELSINKI 297 Finland 298 E-mail: kivinen@ssh.fi