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
<draft-manral-ipsec-rfc4305-errata-00.txt>
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]