ObsoletedPROPOSED STANDARDIETF stream

RFC 4305: Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)

In plain English — editorial summary, not part of the RFC

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. [STANDARDS-TRACK]

Document record

Document ID
RFC4305
Published
December 2005
Authors
D. Eastlake 3rd
Status
PROPOSED STANDARD
Stream
IETF
Area
sec
Pages
9
Also known as
Obsoletes:
RFC 2402, RFC 2406
Obsoleted by:
RFC 4835

Topics

Standards lineage

This document is one revision in a chain of 10 RFCs, each formally replacing the one before it.

  1. RFC 1826 (1995)
  2. RFC 1827 (1995)
  3. RFC 2402 (1998)
  4. RFC 2406 (1998)
  5. RFC 4302 (2005)
  6. RFC 4303 (2005)
  7. RFC 4305 (2005)
  8. RFC 4835 (2007)
  9. RFC 7321 (2014)
  10. RFC 8221 (2017)

Read the full history of Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)

Referenced by

One later RFC formally updates or obsoletes part of this document.

Related documents

Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.

Also filed under

About this page

The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.

Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.

Data sources · Editorial policy · Report a correction · What is an RFC?

canonical URL: /rfc/4305-cryptographic-algorithm-implementation-requirements-for-encapsulating-security-p