Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)
RFC 4305
| Document | Type |
RFC - Proposed Standard
(December 2005; Errata)
Obsoleted by RFC 4835
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 4305 (Proposed Standard) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Russ Housley | ||
| Send notices to | (None) | ||
Network Working Group D. Eastlake 3rd
Request for Comments: 4305 Motorola Laboratories
Obsoletes: 2404, 2406 December 2005
Category: Standards Track
Cryptographic Algorithm Implementation Requirements for
Encapsulating Security Payload (ESP) and Authentication Header (AH)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
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. This document defines
the current set of mandatory-to-implement algorithms for ESP and AH
as well as specifying algorithms that should be implemented because
they may be promoted to mandatory at some future time.
Eastlake Standards Track [Page 1]
RFC 4305 Cryptographic Algorithms for ESP & AH December 2005
Table of Contents
1. Introduction ....................................................2
2. Requirements Terminology ........................................3
3. Algorithm Selection .............................................3
3.1. Encapsulating Security Payload .............................3
3.1.1. ESP Encryption and Authentication Algorithms ........4
3.1.2. ESP Combined Mode Algorithms ........................4
3.2. Authentication Header ......................................5
4. Security Considerations .........................................5
5. Acknowledgement .................................................5
6. Changes from RFC 2402 and 2406 ..................................6
7. Normative References ............................................6
8. Informative References ..........................................7
1. Introduction
The Encapsulating Security Payload (ESP) and the Authentication
Header (AH) provide two mechanisms for protecting data being sent
over an IPsec Security Association (SA) [IPsec, ESP, AH]. 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. This document defines the current set of mandatory-to-
implement algorithms for ESP and AH as well as specifying algorithms
that should be implemented because they may be promoted to mandatory
at some future time.
The nature of cryptography is that new algorithms surface
continuously and existing algorithms are continuously attacked. An
algorithm believed to be strong today may be demonstrated to be weak
tomorrow. Given this, the choice of mandatory-to-implement algorithm
should be conservative so as to minimize the likelihood of it being
compromised quickly. Thought should also be given to performance
considerations as many uses of IPsec will be in environments where
performance is a concern.
Finally, we need to recognize that the mandatory-to-implement
algorithm(s) may need to change over time to adapt to the changing
world. For this reason, the selection of mandatory-to-implement
algorithms is not included the main IPsec, ESP, or AH specifications.
It is instead placed in this document. As the choice of algorithm
changes, only this document should need to be updated.
Ideally, the mandatory-to-implement algorithm of tomorrow should
already be available in most implementations of IPsec by the time it
is made mandatory. To facilitate this, we will attempt to identify
such algorithms (as they are known today) in this document. There is
Eastlake Standards Track [Page 2]
RFC 4305 Cryptographic Algorithms for ESP & AH December 2005
no guarantee that the algorithms we believe today may be mandatory in
the future will in fact become so. All algorithms known today are
Show full document text