The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)
draft-ietf-msec-ipsec-signatures-06

Internet Engineering Task Force                              Brian Weis 
INTERNET-DRAFT                                            Cisco Systems 
Document: draft-ietf-msec-ipsec-signatures-06.txt            June, 2005 
Expires: December, 2005                                                 
 
             The Use of RSA/SHA-1 Signatures within ESP and AH  
 
Status of this Memo 
                                      
   By submitting this Internet-Draft, each author represents that  
   any applicable patent or other IPR claims of which he or she is  
   aware have been or will be disclosed, and any of which he or she 
   becomes aware will be disclosed, in accordance with Section 6 of  
   BCP 79. 
    
   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 references  
       -- [IKEV2] and [AES-GCM] should be changed to their assigned  
       -- RFC numbers, assuming they are published before this  
       -- document. 
    

     
   Weis                 Expires December, 2005                [Page 1] 


           The Use of RSA/SHA-1 Signatures with ESP and AH  June, 2005 
    
    
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...................................................9 
9.0 References.........................................................9 
  9.1 Normative References.............................................9 
  9.2 Informative References..........................................10 
Author's Address......................................................10 
Full Copyright Statement..............................................10 
Intellectual Property.................................................11 
 
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.  
    

 
   Weis                 Expires December, 2005                [Page 2] 


           The Use of RSA/SHA-1 Signatures with ESP and AH  June, 2005 
    
    
   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 
   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 
   an independently computed 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. 
 
   Two digital signatures encoding methods are supported in [RSA]. 
   RSASSA-PKCS1-v1_5 MUST be supported by a conforming implementation. 
   RSASSA-PSS is generally believed to be more secure, but at the time 
   of this writing is not ubiquitous. RSASSA-PSS SHOULD be used whenever 
   it is available. SHA-1 MUST be used as the signature hash algorithm 
   used by the RSA digital signature algorithm.  
    
   When specified for ESP, the ICV is equal in size to the RSA modulus, 
   unless the RSA modulus is not a multiple of 8 bits. In this case, the 
   ICV MUST be prepended with between 1 and 7 bits set to zero such that 
   the ICV is a multiple of 8 bits. This specification matches the 
   output S [RSA, Section 8.1.1] (RSASSA-PSS) and [RSA, Section 
   8.2.1](RSASSA-PKCS1-v1_5) when the RSA modulus is not a multiple of 8 
   bits. No implicit ESP ICV Padding bits are necessary. 
    
   When specified for AH, the ICV is equal in size of the RSA modulus, 
   unless the RSA modulus is not a multiple of 32 bits (IPv4) or 64 bits 
   (IPv6) [AH, Section 2.6]. In this case, explicit ICV Padding bits are 
   necessary to create a suitably sized ICV [AH, Section 3.3.3.2.1].  
    
   The distribution mechanism of the RSA public key and its replacement 
   interval are a group 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.  
 
   Weis                 Expires December, 2005                [Page 3] 


           The Use of RSA/SHA-1 Signatures with ESP and AH  June, 2005 
    
    
    
   Digital signature generation is performed as described in [RSA, 
   Section 8.1.1] (RSASSA-PSS) and [RSA, Section 8.2.1](RSASSA-PKCS1-
   v1_5). The authenticated portion of the AH or ESP packet ([AH, 
   Section 3.3.3], [ESP, Section 3.3.2]) is used as the message M, which 
   is passed to the signature generation function. The signer's RSA 
   private key is passed as K. Summarizing, the signature generation 
   process computes a SHA-1 hash of the authenticated packet bytes, 
   signs the SHA-1 hash using the private key, and encodes the result 
   with the specified RSA encoding type. This process results in a value 
   S, which is known as the ICV in AH and ESP. 
    
   Digital signature verification is performed as described in [RSA, 
   Section 8.1.2] (RSASSA-PSS) and [RSA, Section 8.2.2](RSASSA-PKCS1-
   v1_5). Upon receipt, the ICV is passed to the verification function 
   as S. The authenticated portion of the AH or ESP packet is used as 
   the message M, and the RSA public key is passed as (n, e). In 
   summary, the verification function computes a SHA-1 hash of the 
   authenticated packet bytes, decrypts the SHA-1 hash in the ICV, and 
   validates that the appropriate encoding was applied and was correct. 
   The two SHA-1 hashes are compared, and if they are identical the 
   validation is successful. 
 
    
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. 
    
   A conforming implementation MUST support a modulus size of 1024 bits. 
    
   Recent guidance [TWIRL, RSA-TR] 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. Table 1 summarizes the maximum length 
   of time that selected modulus sizes should be used. Note that these 
   recommendations are based on factors such as the cost of processing 
   and memory, as well as cryptographic analysis methods, which were 
   current at the time these documents were published. As those factors 
   change, choices of key lifetimes should take them into account. 
         

 
   Weis                 Expires December, 2005                [Page 4] 


           The Use of RSA/SHA-1 Signatures with ESP and AH  June, 2005 
    
    
                    Number of     Recommended Maximum 
                   Modulus Bits         Lifetime 
                   ------------    ------------------- 
                       768               1 week 
                       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.  
    
   Care should be taken that RSA signatures are not used for 
   applications when potential receivers are known to lack sufficient 
   processing power to verify the signature. It is also important to use 
   this scheme judiciously when any receiver may be battery powered. 
    
   The RSA asymmetric key algorithm is best suited to protect network 
   traffic for which: 
    
    o The sender has a substantial amount of 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 affects the processing required to create 
   and verify RSA digital signatures. Care should be taken to determine 
   the size of modulus 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 
   signatures may result in a lower verification processing cost. At the 
   time of this writing, no attacks are known against low-exponent RSA 

 
   Weis                 Expires December, 2005                [Page 5] 


           The Use of RSA/SHA-1 Signatures with ESP and AH  June, 2005 
    
    
   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 
    
   The RSA signatures algorithm cannot be used with an ESP Combined Mode 
   algorithm that includes an explicit ICV. The Combined Mode algorithm 
   will add the ESP ICV field, which does not allow use of a separate 
   authentication algorithm to add the ESP ICV field. One example of 
   such an algorithm is the ESP Galois/Counter Mode algorithm [AES-GCM]. 
    
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 using 
   the Authentication Key Length SA Attribute. 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. 
    
   Key management mechanisms negotiating the use of RSA Signatures also 
   MUST include the encoding method during policy negotiation using the 
   Signature Encoding Algorithm SA Attribute. 
    
   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. 
 
   Weis                 Expires December, 2005                [Page 6] 


           The Use of RSA/SHA-1 Signatures with ESP and AH  June, 2005 
    
    
     
    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 
   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 

 
   Weis                 Expires December, 2005                [Page 7] 


           The Use of RSA/SHA-1 Signatures with ESP and AH  June, 2005 
    
    
   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. 
    
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". 
    
   An assigned number is also required in the "IPSEC AH Transform 
   Identifiers" name space in the ISAKMP registry. Its mnemonic should 
   be "AH-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 December, 2005                [Page 8] 


           The Use of RSA/SHA-1 Signatures with ESP and AH  June, 2005 
    
    
   A second "IPSEC Security Association Attribute" is required in the 
   ISAKMP registry to pass the RSA signature encoding type. The 
   attribute class should be called "Signature Encoding Algorithm", and 
   it should be a Basic type. The following rules apply to define the 
   values of the attribute: 
    
                 Name                Value 
                 ----                ----- 
                 Reserved            0 
                 RSASSA-PKCS1-v1_5   1 
                 RSASSA-PSS          2 
    
   Values 3-61439 are reserved to IANA. New values MUST be added due to 
   a Standards Action as defined in [RFC2434]. Values 61440-65535 are 
   for private use and may be allocated by implementations for their own 
   purposes. 
    
8.0 Acknowledgements 
    
   Scott Fluhrer and David McGrew provided advice regarding applicable 
   key sizes. Scott Fluhrer also provided advice regarding key 
   lifetimes. Ian Jackson, Steve Kent, and Ran Canetti provided many 
   helpful comments. Sam Hartman, Russ Housley, and Lakshminth Dondeti 
   provided valuable guidance in the development of this document. 
    
9.0 References 
    
9.1 Normative References 
    
   [AH] Kent, S., "IP Authentication Header", draft-ietf-ipsec-
   rfc2402bis-10.txt, December 2004. 
    
   [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", draft-
   ietf-ipsec-esp-v3-09.txt, September2004. 
 
   [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. 
    
   [SHA] FIPS PUB 180-2: Specifications for the Secure Hash Standard, 
   August 2002.  
   http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf. 
    

 
   Weis                 Expires December, 2005                [Page 9] 


           The Use of RSA/SHA-1 Signatures with ESP and AH  June, 2005 
    
    
9.2 Informative References 
    
   [AES-GCM] Viega, J., and D. McGrew, "The Use of Galois/Counter Mode 
   (GCM) in IPsec ESP", draft-ietf-ipsec-ciph-aes-gcm-00.txt, April 27, 
   2004. 
    
   [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-17.txt, September 23, 2004. 
    
   [RSA-TR] B. Kaliski, "TWIRL and RSA Key Size", RSA Laboratories 
   Technical Note, http://www.rsasecurity.com/rsalabs/node.asp?id=2004, 
   May 6, 2003. 
    
   [TWIRL] Shamir, A., and E. Tromer, "Factoring Large Numbers with the 
   TwIRL Device", Draft, February 9, 2003. 
 
Author's 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 (2005). 
    
   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. 
 
   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. 

 
   Weis                 Expires December, 2005               [Page 10] 


           The Use of RSA/SHA-1 Signatures with ESP and AH  June, 2005 
    
    
    
Intellectual Property 
    
   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed 
   to pertain to the implementation or use of the technology 
   described in this document or the extent to which any license 
   under such rights might or might not be available; nor does it 
   represent that it has made any independent effort to identify any 
   such rights.  Information on the procedures with respect to rights 
   in RFC documents can be found in BCP 78 and BCP 79. 
    
   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use 
   of such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository 
   at http://www.ietf.org/ipr. 
    
   The IETF invites any interested party to bring to its attention 
   any copyrights, patents or patent applications, or other 
   proprietary rights that may cover technology that may be required 
   to implement this standard.  Please address the information to the 
   IETF at ietf-ipr@ietf.org. 
    
Acknowledgement 
    
   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 

 
   Weis                 Expires December, 2005               [Page 11]