Internet Engineering Task Force Brian Weis INTERNET-DRAFT Cisco Systems Document: draft-ietf-msec-ipsec-signatures-04.txt February, 2004 Expires: August, 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 August, 2005 1 The Use of RSA Signatures with ESP and AH February, 2004 Table of Contents 1.0 Introduction......................................................2 2.0 Algorithm and Mode................................................3 2.1 Key size discussion.............................................3 3.0 Performance.......................................................4 4.0 Interaction with the ESP Cipher Mechanism.........................5 5.0 Key Management Considerations.....................................5 6.0 Security Considerations...........................................5 6.1 Eavesdropping...................................................6 6.2 Replay..........................................................6 6.3 Message Insertion...............................................6 6.4 Deletion........................................................6 6.5 Modification....................................................6 6.6 Man in the middle...............................................7 6.7 Denial of Service...............................................7 7.0 IANA Considerations...............................................7 8.0 Acknowledgements..................................................8 9.0 References........................................................8 9.1 Normative References............................................8 9.2 Informative References..........................................8 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 August, 2005 2 The Use of RSA Signatures with ESP and AH February, 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 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. Several schemes for the RSA algorithm are described in [RSA]. Two schemes (RSAES-PKCS1-v1_5 and RSAES-OAEP) 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 (RSAES-PKCS1-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-PKCS1-v1_5scheme [RSA, Section 7.2] MUST be used as the encryption scheme. 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. 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 Weis Expires August, 2005 3 The Use of RSA Signatures with ESP and AH February, 2004 in an unnecessarily high cost of CPU cycles for the sender and all receivers of the packet. 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. 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. 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. For example, it should not be used 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, 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 Weis Expires August, 2005 4 The Use of RSA Signatures with ESP and AH February, 2004 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 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 Weis Expires August, 2005 5 The Use of RSA Signatures with ESP and AH February, 2004 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 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. Weis Expires August, 2005 6 The Use of RSA Signatures with ESP and AH February, 2004 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. 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". Weis Expires August, 2005 7 The Use of RSA Signatures with ESP and AH February, 2004 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-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. 9.2 Informative References [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. Weis Expires August, 2005 8 The Use of RSA Signatures with ESP and AH February, 2004 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. 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 August, 2005 9