IP Security Protocol Working Group (IPSEC) T. Kivinen INTERNET-DRAFT SSH Communications Security draft-ietf-ipsec-ike-hash-revised-00.txt 23 November 1999 Expires: 23 May 2000 Fixing IKE Phase 1 Authentication HASH Status of This memo This document is a submission to the IETF IP Security Protocol (IPSEC) Working Group. Comments are solicited and should be addressed to the working group mailing list (ipsec@lists.tislabs.com) or to the editor. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document defines new method of calculating the authentication HASH of the IKE [RFC-2409] protocol. It fixes known problems with the IKE. The way the HASH is currently defined in the [RFC-2409] does not authen- ticate the generic ISAKMP [RFC-2408] header, nor does it authenticate any extra payloads inside phase 1 packets. This causes a security prob- lem when using extra payloads as already defined in the IKE and DOI [RFC-2407] (vendor ID payload, INITIAL-CONTACT notification etc). This document defines three methods how to negotiate the new HASH method. All methods tries to be backward compatible as much as possible. Only one of those methods must be selected by the working group and all the other should be removed from this document. T. Kivinen [page 1] INTERNET-DRAFT 23 November 1999 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Specification of Requirements . . . . . . . . . . . . . . . . . 3 3. Revised HASH Calculation . . . . . . . . . . . . . . . . . . . . 3 4. Negotiating Revised HASH . . . . . . . . . . . . . . . . . . . . 4 5. Selecting Revised HASH Using New Authentication Methods . . . . 4 6. Selecting Revised HASH Using New HASH Algorithms . . . . . . . . 5 7. Selecting Revised HASH Using New PRF Algorithm . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction In the IKE [RFC-2409] protocol there is a clear security problem, because of the way the authentication HASH is calculated. The HASH is defined in the [RFC-2409] like this: HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b ) HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b ) The HASH does not include all payloads, nor it does not include generic ISAKMP [RFC-2408] header, which contains version numbers, exchange type etc. This problem is quite easy to fix, but the bigger problem is how to fix it in the backward compatible way, so we do not break all existing implementations out there. Most of the implementations out there will break immediately if we update the ISAKMP major/minor number or the phase 1 transform identifier. Most of the implementators say that their implementation should be able to ignore unknown SA data attributes inside the SA payload. They will not select that transform, so there should also be transform that is supported by them to really be backward compatible. This means that the most backword compatible way to negotiate the new HASH method is to negotiate it inside the SA payload. One advantage of negotiating new HASH inside the SA payload is that it is authenticated, so if attacker removes new revised HASH proposals from the SA payload the initiator will detect this when checking the HASH. There are three different alternatives that can be used. One is to define new, revised, authentication method for each existing authentication method. I.e define "Pre Shared Keys Revised HASH Authentication Method", "RSA Signatures Revised HASH Authentication Method" etc. Another alternative is to duplicate all HASH types ("MD5 Revised Authentication HASH"), and the third way is to define PRF method to describe new authentication HASH usage ("Revised Authentication T. Kivinen [page 2] INTERNET-DRAFT 23 November 1999 PRF"). All of the cases are identical in sense that the reserved number range is large enough (16 bits), so we can "consume" some extra numbers. The PRF method is might have more problems, because currently it is not used at all (there is no defined PRFs), so some implementations might break when they see such attribute class. 2. Specification of Requirements This document shall use the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED, "MAY", and "OPTIONAL" to describe requirements. They are to be interpreted as described in [RFC-2119] document. 3. Revised HASH Calculation The new HASH is defined so that all the packet received and sent before are included in the HASH calculation. This also includes the packet currently being generated. The HASH includes the ISAKMP generic headers, ISAKMP payload headers etc, i.e the exact bits sent to the wire from the beginning of the ISAKMP generic header to the end of the packet. The HASH includes the padding added because of the encryption. When the length of the packet (inside the ISAKMP header) is calculated in to the HASH, it MUST be set to the real length of packet including the padding. Packet is added to the HASH as plaintext. Retransmission packets are not added to the HASH. The authentication payloads (HASH or SIG) MUST be the last payload in the packet, and when it is calculated to the authentication HASH its contents MUST be all zeros, with proper length (either determined by the HASH algorithm or the public key used in the authentication). So in the main mode the initiator HASH is calculated as follows: HASH_I = prf(SKEYID, packet_1 | packet_2 | packet_3 | packet_4 | packet_5) Where the packet_1 is the first packet initiator sends to the network (starting from the beginning of the generic header and continuing to the length specified in the ISAKMP header). Same goes for packets 2 to 4. The packet 5 is special, because it is this packet we are currently sending out. It is calculated to the HASH before encryption, but including the padding. The HASH/SIG payload MUST be in its place and must contain all zeros. After the HASH has been calculated, the value is filled in to the place holder inside the packet and then the packet is encrypted before sent out. When the responder is checking the HASH it first decrypts the packet_5 and then it copies the HASH/SIG away and clears it from the packet. Then it calculates the exactly same HASH_I the initiator did, which can then be used authenticate the exchange (either direct comparison of the T. Kivinen [page 3] INTERNET-DRAFT 23 November 1999 HASH, or signature verification). In the main mode the responder HASH is calculated as follows: HASH_R = prf(SKEYID, packet_1 | packet_2 | packet_3 | packet_4 | packet_5 | packet_6) The packets 1 to 5 are identical to initiator case, i.e the SIG/HASH payload inside the payload 5 contains zeros. The packet 6 is similar than packet 5 in the initiator case, i.e the HASH/SIG payload is in its place and must contain all zeros. In the aggressive mode the HASH is calculated as follows: HASH_I = prf(SKEYID, packet_1 | packet_2) HASH_R = prf(SKEYID, packet_1 | packet_2 | packet_3) With same kind of processing of packet 2 and 3 than was for packets 5 and 6 in the main mode. Note, that the encryption of the final packet in the aggressive mode does affect the HASH, because there might be padding added to the packet 3 which must be then be included to the HASH. 4. Negotiating Revised HASH The revised HASH is negotiated using defined attribute values inside the SA payload. This means that current implementations are able to ignore those proposal and select the old HASH method. New implementations SHOULD add revised HASH method before normal method, so that the new revised HASH method is preferred. XXX Next paragraph will disappear from the final document: Next three sections describe three different ways to negotiate the new revised HASH method. The working group must select one of those and after that two of the other methods are removed from this document. Each of sections are currently written as they would be there alone, thus there is some duplication of text inside of them. 5. Selecting Revised HASH Using New Authentication Methods The revised HASH method is negotiated by adding 5 new authentication methods, i.e: XXX+1 Pre-Shared Keys with Revised Authentication HASH XXX+2 DSS Signatures with Revised Authentication HASH XXX+3 RSA Signatures with Revised Authentication HASH XXX+4 T. Kivinen [page 4] INTERNET-DRAFT 23 November 1999 Encryption with RSA with Revised Authentication HASH XXX+5 Revised Encryption with RSA with Revised Authentication HASH Note, The XXX should be replaced as the last defined authentication method number from the RFC2409. Each authentication method is exactly identical to the old ones, except the HASH_I and HASH_R are calculated as described in the section ``Revised HASH Calculation''. In the signature modes the final SIG_I or SIG_R is the result of the negotiated digital signature algorithm applied to HASH_I or HASH_R respectively. In the RSA Encryption mode the authentication of the other party takes place in the generation of the SKEYID, because to generate it correctly the other end must be able to decrypt the encrypted NONCE payload. Note that the ID and NONCE payloads are already encrypted using public key when they are calculated to the authentication HASH. 6. Selecting Revised HASH Using New HASH Algorithms The revised HASH method is negotiated by adding 3 new HASH algorithms, i.e: XXX+1 MD5 with Revised Authentication HASH XXX+2 SHA with Revised Authentication HASH XXX+3 Tiger with Revised Authentication HASH Note, The XXX should be replaced as the last defined hash algorithm number from the RFC2409. Each HASH is defined so that it doesn't affect the HASH algorithm itself, but the new revised HASH methods changes the way how the HASH_I and HASH_R are calculated. This is described in the section ``Revised HASH Calculation''. In the signature modes the final SIG_I or SIG_R, is the result of the negotiated digital signature algorithm applied to HASH_I or HASH_R respectively. In the RSA Encryption mode the authentication of the other party happens in the generation of the SKEYID, because to generate it correctly the other end must be able to decrypt the encrypted NONCE payload. Note that the ID and NONCE payloads are already encrypted, when they are calculated to the authentication HASH. T. Kivinen [page 5] INTERNET-DRAFT 23 November 1999 7. Selecting Revised HASH Using New PRF Algorithm The revised HASH method is negotiated by adding a PRF algorithm, i.e: XXX+1 HMAC-HASH PRF with Revised Authentication HASH Note, The XXX should be replaced as the last defined PRF algorithm number from the RFC2409. Each HASH is defined so that it doesn't affect the prf algorithm itself, but the new revised HASH method change the way how the HASH_I and HASH_R are calculated. This is described in the section ``Revised HASH Calculation''. In the signature modes the final SIG_I or SIG_R, is the result of the negotiated digital signature algorithm applied to HASH_I or HASH_R respectively. In the RSA Encryption mode the authentication of the other party happens in the generation of the SKEYID, because to generate it correctly the other end must be able to decrypt the encrypted NONCE payload. Note that the ID and NONCE payloads are already encrypted, when they are calculated to the authentication HASH. 8. Security Considerations This document describes a way to fix the security problem inside the IKE. In the IKE defined in RFC2409 only some payloads are authenticated. This means that generic ISAKMP header (version numbers, exchange type, flags etc) and extra payloads (Notifications, Vendor ID, CERT, and CR payloads) are not authenticated. This document fixes that security problem. This document does NOT fix the other exchanges methods, like the quick mode or the new group mode exchanges. In those exchanges the ISAKMP generic header is still unauthenticated, all other payloads inside the those exchanges are already authenticated. 9. References [RFC-2408] Maughan D., Schertler M., Schneider M., Turner J., "Internet Security Association and Key Management Protocol (ISAKMP)", November 1998. [RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange (IKE)", November 1998 [RFC-2119] Bradner, S., "Key words for use in RFCs to indicate Requirement Levels", March 1997 [RFC-2407] Piper D., "The Internet IP Security Domain of Interpretation for ISAKMP", November 1998 T. Kivinen [page 6] INTERNET-DRAFT 23 November 1999 10. Authors' Addresses Tero Kivinen SSH Communications Security Ltd. Tekniikantie 12 FIN-02150 ESPOO Finland E-mail: kivinen@ssh.fi T. Kivinen [page 7]