[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-bew-ipsec-signatures) 00 01 02 03 04 05 06 RFC 4359

   Internet Engineering Task Force                                   Brian Weis
   INTERNET-DRAFT                                                 Cisco Systems
   Document: draft-ietf-msec-ipsec-signatures-00.txt             December, 2003
   Expires: June, 2004


                The Use of RSA Signatures within ESP and AH

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet
   Engineering Task Force (IETF), its areas, and its working groups.
   Note that other groups may also distribute working documents as
   Internet Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.

Abstract

   This memo describes the use of the RSA Signature algorithm [RSA] as
   an authentication algorithm within the revised IPSEC Encapsulating
   Security Payload [ESPbis] and the revised IPSEC Authentication Header
   [AHbis]. The use of a digital signature algorithm such as RSA
   provides data origin authentication when a secret key method (e.g.,
   HMAC) cannot do so. For example, when ESP and AH are used to protect
   IP multicast data flows.

   Further information on the other components necessary for ESP and AH
   implementations is provided by [ROADMAP].










   Weis                   Expires June, 2004                         1 
              The Use of RSA Signatures with ESP and AH December, 2003


Table of Contents

1.0 Introduction......................................................2
2.0 Algorithm and Mode................................................3
3.0 Performance.......................................................3
4.0 Interaction with the ESP Cipher Mechanism.........................4
5.0 Key Management Considerations.....................................4
6.0 Security Considerations...........................................5
  6.1 Eavesdropping...................................................5
  6.2 Replay..........................................................5
  6.3 Message Insertion...............................................5
  6.4 Deletion........................................................5
  6.5 Modification....................................................6
  6.6 Man in the middle...............................................6
  6.7 Denial of Service...............................................6
7.0 IANA Considerations...............................................6
8.0 Acknowledgements..................................................7
9.0 References........................................................7
  9.1 Normative References............................................7
  9.2 Informative References..........................................7
Authors Addresses.....................................................8

1.0 Introduction

   AH and ESP payloads can be used to protect both unicast traffic and
   group traffic, such as IPv4 and IPv6 multicast traffic. When unicast
   traffic is protected between a pair of entities, HMAC transforms
   (such as [HMAC-SHA] and [HMAC-MD5]) are sufficient to prove data
   origin authentication. An HMAC is sufficient protection in that
   scenario because only one other entity knows the key, and proof-of-
   possession of the key in the HMAC construct authenticates the sender.
   However when AH and ESP protect group traffic, this property is no
   longer valid -- all group members share the single HMAC key and the
   identity of the sender is not uniquely established.

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

   Witj asymmetric encryption 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").When the private key is used to encrypt the output of a
   cryptographic hash algorithm, the cipher text is called a "digital
   signature". A receiver of the digital signature uses the public key
   to decrypt the hash, which is then compared to a hash generated by
   the reveiver. If the hashes match, then the receiver has confidence
   in the claimed origin of the packet.


   Weis                   Expires June, 2004                         2 
              The Use of RSA Signatures with ESP and AH December, 2003


   This memo describes how RSA digital signatures can be applied as an
   authentication mechanism to AH and ESP payloads to provide data
   origin authentication.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT","SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in [RFC2119].

2.0 Algorithm and Mode

   The RSA Public Key Algorithm [RSA] is a widely deployed public key
   algorithm commonly used for digital signatures. Compared to other
   public key algorithms, signature verification is relatively
   efficient. This property is useful for groups where receivers may
   have limited processing capabilities. The RSA Algorithm is commonly
   supported in hardware, and is not encumbered by intellectual property
   claims.

   Several schemes for the RSA Algorithm are described in [RSA]. Two
   schemes (RSASSA-PKCS1-v1.5 and RSASSA-PSS) combine the generation of
   a hash from a message, and the signing of that hash. However, this
   combination of cryptographic operations is not always appropriate for
   IPsec, where a variety of hardware and software modules may be used.
   In addition, one signature method (RSASSA-PPKCS1-v1.5) encodes the
   hash type into the signature data block, and this encoding is not
   necessary because the hash algorithm is pre-determined in IPsec.

   The RSAES-OAEP raw RSA scheme [RSA, Section 7.1] MUST be used as the
   encryption scheme. As recommended in [RSA, Section B.1], SHA-1 MUST
   be used as the signature hash algorithm both as the message to be
   encrypted by the RSA Algorithm, and as the encoding parameter for the
   OAEP encoding. The value of parameter string P MUST be the default,
   which is the hash of an empty string. The mask generation function
   MUST be MGF1 as defined in [RSA, Section B.2.1].

   Ephemeral RSA key pairs generated for use during the lifetime of an
   SA may be generated. Doing so reduces the amount of time the RSA
   private key will be used, which may allow for a use of shorter keys.
   Note that relatively short key sizes are acceptable because the
   security model for short-live RSA authentication keys is different
   from the usual model.

   The size of the RSA modulus used can vary, but MUST be at least 496
   bits. This restriction is a function of the size of the SHA-1 hash
   and the number of bits needed for OAEP encapsulation. (For more
   information, see [RSA, Section 7.1].)

3.0 Performance

   The RSA asymmetric key algorithm is very costly in terms of
   processing time compared to the HMAC algorithms. However, processing
   cost is decreasing over time. Faster general-purpose processors are
   being deployed, faster software implementations are being developed,

   Weis                   Expires June, 2004                         3 
              The Use of RSA Signatures with ESP and AH December, 2003


   and hardware acceleration support for the algorithm is becoming more
   prevalent. However, care should always be taken that RSA signatures
   are not used for applications that expect to have bandwidth
   requirements that would be adversely affected.

   The RSA asymmetric key algorithm is best suited to protect network
   traffic for network traffic for which:

    o The sender has a substantial amount of processing power, whereas
      receivers are not guaranteed to have substantial processing
      power, and

    o The network traffic is small enough that adding a relatively
      large authentication tag (in the range of 61 to 256 bytes) does
      not cause packet fragmentation.

   Both key pair generation and encryption (or signing) are
   substantially more expensive operations, but these are isolated to
   the sender.

   The size of the RSA modulus can affect the processing required to
   create and verify RSA digital signatures. Care should be taken to
   determine what the size of key is needed for the application.
   Smaller key sizes may be chosen as long as the network traffic
   protected by the private key flows for less time than it is estimated
   that an attacker would take to discover the private key. This
   lifetime is considerably smaller than most public key applications,
   so a key that is normally considered weak may be satisfactory. (If
   the RSA public key algorithm were used to encrypt the packet, then
   the lifetime would be substantially longer.)

   The addition of a digital signature as an authentication tag adds a
   significant number of bytes to the packet. This increases the
   likelihood that the packet encapsulated in AH or ESP may be
   fragmented.

4.0 Interaction with the ESP Cipher Mechanism

   There are no known issues that preclude the use of the RSA
   signatures algorithm with any specific cipher algorithm.

5.0 Key Management Considerations

   A key management mechanism negotiating the use of RSA Signatures MUST
   include the length of the RSA modulus during policy negotiation. This
   gives a device the opportunity to decline, which is especially
   important for devices with constrained processors that might not be
   able to handle the verification of signatures using larger key sizes.

   A receiver must have the RSA public key in order to decrypt the
   packet. When used with a group key management system (e.g., RFC 3547
   [GDOI]), the public key SHOULD be sent as part of the key download

   Weis                   Expires June, 2004                         4 
              The Use of RSA Signatures with ESP and AH December, 2003


   policy. If the group has multiple senders, the public key of each
   sender SHOULD be sent as part of the key download policy.

   Use of this transform with a pair-wise key management system such as
   the Internet Key Exchange [IKEv2] is NOT RECOMMENDED.  The value of
   using this transform for a pair-wise connection is limited,
   considering the performance impact.

6.0 Security Considerations

   This document provides a method of authentication for AH and ESP
   using digital signatures. This feature provides the following
   protections:

    o Message modification integrity. The digital signature allows the
      receiver of the message to verify that it was exactly the same as
      when the sender signed it.

    o Host authentication. The asymmetric nature of the RSA public key
      algorithm allows the sender to be uniquely verified, even when
      the message is sent to a group.

   As suggested by [RFC3552], the following sections describe various
   attacks that could be deployed against using RSA signatures as a
   means of authentication.

6.1 Eavesdropping

   This document does not address confidentiality. That function, if
   desired, must be addressed by an ESP cipher that is used with the
   RSA Signatures authentication method. The RSA signature itself does
   not need to be protected in any way.

6.2 Replay

   This document does not address replay attacks. That function, if
   desired, is addressed through use of AH and ESP sequence numbers as
   defined in [AH] and [ESP].

6.3 Message Insertion

   This document directly addresses message insertion attacks. Inserted
   messages will fail authentication and be dropped by the receiver.

6.4 Deletion

   This document does not address deletion attacks. It is only
   concerned with validating the legitimacy of messages that are not
   deleted.


   Weis                   Expires June, 2004                         5 
              The Use of RSA Signatures with ESP and AH December, 2003


6.5 Modification

   This document directly addresses message modification attacks.
   Modified messages will fail authentication and be dropped by the
   receiver.

6.6 Man in the middle

   As long as a receiver is given the sender RSA public key in a
   trusted manner, it will be able to verify that the digital signature
   is correct. A man in the middle will not be able to spoof the actual
   sender unless it acquires the RSA private key through some means.

   RSA modulus sizes must be chosen carefully to ensure that the time it
   takes a man in the middle to determine the RSA private key through
   cryptanalysis is longer than the amount of time that packets are
   signed with that private key.

6.7 Denial of Service

   A receiver of an ESP and AH packet starts by looking up the Security
   Association in the SADB. If one is found, the ESP or AH sequence
   number in the packet is verified. If the sequence number falls
   within the window, the authentication step is performed.

   An attacker that sends an ESP or AH packet which matches a valid SA
   on the system and which also has a valid sequence number will cause
   the receiver to perform the AH or ESP authentication step. Because
   the process of verifying an RSA digital signature consumes
   relatively large amounts of processing, this could lead to a denial
   of service attack on the receiver if many such packets were sent.

   If the message was sent to an IPv4 or IPv6 multicast group all group
   members that received the packet would be under attack
   simultaneously.

   This attack can be mitigated by encapsulating an ESP or AH payload
   in an AH payload using an HMAC transform. In this case, the HMAC
   transform would be validated first, and would indicate that a group
   member rather than an attacker sent the packet.

7.0 IANA Considerations

   An assigned number is required in the "IPSec Authentication
   Algorithm" name space in the ISAKMP registry [ISAKMP-REG]. The
   mnemonic should be "SIG-RSA".

   A new "IPSEC Security Association Attribute" is required in the
   ISAKMP registry to pass the RSA modulus size. The attribute class
   should be called "Authentication Key Length", and it should a
   Variable type.


   Weis                   Expires June, 2004                         6 
              The Use of RSA Signatures with ESP and AH December, 2003


8.0 Acknowledgements

   Scott Fluhrer and David McGrew provided advice regarding applicable
   key sizes.

9.0 References

9.1 Normative References

   [AHbis] Kent, S., "IP Authentication Header", draft-ietf-ipsec-
   rfc2402bis-05.txt, September 2003.

   [ESPbis] Kent, S., "IP Encapsulating Security Payload (ESP)", draft-
   ietf-ipsec-esp-v3-06.txt, July 2003.

   [ISAKMP-REG] http://www.iana.org/assignments/isakmp-registry

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Level", BCP 14, RFC 2119, March 1997.

   [RFC2401bis] Kent, S., "Security Architecture for the Internet
   Protocol", draft-ietf-ipsec-rfc2401bis-00.txt, October 2003.

   [RFC3552] E. Rescorla, et. al., "Guidelines for Writing RFC Text on
   Security Considerations", RFC 3552, July 2003.

   [ROADMAP] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
   Document Roadmap", RFC 2411, November 1998.

   [RSA] Jonsson, J., B. Kaliski,  "Public-Key Cryptography Standard
   (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447,
   February 2003.

9.2 Informative References

   [GDOI] M. Baugher, B. Weis, T. Hardjono, H. Harney, "The Group Domain
   of Interpretation", RFC 3547, December 2002.

   [HMAC-MD5] Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within
   ESP and AH"", RFC 2403, November 1998.

   [HMAC-SHA] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within
   ESP and AH", RFC 2404, November 1998.

   [IKEV2] C. Kaufman, "Internet Key Exchange (IKEv2) Protocol", draft-
   ietf-ipsec-ikev2-11.txt, October 9, 2003.


   Weis                   Expires June, 2004                         7 
              The Use of RSA Signatures with ESP and AH December, 2003


Authors Address

   Brian Weis
   Cisco Systems
   170 W. Tasman Drive,
   San Jose, CA 95134-1706, USA
   (408) 526-4796
   bew@cisco.com


   Weis                   Expires June, 2004                         8


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/