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

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 03

Network Working Group                                          V. Manral
Request for Comments: 4835                              IP Infusion Inc.
Obsoletes: 4305                                               April 2007
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 IETF Trust (2007).

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.

Manral                       Standards Track                    [Page 1]
RFC 4835           Cryptographic Algorithms ESP and AH        April 2007

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Requirements Terminology  . . . . . . . . . . . . . . . . . . . 3
   3.  Algorithm Selection . . . . . . . . . . . . . . . . . . . . . . 4
     3.1.  Encapsulating Security Payload  . . . . . . . . . . . . . . 4
       3.1.1.  ESP Encryption and Authentication Algorithms  . . . . . 4
       3.1.2.  ESP Combined Mode Algorithms  . . . . . . . . . . . . . 5
     3.2.  Authentication Header . . . . . . . . . . . . . . . . . . . 5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Changes from RFC 2402 and RFC 2406 to RFC 4305  . . . . . . . . 7
   7.  Changes from RFC 4305 . . . . . . . . . . . . . . . . . . . . . 7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 9

Manral                       Standards Track                    [Page 2]
RFC 4835           Cryptographic Algorithms ESP and AH        April 2007

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) [RFC4301], [RFC4302].  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 in 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
   no guarantee that the algorithms that we (today) believe may be
   mandatory in the future will in fact become so.  All algorithms known