Internet Engineering Task Force                                   Brian Weis
   INTERNET-DRAFT                                                 Cisco Systems
   Document: draft-ietf-msec-ipsec-signatures-03.txt             November, 2004
   Expires: May, 2005


                The Use of RSA Signatures within ESP and AH

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   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 Digital Signature algorithm as
   an authentication algorithm within the revised IP Encapsulating
   Security Payload (ESP) as described in RFC XXXX and the revised IP
   Authentication Header (AH) as described in RFC YYYY. 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.

       -- Note to RFC Editor:  Please replace RFC XXXX with the RFC
       -- number that is assigned to draft-ietf-ipsec-esp-v3 and
       -- replace RFC YYYY with the RFC number assigned to
       -- draft-ietf-ipsec-rfc2402bis. Please also modify normative
       -- references [ESP] and [AH] that point to these drafts with
       -- their respective RFC numbers. Lastly, informative reference
       -- [IKEV2] should be changed to its assigned RFC number, assuming
       -- it is published before this document.





   Weis                   Expires May, 2005                         1
              The Use of RSA Signatures with ESP and AH November, 2004


Table of Contents

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

1.0 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"). When

   Weis                   Expires May, 2005                         2
              The Use of RSA Signatures with ESP and AH November, 2004


   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 value, and
   the hash to determine whether or not the claimed origin of the packet
   is correct.

   This memo describes how RSA digital signatures can be applied as an
   ESP and AH authentication mechanism 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.

   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 L MUST be the default,
   which is a SHA-1 hash of an empty string (SHA-1("")). The mask
   generation function MUST be MGF1 as defined in [RSA, Section B.2.1].

   The distribution mechanism of the RSA public key and its replacement
   interval are a local policy matter. The use of an ephemeral key pair
   with a lifetime of the ESP or AH SA is RECOMMENDED. This recommended
   policy reduces the exposure of the RSA private key to the lifetime of
   the data being signed by the private key. Also, this obviates the
   need to revoke or transmit the validity period of the key pair.

   The size of the RSA modulus 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].)



   Weis                   Expires May, 2005                         3
              The Use of RSA Signatures with ESP and AH November, 2004



2.1 Key size discussion

   The choice of RSA modulus size must be made carefully. If too small
   of a modulus size is chosen, an attacker may be able to reconstruct
   the private key used to sign packets before the key is no longer
   used by the sender to sign packets. This order of events may result
   in the data origin authentication property being compromised.
   However, choosing a modulus size larger than necessary will result
   in an unnecessarily high cost of CPU cycles for the sender and all
   receivers of the packet.

   Recent guidance on key sizes make estimates as to the amount of
   effort an attacker would need to expend in order to reconstruct an
   RSA private key. Section 2.1 of RFC 3766 [PK-STRENGTHS] suggests
   that an attacker may need 8000 MIPS years (MYs) to factor a 512 bit
   modulus, based on a previously factored 512 bit value [RSA155].
   (However, factoring a 528 bit modulus was subsequently found to take
   only 3000 MYs, so this smaller value is used as a more conservative
   starting point for determining the difficulty of factoring a 512 bit
   modulus.) It should be assumed that an attacker could harness 1
   million PCs with state-of-the-art processors for the sieving phase
   of Number Field Sieve (NFS) processing, and that a sufficiently fast
   processor with substantial memory is available for the matrix
   reduction phase. Assuming half of the processing applies to each
   phase, this results in a lifetime of about 5 days. However, since
   the formulae used to compute this value are empirical, a more
   conservative value of 1 hour is chosen as a recommended maximum
   lifetime for a key pair with a 512 bit modulus.

   A cost based security analysis of key lengths [COST] suggests an
   extrapolation of other RSA private key sizes from a private key with
   a 512 bit modulus. For example, a table in [COST] shows that the
   real time needed to complete NFS on a 576 bit modulus should be
   about 10.9 times as long as a 512 bit modulus. This table was used
   to extrapolate the key lifetime values below for values up to 796
   bit keys.  (Although this extrapolation can be applied to 1024 bit
   keys and higher, as a precaution against over-optimism we do not
   propose they be used for more than one year.)

   Table 1 summarizes the above discussion regarding the maximum length
   of time that selected modulus sizes should be used.












   Weis                   Expires May, 2005                         4
              The Use of RSA Signatures with ESP and AH November, 2004


                    Number of     Recommended Maximum
                   Modulus Bits         Lifetime
                   ------------    -------------------
                     496-512             1 hour
                       576              10 hours
                       640               4 days
                       704              30 days
                       796              8 months
                       1024              1 year

             Table 1. RSA Key Use Lifetime Recommendations


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,
   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 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 62 to 256 bytes) does
      not cause packet fragmentation.

   RSA key pair generation and signing are substantially more expensive
   operations than signature verification, 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 modulus is needed for the application.
   Smaller modulus 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
   that store the signed data for a period of time. But since the
   digital signature is used only for sender verification purposes, a
   modulus that is considered weak in another context may be
   satisfactory.

   The size of the RSA public exponent can affect the processing
   required to verify RSA digital signatures. Low-exponent RSA

   Weis                   Expires May, 2005                         5
              The Use of RSA Signatures with ESP and AH November, 2004


   signatures may result in a lower verification processing cost. At the
   time of this writing, no attacks are known against low-exponent RSA
   signatures that would allow an attacker to create a valid signature
   using the RSAES-OAEP raw RSA scheme.

   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 ESP or AH 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

   Key management mechanisms 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 use of the algorithm. This
   is especially important for devices with constrained processors that
   might not be able to verify signatures using larger key sizes.

   A receiver must have the RSA public key in order to verify integrity
   of 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 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 to obtain data origin authentication for
   pairwise SAs is NOT RECOMMENDED. In the case of pairwise SAs (such as
   negotiated by the Internet Key Exchange [IKEv2]), data origin
   authentication can be achieved with an HMAC transform.  Because the
   performance impact of an RSA signature is typically greater than an
   HMAC, the value of using this transform for a pairwise connection is
   limited.

6.0 Security Considerations

   This document provides a method of authentication for ESP and AH
   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.

   Non-repudiation is not claimed as a property of this transform.  At
   times, the property of non-repudiation may be applied to digital

   Weis                   Expires May, 2005                         6
              The Use of RSA Signatures with ESP and AH November, 2004


   signatures on application level objects (e.g., electronic mail).
   However, this document describes a means of authenticating network
   level objects (i.e., IP packets), which are ephemeral and not
   directly correlated to any application. Non-repudiation is not
   applicable to network level objects (i.e., IP packets).

   A number of attacks are suggested by [RFC3552]. The following
   sections describe the risks those attacks present when RSA signatures
   are used for ESP and AH packet 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 from an eavesdropper.

6.2 Replay

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

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.

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 (e.g., by a key management protocol), 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.

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


   Weis                   Expires May, 2005                         7
              The Use of RSA Signatures with ESP and AH November, 2004


6.7 Denial of Service

   According to IPsec processing rules, a receiver of an ESP and AH
   packet begins by looking up the Security Association in the SADB. If
   one is found, the ESP or AH sequence number in the packet is
   verified. No further processing will be applied to packets with an
   invalid sequence number.

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

   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 against most attackers by encapsulating
   ESP or AH using an RSA Signature for authentication within ESP or AH
   using an HMAC transform for authentication. In this case, the HMAC
   transform would be validated first, and as long as the attacker does
   not possess the HMAC key no digital signatures would be evaluated on
   the attacker packets. However, if the attacker does possess the HMAC
   key (e.g., they are a legitimate member of the group using the SA)
   then the DoS attack cannot be mitigated.

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.

8.0 Acknowledgements

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

9.0 References

9.1 Normative References

   [AH] Kent, S., "IP Authentication Header", draft-ietf-ipsec-
   rfc2402bis-07.txt, March 2004.



   Weis                   Expires May, 2005                         8
              The Use of RSA Signatures with ESP and AH November, 2004


   [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", draft-
   ietf-ipsec-esp-v3-08.txt, March 2004.

   [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.

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

   [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

   [COST] R. Silverman, "A Cost-Based Security Analysis of Symmetric and
   Asymmetric Key Lengths", RSA Laboratories Bulletin, Number 13, April
   2000 (Revised November 2001).

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

   [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-15.txt, August 13, 2004.

   [PK-STRENGTHS] Orman, H., and P. Hoffman, "Determining Strengths For
   Public Keys Used For Exchanging Symmetric Keys", RFC 3766, April
   2004.

   [RSA155] RSA Laboratories, "RSA-155 is factored!",
   http://www.rsasecurity.com/rsalabs/node.asp?id=2098.

Authors Address

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

Full Copyright Statement

   Copyright (C) The Internet Society (2004). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.



   Weis                   Expires May, 2005                         9
              The Use of RSA Signatures with ESP and AH November, 2004


   This document and the information contained herein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.










































   Weis                   Expires May, 2005                        10