One document matched: draft-zhao-ipsec-multi-sender-sa-00.txt
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 <i, j> 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
| PAFTECH AB 2003-2026 | 2026-04-24 02:49:55 |