datatracker.ietf.org
Sign in
Version 5.6.4.p1, 2014-10-20
Report a bug

The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)
RFC 4359

Network Working Group                                            B. Weis
Request for Comments: 4359                                 Cisco Systems
Category: Standards Track                                   January 2006

                The Use of RSA/SHA-1 Signatures within
 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 (2006).

Abstract

   This memo describes the use of the RSA digital signature algorithm as
   an authentication algorithm within the revised IP Encapsulating
   Security Payload (ESP) as described in RFC 4303 and the revised IP
   Authentication Header (AH) as described in RFC 4302.  The use of a
   digital signature algorithm, such as RSA, provides data origin
   authentication in applications when a secret key method (e.g., HMAC)
   does not provide this property.  One example is the use of ESP and AH
   to authenticate the sender of an IP multicast packet.

Weis                        Standards Track                     [Page 1]
RFC 4359         RSA/SHA-1 Signatures within ESP and AH     January 2006

Table of Contents

   1. Introduction ....................................................2
   2. Algorithm and Mode ..............................................3
      2.1. Key Size Discussion ........................................4
   3. Performance .....................................................5
   4. Interaction with the ESP Cipher Mechanism .......................6
   5. Key Management Considerations ...................................6
   6. Security Considerations .........................................7
      6.1. Eavesdropping ..............................................7
      6.2. Replay .....................................................7
      6.3. Message Insertion ..........................................8
      6.4. Deletion ...................................................8
      6.5. Modification ...............................................8
      6.6. Man in the Middle ..........................................8
      6.7. Denial of Service ..........................................8
   7. IANA Considerations .............................................9
   8. Acknowledgements ...............................................10
   9. References .....................................................10
      9.1. Normative References ......................................10
      9.2. Informative References ....................................10

1.  Introduction

   Encapsulating Security Payload  (ESP) [ESP] and Authentication Header
   (AH) [AH] headers can be used to protect both unicast traffic and
   group (e.g., IPv4 and IPv6 multicast) traffic.  When unicast traffic
   is protected between a pair of entities, HMAC transforms (such as
   [HMAC-SHA]) are sufficient to prove data origin authentication.  An
   HMAC is sufficient protection in that scenario because only the two
   entities involved in the communication have access to the key, and
   proof-of-possession of the key in the HMAC construct authenticates
   the sender.  However, when ESP and AH authenticate group traffic,
   this property no longer holds because all group members share the
   single HMAC key.  In the group case, the identity of the sender is
   not uniquely established, since any of the key holders has the
   ability to form the HMAC transform.  Although the HMAC transform
   establishes a group-level security property, data origin
   authentication is not achieved.

   Some group applications require true data origin authentication,
   where one group member cannot successfully impersonate another group
   member.  The use of asymmetric digital signature algorithms, such as
   RSA, can provide true data origin authentication.

   With asymmetric algorithms, the sender generates a pair of keys, one
   of which is never shared (called the "private key") and one of which
   is distributed to other group members (called the "public key").

Weis                        Standards Track                     [Page 2]
RFC 4359         RSA/SHA-1 Signatures within ESP and AH     January 2006

   When the private key is used to sign the output of a cryptographic
   hash algorithm, the result is called a "digital signature".  A
   receiver of the digital signature uses the public key, the signature

[include full document text]