Internet DRAFT Vishwas Manral UPDATES RFC 4305 IPInfusion Expires September 2006 March 2006 Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH), Errata Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on September 08, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Since the publication of the RFCs specifying the implementation requirements for ESP and AH, some errors have been noted. This informational document lists these errors and provides corrections for them. V. Manral Expires September 2006 [Page 1] INTERNET-DRAFT Implementation requirements for ESP March 2006 and AH - Errata Contributers Thanks to the following people for reporting or responding to reports of these errata: Paul Koning, Stephen Kent and Lars Völker. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Errata . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 6 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 V. Manral Expires September 2006 [Page 2] INTERNET-DRAFT Implementation requirements for ESP March 2006 and AH - Errata 1. Introduction The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Encapsulating Security Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPsec Security Association (SA). To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to- implement algorithms to ensure that there is at least one algorithm that all implementations will have available. Relevent information is available in [RFC4305]. This document specifies the errors that have been noted in the RFC. Some of the errors are critical and that is why the need to put in a different draft. Some of the changes are not just an errata, but a desired spec change that we missed. 2. Errata i. Section 3.1.1 states Requirement Authentication Algorithm (notes) ----------- ------------------------ MUST HMAC-SHA1-96 [RFC2404] MUST NULL (1) SHOULD+ AES-XCBC-MAC-96 [RFC3566] MAY HMAC-MD5-96 [RFC2403] (2) Should be Requirement Authentication Algorithm (notes) ----------- ------------------------ MUST HMAC-SHA1-96 [RFC2404] SHOULD+ AES-XCBC-MAC-96 [RFC3566] MAY NULL (1) MAY HMAC-MD5-96 [RFC2403] (2) ii. Section 3.1.1 states Notes: (1) Since ESP encryption and authentication are optional, support for the two "NULL" algorithms is required to maintain consistency with the way these services are negotiated. Note that while authentication and encryption can each be "NULL", they MUST NOT both be "NULL". V. Manral Expires September 2006 [Page 3] INTERNET-DRAFT Implementation requirements for ESP March 2006 and AH - Errata Should be Notes: (1) Since ESP encryption is optional, support for the "NULL" algorithm is required to maintain consistency with the way services are negotiated. Note that while authentication and encryption can each be "NULL", they MUST NOT both be "NULL". iii. Section 3.2 states Requirement Algorithm (notes) ----------- --------- MUST HMAC-SHA1-96 [RFC2404] SHOULD+ AES-XCBC-MAC-96 [RFC3566] MAY HMAC-MD5-96 [RFC2403] (1) Note: (1) Weaknesses have become apparent in MD5; however, these should not affect the use of MD5 with HMAC. Should be Requirement Algorithm (notes) ----------- --------- MUST HMAC-SHA1-96 [RFC2404] (1) SHOULD+ AES-XCBC-MAC-96 [RFC3566] MAY HMAC-MD5-96 [RFC2403] (2) Note: (1) Collisions attacks are now known in SHA-1; however, these should not affect the use of SHA-1 with HMAC. (2) Weaknesses have become apparent in MD5; however, these should not affect the use of MD5 with HMAC. iv. Section 6. The implementation requirements are compared below: Old Old New Req. RFC(s) Requirement Algorithm (notes) --- ------ ----------- --------- MUST 2406 SHOULD NOT DES-CBC [RFC2405] (1) MUST 2402 2406 MAY HMAC-MD5-96 [RFC2403] MUST 2402 2406 MUST HMAC-SHA1-96 [RFC2404] V. Manral Expires September 2006 [Page 4] INTERNET-DRAFT Implementation requirements for ESP March 2006 and AH - Errata Should be The implementation requirements are compared below: Old Old New Req. RFC(s) Requirement Algorithm (notes) --- ------ ----------- --------- MUST 2406 SHOULD NOT DES-CBC [RFC2405] (1) MUST 2402 2406 MAY HMAC-MD5-96 [RFC2403] MUST 2402 2406 MUST HMAC-SHA1-96 [RFC2404] MUST 2406 MAY NULL Authentication MUST 2406 MUST NULL Encryption v. In the header, it says: Obsoletes: 2404, 2406 Should be Obsoletes: 2402, 2406 V. Manral Expires September 2006 [Page 5] INTERNET-DRAFT Implementation requirements for ESP March 2006 and AH - Errata 3. Acknowledgements This draft borrows text heavily from RFC4305.:) The author would like to acknowledge Stephen Kent and Donald Eastlake. V. Manral Expires September 2006 [Page 6] INTERNET-DRAFT Implementation requirements for ESP March 2006 and AH - Errata 4. References 4.1. Normative References [RFC4305] 3rd Eastlake, D., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005 4.2. Informative References [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998. [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998. [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003. Authors' Addresses Vishwas Manral IPInfusion, Bangalore India Phone: +91-98456-61911 Email: vishwas.ietf@gmail.com V. Manral Expires September 2006 [Page 7] INTERNET-DRAFT Implementation requirements for ESP March 2006 and AH - Errata Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. V. Manral Expires September 2006 [Page 8]