IPSec Working Group Fan Zhao Internet Draft Gary Hong Expires: January 12, 2005 S. Felix, Wu UC Davis Souhwan Jung Soongsil Univ. HyunGon Kim ETRI July 12, 2004 Supporting Multi-Sender SA in a Secure and Efficient Way draft-zhao-ipsec-multi-sender-sa-00 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. This Internet-Draft will expire on January 12, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract: In this draft, we propose two efficient and practical mechanisms to enable the anti-replay service in the multiple sender SA. As IPSec is still under its development, this draft is mainly based on the existing RFCs. The two solutions require only minor change to the current standards and are back compatible. The security of new proposals and the impacts of possible future standards will be analyzed and discussed. Conventions used in this document 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 RFC-2119. zhao, et al. [Page 1] Internet Draft Supporting Multi-sender SA July 2004 1. Introduction Anti-replay service is to prevent the replay attack and potential DoS attack. However, it is not available in the multi-sender SA. Below is quoted from [10]. í—Sharing an SA among multiple senders is permitted, though generally not recommended. ESP provides no means of synchronizing packet counters among multiple senders or meaningfully managing a receiver packet counter and window in the context of multiple senders. Thus, for a multi-sender SA, the anti-replay features of ESP are not available.í˜ However, multi-sender SA is suitable to be used in a lot of applications. For example, multiple roaming users (Road Warriors) share a SA with the corporation security gateway. Lack of the anti-replay service will make such applications vulnerable to replay attack and Denial-of-Service attack. In this draft, we propose two practical solutions based on the current standards and IPv4 protocol to address this problem. We will describe and analyze each solution and then make a side-by-side comparison between them. 2. Overview 2.1 Terminologies We use the following terminologies in the following context. Sender: One end point of IPSec SA that is sending the packets. We consider the application where there is more than one sender. Receiver: The other end point of IPSec SA that is receiving the packets. We consider the application where there is only one receiver. Note that one sender can be a receiver at the same time (but not using the same SA) and there could be more than one receiver also like in the multicast scenario. But we only consider the many-to-one case and one direction here in order to simplify the problem. 2.2 Assumptions If we think multiple senders form a group, then each member in this group is assumed to be trustable. That means that we do not consider the insider attack here. We assume that all the senders share the same credential otherwise the receiver can distinguish the sender based on the different credentials. If the receiver can verify the credential provided by one sender, the receiver believes it is a valid user. We do not make any assumption on the sending pattern of each sender. 2.3 Analysis With the different applications and scenarios, this problem comes in the different forms and with the different difficulties. In the Road Warriors case, since each sender uses his own IP address, if AH is used, the secure gateway can distinguish the packet streams according to the source IP address, thus process them using the different anti-replay windows. However, if only ESP is used, the secure gateway cannot simply trust the source IP address because the attacker may intercept a zhao, et al. [Page 2] Internet Draft Supporting Multi-sender SA July 2004 lot of packets from the valid users and then replay those packets with the forged source IP address in order to make the secure gateway create and maintain a huge number of anti-replay windows unnecessarily. Note that since ESP does not cover the source IP address, the secure gateway cannot detect the forged packet. There also exists the application that multiple senders use the same source IP address. One example is that in the mobile IP, the mobile node uses its home agent to forward the packets to achieve the continuous connectivity when changing the point to attach to the Internet. Multi-homing is more and more widely adopted for the purpose of availability, fault tolerance and load balancing. One important application is to set up multiple home agents to overcome the single point failure. It is desirable that such configuration is transparent to mobile nodes. Multiple home agents (We assume that they belongs to the domain in order to simplify the problem.) are organized like in the anycast group. In this case, when IPSec is used to protect the communication between home agents and mobile node, mobile node will receive a lot of IPSec packets using the same source IP address from multiple different home agents. So source IP address cannot identify the sender always. 2.4 Goals We want to achieve the following goals listed in the descending priority: - Security: The new solution does not introduce any new security threat. In other words, it achieves the same security strength as in the original IPSec. - Scalability: The new solution can efficiently support any number of senders conceptually. - Efficiency: Too frequent IPSec SA renewals if IKE is used greatly degrade the performance. In order to achieve the efficiency, the lifetime of SA should be as long as in the original IPSec. - Compatibility: Minimal changes to the original IPSec protocol and the legacy IPSec node can still communicate with the upgraded IPSec node. - Transparency and privacy: The receiver should not be able to identify which sender or how many senders or the location of any sender for the privacy, security or whatever reason. In other words, senders should reveal as little information as possible. 2.5 Problem Formalization Given a set of senders, {s[0], s[1],íª, s[k-1]}, each sender, s[i], will send a sequence of packets denoted by p[i]. The jth packet sent by the sender i in this sequence is denoted by p[i][j]. The receiver, R, will receive the packets from the multiple senders simultaneously. For any received packet, q, R needs to tell which sender has sent q and the position of q in the sequence of packets sent by that sender. In other words, R knows a function F that takes q and s as the inputs and generates the as the output. zhao, et al. [Page 3] Internet Draft Supporting Multi-sender SA July 2004 The formalized problem above is similar to find the membership of each packet. We propose the following two solutions to embed the membership information into each packet. 3. Encoding method Each sender generates an m bit long random number independently and keeps it as a secret. The sequence number is still used in the same way as in the legacy IPsec protocol. Assume that one sender, s[i], generates a random number, n[i]. If the current sequence number is denoted by seq, s[i] puts seq in the sequence number field in the AH or ESP header and puts G(n[i], seq), called MIN (membership information), in a special field in the IPSec packet. Because R knows whether an IPSec packet is generated by a multi-sender SA according to SPI, R will use the function H to decode the membership information in this packet, H(MIN, seq) = H(G(n[i], seq), seq) = n[i] (An ideal candidate of H is G^(-1).). Based on the result, R categorizes the IPSec packets into streams and allocates an anti-replay window to each stream. The anti-replay window scheme is the same as before. Because usually the SA needs to be renewed after 2^32 packets are sent, the receiver counts the number of packets received under the multi-sender SA, if it reaches the limit, the receiver will trigger some action based on the policy. 3.1 System Parameters The length of random number is denoted by m that represents the largest number of senders supported and is determined by the needs of the application. In the following analysis, we assume that m is equal to 16, so the maximum number of senders is 65536, which should meet the needs of the most applications. The number of senders is denoted by k <= 2^m. 3.2 The way to generate the MIN The basic requirement of MIN is the uniqueness. If there is the coordination among senders or a central controller of a group of senders like in the multicast group, it is easy to guarantee the uniqueness of MIN proactively. For example, the MIN is generated from a counter. If there is no way to synchronize among senders, each sender can randomly generate their own MIN, for example by using their identity as input to a hash function. The probability that there is no repetition of MIN is ?[(2^m-k+i)/2^m] where i>=1 and i<=k. If more than one sender chooses the same MIN, the communication will be disturbed. If the involved sender detects this problem, it SHOULD regenerate a new MIN. (reactive method) zhao, et al. [Page 4] Internet Draft Supporting Multi-sender SA July 2004 3.3 Where to put MIN There is a requirement that MIN field must be authenticated, otherwise the anti-replay service is compromised. In order to resist the packet loss and reordering, we want to let every packet carry such MIN information. However, the AH/ESP protocol does not dedicate such a field in the AH/ESP header, thus we need to carefully embed such information in the packet. ESP protocol: IV field is 8 octets, so we can put MIN there. We will show how it will meet the requirement of IV for each encryption algorithm later. AH protocol: 16-bit IP ID field in IPv4 can be used. Since the sequence number field is 32-bit long, we can either split the sequence number in two with 16 bits each and then XOR these two portions or just use the lower portion of 16 bits. So if seq is denoted by s1||s2 (|| means the concatenation.), the generation of MIN will be either G(n[i], s1 xor s2) or G(n[i], s2). In the following text, we will use G(n[i], s2). We will show how this solution does not introduce the new possibility to break the semantics of IP ID field later. 3.3 The choice of G and H An ideal candidate of H is G^(-1). Also there are two good candidates for G. One is xor and the other is plus. There is minor difference between these two functions except that the calculation time of plus is not constant and the generated MIN by plus is incremented continuously (if G(n[i], s2) is used), which is as same as what most current operating system does with the IP ID field. In the following text, we will use xor as G. 3.4 AH Analysis The IP ID field is used for packet fragmentation. However since the recent measurements suggest that less than 0.25% of packets are fragmented, we think the impact is very minor. The interval between two different packets with the same IP ID from the same sender is at least 2^16. It is possible that two packets from the different senders have the same IP ID field. For example, MIN1 xor seq1 = MIN2 xor seq2. However, even without MIN, this situation is also possible in a multi-sender SA. It is also well known that packet fragmentation can cause the DoS attack, so it is better not to use the packet fragmentation. 3.5 ESP Analysis 3.5.1 Explicit IV vs. implicit IV So far all the encryption algorithms standardized require an explicit IV field, including the AES-CCM draft. There are a lot of advantages by using the explicit IV field. Please refer to the related documents. The drafts using the implicit IV are out of scope. They may use a different solution to support the anti-replay service in the multi-sender SA. zhao, et al. [Page 5] Internet Draft Supporting Multi-sender SA July 2004 3.5.2 Different IV requirements The different encryption algorithms have different requirements on IV. Below is summary of the IV requirements from the related RFCs and drafts. - Unique within the lifetime of key: [1] [9] [12] - Random within the lifetime of key: [4] [5] [8] (In the earlier RFC of CBC mode encryption [1], it only suggests the uniqueness like a counter although it identifies some risks that could happen.) 3.5.2.1 Random IV in CBC mode Randomness is a higher requirement than uniqueness. Consider the current standard and 3DES-CBC: 32-bit sequence number and 64-bit IV. If 16 bits are reserved for MIN, the rest 48-bit portion in the IV is randomized (Considering the predictable plaintext in the IP header, it may be better to use the higher portion of IV field to contain the MIN.). With 16 bits dedicated for the MIN, the whole IV field may be less í—randomí˜ than before; from the related RFCs, we are unaware of the quantitative impacts on security. The similar case is with AES-CBC also where an 128-bit IV is used. A good encryption algorithm should generate the random cipher text even with very small different input, so the security strength by using a í—lessí˜ random IV is not degraded. But if the less random IV really degrades the security strength, we can generate another implicit IV by using the MIN and the rest portion of IV field (Usually it is from the encryption of the previous packet.) as inputs to a collision resistant hash function for encryption and decryption while the MIN and the rest portion of IV field are still explicitly included in the payload. It is worth providing the anti-replay service at the cost of a single hash function for each packet. Note that this hash operation is done only after the integrity check is successful and will not cause a big burden. 3.5.2.2 Unique IV in Counter mode Since IV field is 64 bit long while sequence number field is only 32 bit, it still meets the requirement if reserving 16 bits from IV. 3.6 Extended Sequence Number The new drafts [10] [11] proposes to use 64-bit sequence number with the lower 32-bit portion transferred. In AH, the proposal works with ESN since MIN is encoded in the IP ID field. The impact on the ESP needs more analysis. Considering the 64-bit sequence number field and the 128-bit IV field in ESP CBC mode, the analysis above still applies. Considering the 64-bit sequence number field and the 64-bit IV field in ESP CBC mode, the analysis above still apply. But the probability to generate the unique IV becomes smaller. This actually happens to any encryption algorithm using a 64-bit IV even without MIN. AES counter mode requires a 64-bit unique IV used with one key. If IPSec sequence number field (32-bit) can be used as part of IV, the zhao, et al. [Page 6] Internet Draft Supporting Multi-sender SA July 2004 rest of original IV space can be used to store the MIN. Our proposal works with ESN. 3.7 Integrity-only Service in ESP Sometimes the integrity-only service is used due to the performance issue although it is not common and not as secure as AH. Without the IV field, we have to fit the encoded MIN into the packet payload at a specific position. 4. Splitting the Sequence Number Field We can split the sequence number field in two, sender ID field and sub sequence number field. It does not change the semantics of other field. Thus it can work with all encryption algorithms. But the processing of ESN needs to be changed. |<----------------32 bits--------------->| |----------------------------------------| | sequence number field | |----------------------------------------| |<--sender ID-->|<--sub sequence number--> In the method above the sender can only use the static sequence number range. It is possible to dynamically assign the sequence number range to the senders based on their traffic usage model. This solution needs to send the feedback from the receiver to the sender, thus it is more complicated. 5. Comparisons The static splitting method is not efficient in using the SA. If one sender uses all the assigned sequence number, although there is still unused sequence number, the SA has to be renewed. The ratio between SA real lifetime in static splitting method and that in the encoding method can be easily derived. And there are conflicts between the sender ID field and the sub sequence number field, i.e. the conflict between the SA lifetime and the number of senders supported. In order to fully use the SA lifetime, the larger the sub sequence number field, the better. However the smaller sender ID field will increase the probability that different senders generate the same ID if the sender ID is generated randomly. In order for each sender to use the unique ID, the coordination among senders is needed. It is not transparent because during the negotiation the receiver will know the number of senders ahead. And it will also cause the difficulty when multiple senders dynamically join the group to use this same SA in some applications. On the other hand, the encoding method meets all the requirements at a small cost of computation (xor and one addition hash function in the CBC mode). zhao, et al. [Page 7] Internet Draft Supporting Multi-sender SA July 2004 6. Implementation issues Since the multi-sender SA can be negotiated by IKE or set up manually, only the entities supporting it will take advantage of it. Those entities that do not recognize this kind of SA will just discard the request. 7. Security Consideration Security is central to the design of this document, and thus security considerations permeate the specification. 8. Conclusion In this draft we propose two different kinds of methods based on the current IPSec standards and IPv4 protocol to support the anti-replay service in the multi-sender SA. Because no dedicated field fulfills our needs, we have to reuse the existing fields. Anti-replay service and multi-sender SA are useful. We hope that the future IPSec standard will allow more flexibility in negotiating and processing specific SA that meets the needs of applications. We also hope that this draft provides some hints when designing more scaleable and efficient method to enable the anti-replay service in other complicated scenarios if arising in the future. References: [1] P. Karn, P. Metzger, and W. Simpson, "The ESP DES-CBC Transform", RFC 1829, August 1995. [2] S. Kent, and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [3] S. Kent, and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [4] R. Pereira, and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998. [5] C. Madson, and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998. [6] S. Kent, and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [7] S. Bradner. í—Key words for use in RFCs to Indicate Requirement Levelsí˜, RFC 2119, March 1997. [8] S. Frankel, R. Glenn, and S. Kelly, í—The AES-CBC Cipher Algorithm and Its Use with IPsecí˜, RFC 3602, September 2003. [9] R. Housley, í—Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)í˜, RFC 3686, January 2004. zhao, et al. [Page 8] Internet Draft Supporting Multi-sender SA July 2004 [10] S. Kent, "IP Encapsulating Security Payload (ESP)", draft- ietf-ipsec-esp-v3-08, Work in Progress, March 2004. [11] S. Kent, í—IP Authentication Headerí˜, draft-ietf-ipsec- rfc2402bis-07, Work in Progress, March 2004. [12] R. Housley, í—Using AES CCM Mode With IPsec ESPí˜, draft-ietf- ipsec-ciph-aes-ccm-05, Work in Progress, November 2003. [13] P. Hoffman, í—Cryptographic Suites for Ipsecí˜, draft-ietf- ipsec-ui-suites-06, Work in Progress, April 2004. [14] S. Kent, and K. Seo, í—Security Architecture for the Internet Protocolí˜, draft-ietf-ipsec-rfc2401bis-02, Work in Progress, April 2004. Authors' Addresses Fan Zhao Department of Computer Science University of California, Davis One Shield Avenue Davis, CA 95616 USA Phone: +1-530-752-3128 EMail: fanzhao@ucdavis.edu Gary Hong Department of Computer Science University of California, Davis One Shield Avenue Davis, CA 95616 USA Phone: +1-530-752-3128 EMail: shong@ucdavis.edu Felix Wu Department of Computer Science University of California, Davis One Shield Avenue Davis, CA 95616 USA Phone: +1-530-754-7070 EMail: wu@cs.ucdavis.edu zhao, et al. [Page 9] Internet Draft Supporting Multi-sender SA July 2004 Souhwan Jung Soongsil University 1-1, Sangdo-dong, Dongjak-ku Seoul 156-743 KOREA Phone: +82-2-820-0714 EMail: souhwanj@ssu.ac.kr HyunGon Kim Network Security Department ETRI 161 Kajong-Dong, Yusong-Gu Taejon 305-600 KOREA Phone: +82-42-860-5428 Email: hyungon@etri.re.kr Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph zhao, et al. [Page 10] Internet Draft Supporting Multi-sender SA July 2004 are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. zhao, et al. [Page 11] pact