number and the IV field will contain the same value.
6. By decoupling the IV and the sequence number, architectures
where the sequence number assignment is performed outside the
assurance boundary are accommodated.
The use of an explicit IV field directly follows from the decoupling
of the sequence number and the per-packet counter block value. The
additional overhead (64 bits for the IV field) is acceptable. This
overhead is significantly less overhead associated with Cipher Block
Chaining (CBC) mode. As normally employed, CBC requires a full block
for the IV and, on average, half of a block for padding. AES CCM
confidentiality processing with an explicit IV has about one-third of
the overhead as AES CBC, and the overhead is constant for each
packet.
11. IANA Considerations
IANA has assigned three ESP transform numbers for use with AES CCM
with an explicit IV:
14 for AES CCM with an 8-octet ICV;
15 for AES CCM with a 12-octet ICV; and
16 for AES CCM with a 16-octet ICV.
12. Acknowledgements
Doug Whiting and Niels Ferguson worked with me to develop CCM mode.
We developed CCM mode as part of the IEEE 802.11i security effort.
One of the most attractive aspects of CCM mode is that it is
unencumbered by patents. I acknowledge the companies that supported
the development of an unencumbered authenticated encryption mode (in
alphabetical order):
Hifn
Intersil
MacFergus
RSA Security
Also, I thank Tero Kivinen for his comprehensive review of this
document.
13. References
This section provides normative and informative references.
13.1. Normative References
[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard (AES),"
November 2001.
[DOI] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[CCM] Whiting, D., Housley, R., and N. Ferguson, "Counter with
CBC-MAC (CCM)", RFC 3610, September 2003.
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
13.2. Informative References
[ARCH] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[ROAD] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
Document Roadmap", RFC 2411, November 1998.
[JUMBO] Borman, D., Deering, S., and R. Hinden, "IPv6
Jumbograms", RFC 2675, August 1999.
Author’s Address
Russell Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
USA
EMail: housley@vigilsec.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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.
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.
Intellectual Property
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.