idnits 2.17.1 draft-ietf-ipsec-ike-hash-revised-02.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 (22 November 2000) is 8528 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-02.txt 22 November 2000 4 Expires: 22 May 2001 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 generic ISAKMP [RFC-2408] header, nor does it authenticate 41 any extra payloads inside phase 1 packets. This causes a security prob- 42 lem when using extra payloads as already defined in the IKE and DOI 43 [RFC-2407] (vendor ID payload, INITIAL-CONTACT notification etc). There 44 is also suggestion how to fix the Phase 2 authentication hashes so that 45 they will also authenticate the generic ISAKMP header. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Specification of Requirements . . . . . . . . . . . . . . . . . 2 51 3. Revised HASH Calculation . . . . . . . . . . . . . . . . . . . . 2 52 4. Using of Revised HASH . . . . . . . . . . . . . . . . . . . . . 4 53 5. Fixing the Phase 2 authentication HASHs . . . . . . . . . . . . 4 54 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 55 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 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 payloads, nor it does not include generic 69 ISAKMP [RFC-2408] header, which contains version numbers, exchange type 70 etc. 72 2. Specification of Requirements 74 This document shall use the keywords "MUST", "MUST NOT", "REQUIRED", 75 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED, "MAY", and 76 "OPTIONAL" to describe requirements. They are to be interpreted as 77 described in [RFC-2119] document. 79 3. Revised HASH Calculation 81 The new HASH is defined so that all the packet received and sent before 82 are included in the HASH calculation. This also includes the packet 83 currently being generated. The final authentication HASH is HASH of 84 concatenation of HASHes of individiual packets. The reason for this is 85 that quite a lot of implementations already calculate the HASH of the 86 packet they are receiving just to detect retransmissions. This method 87 also makes the memory consumption smaller. 89 Each packet HASH includes the ISAKMP generic headers, ISAKMP payload 90 headers etc, i.e the exact bits sent to the wire from the beginning of 91 the ISAKMP generic header to the end of the packet. The HASH includes 92 the padding added because of the encryption. When the length of the 93 packet (inside the ISAKMP header) is calculated in to the HASH, it MUST 94 be set to the real length of packet including the padding. Packet is 95 added to the HASH as plaintext. 97 The authentication payloads (HASH or SIG) MUST be the last payload in 98 the packet, and when it is calculated to the authentication HASH it MUST 99 have proper payload header, but its contents inside the payload MUST be 100 all zeros, with proper length (either determined by the HASH algorithm 101 or the public key used in the authentication). 103 So in the main mode the initiator HASH is calculated as follows: 105 HASH_I = prf(SKEYID, HASH(packet_1) | HASH(packet_2) | HASH(packet_3) | 106 HASH(packet_4) | HASH(packet_5_template)) 108 Where the HASH() is the negotiated hash algorithm. Note, that the 109 initiator has to save the first packet he sends out, because he might 110 not be able calculate the hash of the packet before he receives the 111 responders packet and can find out the negotiated hash algorithm. 112 Retransmission packets are not added to the HASH. 114 The packet_1 is the first packet initiator sends to the network 115 (starting from the beginning of the generic header and continuing to the 116 length specified in the ISAKMP header). Same goes for packets 2 to 4. 117 The packet 5 template is special, because it is this packet we are 118 currently sending out. 120 The HASH of the packet 5 template is calculated before encryption, but 121 including the padding. The HASH/SIG payload MUST be in its place and 122 MUST contain all zeros. 124 After the HASH of the packet has been calculated, then we calculate the 125 actual HASH_I value. When the HASH_I has been calculated the place 126 holder inside the packet is filled with the proper hash or signature, 127 and the packet is encrypted before sent out. 129 When the responder is checking the HASH it first decrypts the 130 packet_5_template and then it copies the HASH/SIG away and clears it 131 from the packet. Then it calculates the exactly same HASH_I the 132 initiator did, which can then be used authenticate the exchange (either 133 direct comparison of the HASH, or signature verification). 135 In the main mode the responder HASH is calculated as follows: 137 HASH_R = prf(SKEYID, HASH(packet_1) | HASH(packet_2) | HASH(packet_3) | 138 HASH(packet_4) | HASH(packet_5_template) | HASH(packet_6_template)) 140 The packets 1 to 5 are identical to initiator case, i.e the SIG/HASH 141 payload inside the payload 5 template contains zeros. The packet 6 142 template is similar than packet 5 template in the initiator case, i.e 143 the HASH/SIG payload is in its place and must contain all zeros. 145 In the aggressive mode the HASH is calculated as follows: 147 HASH_I = prf(SKEYID, HASH(packet_1) | HASH(packet_2_template)) 148 HASH_R = prf(SKEYID, HASH(packet_1) | HASH(packet_2_template) | 149 HASH(packet_3_template)) 150 With same kind of processing of packet 2 and 3 than was for packets 5 151 and 6 in the main mode. Note, that the encryption of the final packet in 152 the aggressive mode does affect the HASH, because there might be padding 153 added to the packet 3 which must be then be included to the HASH. 155 4. Using of Revised HASH 157 The revised HASH is used for all new negotiations that are defined in 158 the new IKE. This means that revised HASH is used if the phase 1 159 transform ID is specifying the next IKE version. Other new exchanges can 160 define that they are also using the new revised HASH calculation method 161 instead of the old HASH calculation method. 163 Each authentication method is exactly identical to the old ones, except 164 the HASH_I and HASH_R are calculated as described in the section 165 ``Revised HASH Calculation''. 167 In the signature modes the final SIG_I or SIG_R is the result of the 168 negotiated digital signature algorithm applied to HASH_I or HASH_R 169 respectively. 171 In the RSA Encryption mode the authentication of the other party takes 172 place in the generation of the SKEYID, because to generate it correctly 173 the other end must be able to decrypt the encrypted NONCE payload. Note 174 that the ID and NONCE payloads are already encrypted using public key 175 when they are calculated to the authentication HASH. 177 5. Fixing the Phase 2 authentication HASHs 179 For most of the Phase 2 exchanges the authentication hash is defined as 180 follows: 182 HASH = prf(SKEYID_a, M-ID | rest of the packet after hash payload) 184 The new proposal for the authentication hash is: 186 HASH = prf(SKEYID_a, HASH(packet_template)) 188 Where the packet_template is the whole packet before encryption, but 189 after adding encryption padding. The HASH payload inside the packet MUST 190 be in its place and its contents MUST be all zeros (generic payload 191 header is properly filled in). Because the packet_template includes the 192 generic packet header, which contains the message id field, there is no 193 need to add that field to the hash separately. 194 This authentication hash SHOULD be used for all new exchange modes. I.e 195 when new Phase 2 exchange mode is added it SHOULD use this kind of hash 196 instead of old style hash, regardless of the phase 1 authentication 197 style. 199 If the exchange contains multiple packets then the packets MUST be tied 200 together in the HASH calculation. This means that the HASH is calculated 201 in the similar manner than in phase 1, i.e. the HASHes of the previous 202 packets in the exchange are added before the HASH of the outgoing packet 203 template. For example the authentication HASHes for ficticious exchange 204 having 4 packets are calculated as follows: 206 HASH(1) = prf(SKEYID_a, HASH(packet_1_template)) 207 HASH(2) = prf(SKEYID_a, HASH(packet_1_template) | 208 HASH(packet_2_template)) 209 HASH(3) = prf(SKEYID_a, HASH(packet_1_template) | 210 HASH(packet_2_template) | HASH(packet_3_template)) 211 HASH(4) = prf(SKEYID_a, HASH(packet_1_template) | 212 HASH(packet_2_template) | HASH(packet_3_template) | 213 HASH(packet_4_template)) 215 The packet templates are generated in same way than for one packet phase 216 2 exchange case. 218 For already existing phase 2 exchanges (quick mode, new group mode and 219 informational exchange), this new hash MUST be used only and only if the 220 ISAKMP SA was negotiated using the revised HASH authentication method. 221 This will provide the backward compatibility with old implementations. 223 In the quick mode the HASH(2) and HASH(3) includes the nonce payloads, 224 but if we include the complate hashes of 1st and 2nd packets to the 225 HASH(2) and HASH(3) there is no need to add them separately to the HASH. 226 Thus for the quick mode the new authentication HASH is defined to be: 228 HASH(1) = prf(SKEYID_a, HASH(packet_1_template)) 229 HASH(2) = prf(SKEYID_a, HASH(packet_1_template) | 230 HASH(packet_2_template)) 231 HASH(3) = prf(SKEYID_a, HASH(packet_1_template) | 232 HASH(packet_2_template) | HASH(packet_3_template)) 234 6. Security Considerations 236 This document describes a way to fix the security problem inside the 237 IKE. In the IKE defined in RFC2409 only some payloads are authenticated. 238 This means that generic ISAKMP header (version numbers, exchange type, 239 flags etc) and extra payloads (Notifications, Vendor ID, CERT, and CR 240 payloads) are not authenticated. This document fixes that security 241 problem. 243 7. References 245 [RFC-2408] Maughan D., Schertler M., Schneider M., Turner J., "Internet 246 Security Association and Key Management Protocol (ISAKMP)", November 247 1998. 249 [RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange (IKE)", 250 November 1998 252 [RFC-2119] Bradner, S., "Key words for use in RFCs to indicate 253 Requirement Levels", March 1997 255 [RFC-2407] Piper D., "The Internet IP Security Domain of Interpretation 256 for ISAKMP", November 1998 258 8. Authors' Addresses 260 Tero Kivinen 261 SSH Communications Security Corp 262 Fredrikinkatu 42 263 FIN-00100 HELSINKI 264 Finland 265 E-mail: kivinen@ssh.fi