Step Initiator (I) Responder (R) ((1)) Precomputation Precomputation Computation ((2)) by using PK R and/or SK I ((3)) Request Message =) Computation

Transcription

1 Resolution of ISAKMP/Oakley Key-Agreement Protocol Resistant against Denial-of-Service Attack Kanta Matsuura and Hideki Imai Institute of Industrial Science, University of Tokyo, Tokyo , JAPAN Abstract Key-agreement protocol will play an important role as an entrance to secure communication over the Internet. Specically, ISAKMP(Internet Security Association and Key Management Protocol)/Oakley key-agreement is currently a leading approach for communication between two parties. Basic idea of ISAKMP/Oakley is an authenticated Die- Hellman (DH) key-agreement protocol. This authentication owes a lot to public-key primitives whose implementation includes modular exponentiation. Since modular exponentiation is computationally expensive, attackers are motivated to abuse it for Denial-of- Service (DoS) attacks. In search of resistance against DoS attacks, this paper rst describes a basic idea on the protection mechanism for authenticated DH keyagreement protocols against DoS attacks. The paper then proposes a DoS-resistant version of three-pass ISAKMP/Oakley's Phase 1 where DoS attacks impose expensive computation on the attackers themselves. The DoS-resistance is evaluated in terms of (1) the computational cost caused by bogus requests and (2) a server-blocking probability. I. Introduction In order to enjoy secure communication over an open network, how to establish secret session keys is a fundamental problem. Looking at the Internet, ISAKMP(Internet Security Association and Key Management Protocol)/Oakley key-agreement [1] had been a leading approach for communication between two entities. After some modication, it has recently reached RFC as the Internet Key Exchange (IKE) [2]. ISAKMP/Oakley or IKE is based on a well-known Die-Hellman (DH) key-agreement protocol [3]. It is also well-known that this protocol on its own is vulnerable to intruder-in-the-middle attack; an attacker may intercept the protocol messages and masquerade as each of the users involved. Protection mechanisms against this attack has long been explored by providing entity authentication [4]. Hence ISAKMP/Oakley is also equipped with Manuscript received October 30, K. Matsuura, (ext. 2325), fax , kanta@iis.u-tokyo.ac.jp; H. Imai, (ext. 2313), imai@iis.u-tokyo.ac.jp, This work was partly supported by Research for the Future Program (RFTF) by Japan Society for the Promotion of Science (JSPS) under contact no. JSPS-RETF 96P authentication mechanisms which owe a lot to public-key primitives. Since these primitives are computationally expensive, malicious entities can initiate Denial-of-Service (DoS) attacks; they may launch quite a large number of bogus requests to exhaust the computational or communication resource of the targets who verify each request honestly. The purpose of this paper is to solve this problem of DoS. Specically, Section II. introduces our basic strategy [5] for protocol design. Then, after reviewing conventional versions in Section III., we propose a three-pass DoS-resistant version in Section IV. conforming to the strategy. Security consideration of the proposed version is subsequently given in Section V. Finally, Section VI. gives concluding remarks. II. Basic Strategy As mentioned in the introduction, secure and authenticated DH key-agreement protocols usually cost a lot in computation and/or in communication. In terms of communication complexity, three-pass protocols would be a practical solution. This section describes a design direction to protect three-pass DH protocols from DoS attacks. Let us assume that the initiator I and the responder R can use the same public-key infrastructure where public and secret keys of an entity X are denoted by PK X and SK X, respectively. Then three-pass DH key-agreement protocols can be typically structured as shown in Fig. 1. Our design direction for DoS-resistance is as follows: 1. Do not use heavy computation such as modular exponentiation in Step ((4)). 2. Send a random fresh material by Reply Message ((5)) implicitly in a way that the reconstruction of the material requires heavy computation in Step ((6)). We will refer to this material as \RF material" in the following. 3. Use the RF material for authentication. 4. Carry an acknowledgment material derived from the reconstructed RF material by Acknowledgment Message ((7)). 5. Verify the acknowledgment material at the beginning of Step ((8)). This verication must be computationally less expensive than the reconstruction of RF material in Step ((6)).

2 Step Initiator (I) Responder (R) ((1)) Precomputation Precomputation Computation ((2)) by using PK R and/or SK I ((3)) Request Message =) Computation by using ((4)) PK I and/or SK R (Session-key computation may be included.) ((5)) (= Reply Message Computation by using ((6)) PK R and/or SK I (Session-key computation may be included.) ((7)) Acknowledgment Message =) Computation ((8)) by using PK I and/or SK R ((9)) Key establishment Key establishment Fig. 1. Typical structure of three-pass authenticated DH key-agreement protocols with public-key infrastructure. Once conformed to this direction, the protocol discourages DoS attackers by \falling-together" nightmare; if the attacker and the target have similar level of computational power, the attacker must exhaust his/her resource in order to exhaust that of the target since a bogus acknowledgment material is detected before computationallyexpensive parts of Step ((8)). III. Aggressive Mode of ISAKMP/Oakley A. Conventional Versions In the key-management mechanism of IPv6 (Internet Protocol version 6), IKE has several key-agreement modes with dierent numbers of message-passes; Aggressive Mode is a three-pass protocol while Main Mode is a six-pass protocol in Phase 1, for example. In a situation where pre-shared keys are not available, \Aggressive Mode of ISAKMP/Oakley" is authenticated with publickey encryption or with digital signature. We will refer to these two authentication types as PKE-authentication and SIG-authentication, respectively. They are described in Fig. 2 (a) and (b), respectively. In Fig. 2, HDR is an ISAKMP header and the cookies CKY I and CKY R are set up in the header. SA is an SA (Security Association) payload with one or more proposals. A security association is a set of policy and keys used to protect information. The ISAKMP SA is the shared policy and keys used by the negotiating peers to protect their communication; the initiator may provide multiple proposals regarding SA while the responder must reply with only one. SAb is the entire body of the SA payload (minus the ISAKMP generic header). KE is a key-exchange payload which carries keying materials such as DH public values denoted by g x (generated by the initiator) and g y (generated by the responder). N I is the nonce payload of the initiator while N R is that of the responder. Likewise, ID I and ID R are their identity payloads, and SIG I and SIG R are their digitally-signed hash payloads. The hash payloads are pseudo-randomly computed from their nonces, DH public values, cookies, SAs, and IDs as HASH I = prf (SKEYID; g x kg y kcky I kcky R ksabkid I ) (1) HASH R = prf (SKEYID; g x kg y kcky R kcky I ksabkid R ) (2) where SKEYID is the output of a pseudo-random function; for PKE-authentication, while SKEYID = prf (hash (N I kn R ) ; CKY I kcky R ) (3) SKEYID = prf (N I kn R ; g xy ) (4) for SIG-authentication. k represents concatenation. HASH (1) is a hash of the certicate which the initiator is using to encrypt his/her nonce and identity. CERT is a certicate payload and the brackets [3] indicate that the content 3 is optional.

3 Initiator (I) HDR; SA; [HASH (1); ] KE ; ENC PK R (ID I ) ; ENC PK R (N I ) Responder (R)! HDR; SA; KE; HDR; HASH I! ENC PK I (ID R ) ; ENC PK I (N R ) ; HASH R (a) authenticated with public-key encryption (PKE-authentication) Initiator (I) Responder (R) HDR; SA; KE ; N I ; ID I! HDR; SA; KE ; NR ; ID R ; HDR; [CERT ; ] SIG I! [CERT] ; SIG R (b) authenticated with signatures (SIG-authentication) Initiator (I) HDR; SA; [HASH (1); ] ENC PK R (N I ) E KeI (KE) ; E KeI (ID I ) ; [E KeI (CERT)] Responder (R)! HDR; SA; ENC PK I (N R ) HDR; HASH I! E KeR (KE) ; E KeR (ID R ) ; HASH R (c) authenticated with public-key encryption (revised version: revised PKE-authentication) Fig. 2. ISAKMP/Oakley's Phase 1 authenticated by the use of public-key primitives (Aggressive Mode). ENC PK X indicates an encryption with the public key PK X of an entity X. E K is an encryption function of a private-key cipher where K represents an encryption key. Ke I and Ke R are ephemeral keys derived from the nonces and the cookies. The result of Aggressive Mode key-agreement is three groups of authenticated keying materials: SKEYID d = prf (SKEYID; g xy kcky I kcky R k0) (5) SKEYID a = prf (SKEYID; SKEYID d kg xy kcky I kcky R k1) (6) SKEYID e = prf (SKEYID; SKEYID a kg xy kcky I kcky R k2) (7) SKEYID e is used by the ISAKMP SA to protect its messages. SKEYID a is used by the ISAKMP SA to authenticate its messages. SKEYID d is used to derive keys for non-isakmp SAs. PKE-authentication requires two public-key encryption and decryption operations of both the initiator and the responder. The author of [6] modies it into a revised PKE-authentication which requires only one public-key encryption and decryption operation of each party while maintaining the security properties. The revised PKEauthentication is described in Fig. 2 (c). Ke I and Ke R are ephemeral keys derived from the nonces and the cookies. The rst step of the derivation is Ne I = prf (N I ; CKY I ) (8) Ne R = prf (N R ; CKY R ): (9) Then, if the desired length of Ke I is at most the length of Ne I, the sucient number of most signicant bits of Ne I is used as Ke I. If not, more bits are generated by applying the pseudo-random function prf with Ne I as the key and a byte of 0 as the input. The output of prf is then fed back into itself until sucient number of bits are obtained. For example, if the output of prf is 128-bit long and Ne I needs to be 320-bit long, then Ne I is the most signicant 320 bits of K, where K = K1 kk2 kk3 = prf (Ne I ; 0)kprf (Ne I ; K1 )kprf (Ne I ; K2 ) (10) Ke R is derived analogously. B. CPU-Exhaustion DoS Attack Aggressive Mode shown in the previous subsection is vulnerable to CPU-exhaustion DoS attack. In SIGauthentication, the protocol may require the responder to generate a digital signature with heavy computation before identifying the initiator. For example, RSA public-key primitives are recommended to be supported in ISAKMP/Oakley, and generation of RSA signatures costs much more than their verication due to the deployment of a relatively larger exponent in signature generation. This motivates a DoS attacker to launch tremendous number of arbitrary requests. Even if the signature generation is inexpensive, the responder must verify the signature for a fake acknowledgment message.

4 In PKE-authentication, the protocol requires the responder to decrypt two public-key encrypted payloads before identifying the initiator. Unfortunately, this decryption is also computationally expensive 1 and therefore can be abused by an attacker. Although the required number of decryption is reduced to be one, revised PKEauthentication can be attacked in the same scenario. A. Protocol IV. DoS-Resistant Resolution We consider how to enhance the resistance of SIGauthentication against DoS attacks. Specically, we introduce a modied hash payload in the acknowledgment from the initiator. This modied hash payload plays a role of the acknowledgment material in our basic strategy; a reconstructed RF material is used in the computation of the modied hash. The RF material is originally included in the reply from the responder implicitly. The proposed protocol is outlined in Fig. 3. We will refer to this protocol as revised SIG-authentication, in the following. In contrast to SIG-authentication, revised SIGauthentication is described as follows. 1. The rst message, a request from the initiator, is the same as that in SIG-authentication; the initiator sends ISAKMP header followed by SA, keying material, the initiator's nonce, and his ID. 2. The second message, a reply from the responder, is also the same as that in SIG-authentication but there is one restriction: to generate SIG R, the responder must use a signature scheme with the following properties: Expensive computation in signature generation can be completed in advance independent of the initiator, i.e., as a precomputation before receiving the request. The verication procedure includes reconstruction of an RF material R r. 3. In the computation of digitally-signed hash payloads, SKEYID is replaced with a one-way hashed value SKEYID 0 = hash(n I kn R ) which is random, fresh, but publicly-known. This does not change the security of the signature algorithm itself. If the initiator fears an attack with the replacement of the responder's public key, the certicate option is available to protect him/her from the attack. SKEYID e, SKEYID a, and SKEYID d are derived from the same SKEYID as in the conventional SIG-authentication. 4. In the computation of the initiator's digitally-signed hash payload, the hash payload is replaced with a modied hash payload. The modied hash is dened as HASH 3 I = prf (SKEYID 0 ; 1 For instance, RSA decryption costs much more than RSA encryption due to the deployment of a larger exponent. g x kg y kcky I kcky R kr r ksabkid I ). The acknowledgment message explicitly includes HASH 3 I; in the third acknowledgment message from the initiator, ISAKMP header is followed by the modied hash payload and the initiator's signature on it. A certicate payload CERT is optional. 5. On receiving the acknowledgment message, the responder rst checks whether the modied hash really uses the RF material R r. Then, if successful, he/she goes on to the signature verication procedure. 6. The signature scheme for SIG 3 I does not necessarily the same as that for SIG R ; SIG 3 I may use public and secret key pair whose relationship is dierent from that of (PK I ; SK I ) in Fig. 3. (PK I ; SK I ) is provided for the case when the initiator plays a responder's role in a dierent session. B. Formal Description By using the step number specied in Fig. 1, a more formal description of the proposed protocol is given as follows. ((Initiator's Keys)) Secret key: SK I 2 R [1; 2; ; q 0 2] Public key: PK I = g SK I mod p ((Responder's Keys)) Secret key: SK R 2 R [1; 2; ; q 0 2] Public key: PK R = g SK R mod p Step((1)) Each entity precomputes DH public values. Since the signature algorithm has computation steps which can be completed in advance, each entity carries out the precomputation and keeps the resultant RF materials. Step((2)) The initiator generates a request message as specied in SIG-authentication. A precomputed DH public value is used to create KE. Step((3)) The initiator sends the request message HDR, SA, KE, N I, ID I to the responder. Step((4)) The responder selects a proposal in SA, if necessary. The responder computes SKEYID 0 = hash(n I kn R ) and his/her hash payload HASH R = prf (SKEYID 0 ; g x kg y kcky R kcky I ksabkid R ). The responder generates his/her signature SIG R on HASH R. An RF material R r is used in the signaturegeneration and kept by the initiator to be used later again in Step ((8)). A precomputed DH public value is used to create KE. Step((5)) The responder sends his/her reply message HDR, SA, KE, N R, ID R, [CERT ; ] SIG R to the initiator. CERT is an optional certicate payload of SIG R.

5 Initiator (I) Responder (R) Secret key: SK I 2 R [1; 2; ; q 0 2] Secret key: SK R 2 R [1; 2; ; q 0 2] Public key: PK I = g SK I mod p Public key: PK R = g SK R mod p HDR; SA; KE; N I ; ID I! HDR; SA; KE ; N R ; ID R ; HDR; [CERT ; ] SIG 3 I, HASH 3 I! [CERT ; ] SIG R Fig. 3. ISAKMP/Oakley Phase 1 with DoS-resistant authentication (Aggressive Mode). The relationship between secret and public keys is an example for ElGamal-like signatures; p is a large prime and q is a large prime factor of p 0 1. g is a public integer with order q modulo p. SIG 3 I, HASH 3 I is a digitally-signed modied hash payload, which acts as the acknowledgment material in our basic strategy against DoS attack. Step((6)) According to the selected SA, the initiator veries the responder's signature SIG R. If successful, the initiator computes SKEYID 0 = hash(n I kn R ) and his/her modied hash payload HASH 3 I = prf (SKEYID 0 ; g x kg y kcky I kcky R kr r ksabkid I ), where R r is the RF material obtained in the signature-verication procedure. The initiator then computes his/her signature SIG 3 I on HASH 3 I. Step((7)) The initiator sends the acknowledgment message HDR, [CERT ; ] SIG 3 I, HASH 3 I to the responder. CERT is an optional certicate payload of SIG 3 I. Step((8)) The responder checks whether HASH 3 I is really constructed by using the correct RF material R r. If successful, the responder veries the initiator's signature SIG 3 I. Step((9)) If everything is successful, keying materials are nally established; from the DH public values, both the initiator and the responder compute and establish authenticated keying materials SKEYID = prf (N I kn R ; g xy ), SKEYID d = prf (SKEYID; g xy kcky I kcky R k0), SKEYID a = prf (SKEYID; SKEYID d kg xy kcky I kcky R k1); and SKEYID e = prf (SKEYID; SKEYID a kg xy kcky I kcky R k2). C. Examples In the following, we show two specic examples of revised SIG-authentication. The rst one is based on a shortened Digital Signature Standard (SDSS) [7]. As well as the original DSA (Digital Signature Algorithm) [8] or DSS (Digital Signature Standard) [9], the shortened DSS is unforgeable by adaptive attackers under the assumptions that discrete logarithm is hard and that the one-way hash function behaves like a random function [7], [10]. Precomputation by the responder: x r 2 R [1; 2; ; q 0 2], R r = g xr mod p Generation of the responder's signature: T R = hash (R r ; HASH R ) SIG R = (s 1 ; s 2 ) = (x r = (T R + SK R ) mod q; T R ) Verication of the responder's signature: ^R r = (g s2 1 PK R ) s 1 mod p. The initiator accepts the signature if and only if s 2 is equal to hash ^Rr ; HASH R. Computation of the modied hash: SKEYID 0 = hash(n I kn R ) HASH 3 I = prf (SKEYID 0 ; g x kg y kcky I kcky R k ^Rr ksabkid I ) Verication of the modied hash: The responder accepts the modied hash if and only if HASH 3 I is equal to prf (SKEYID 0 ; g x kg y kcky I kcky R kr r ksabkid I ). The second example is based on Schnorr's signature scheme [11]. Precomputation by the responder: x r 2 R [1; 2; ; q 0 2], R r = g xr mod p Generation of the responder's signature: T R = hash(hash R kr r ) SIG R = (s 1 ; s 2 ) = (SK R 1 T R + x r mod q; T R ) Verication of the responder's signature: ^R r = g s1 PK 0s 2 R mod p. The initiator accepts the signature if and only if s 2 is equal to hash(hash R k ^Rr ). Computation of the modied hash: SKEYID 0 = hash(n I kn R ) HASH 3 I = prf (SKEYID 0 ; g x kg y kcky I kcky R k ^Rr ksabkid I ) Verication of the modied hash: The responder accepts the modied hash if and only if HASH 3 I is equal to prf (SKEYID 0 ; g x kg y kcky I kcky R kr r ksabkid I ).

6 D. Evaluation Let us evaluate the DoS resistance in terms of the computational cost. The cost is measured by the total number of modular multiplications required for modular exponentiation. We classify DoS attackers into two types: (Type 1) An attacker who launches completely fake requests. (Type 2) An attacker who pays computational cost which is necessary for imposing modular exponentiation on the responder. In revised SIG-authentication, for example, the attacker should really verify the responder's signature in order to construct a correct modied hash. PKE-authentication, SIG-authentication, and revised PKE-authentication are implemented with famous encryption/signature schemes such as RSA, ElGamal, DSA, and Schnorr [4]. Regarding the cost of RSA, we ignore the cost of encryption or signature verication assuming that a relatively small exponent is used in RSA encryption or signature verication [7]. This allows better performance in the conventional schemes. Regarding the cost of modular exponentiation in RF-material generation, it is assumed that precomputation is available both for the attacker and for the responder. DH public values are also assumed to be precomputed. The computational cost is determined by the number of non-trivial modular multiplications and each multiplication costs in proportion to the size of the modulus (in bits). In the case of an attacker of Type 1, the computational cost per request is summarized as follows. Cost on the attacker's side: PKE-authentication (RSA): 0 PKE-authentication (ElGamal): 0 revised PKE-authentication (RSA): 0 revised PKE-authentication (ElGamal): 0 SIG-authentication (RSA): 0 SIG-authentication (ElGamal): 0 SIG-authentication (DSA): 0 SIG-authentication (Schnorr): 0 revised SIG-authentication (SDSS): 0 revised SIG-authentication (Schnorr): 0 Cost on the responder's side: PKE-authentication (RSA): 0:375jnj = 384 PKE-authentication (ElGamal): 1:5jpj = 1536 revised PKE-authentication (RSA): 0:375jnj = 384 revised PKE-authentication (ElGamal): 1:5jpj = 1536 SIG-authentication (RSA): 0:375jnj = 384 SIG-authentication (ElGamal): 4:5jpj = 4608 SIG-authentication (DSA): 3jqj = 480 SIG-authentication (Schnorr): 3jqj = 480 revised SIG-authentication (SDSS): 0 revised SIG-authentication (Schnorr): 0 where n is the RSA composite and jnj indicates the size of it (in bits). Recommended sizes are, say, jnj = jpj = 1024 and jqj = 160. The numerical results are based on this assignment. In revised SIG-authentication, dierent from the conventional authentications, the responder does not have to pay expensive cost for the requests from attackers of Type 1 who cannot send a correct modied hash. In the case of an attacker of Type 2, the verication cost of the responder's signature is estimated by assuming the help of simultaneous multiple exponentiation (SME), which is attributed by ElGamal [12] to Shamir and well summarized in [4]. This assumption reduces the cost on the attacker's side. By contrast, the attacker's signature is not assumed to be veried with the help of SME. This is because the responder does not want to pay precomputation cost for SME in preparation for Type 1 attackers. It should be noted that the responder does not know whether the attacker is of Type 1 or of Type 2 in advance. The computational cost per request is then summarized as follows. Cost on the attacker's side: PKE-authentication (RSA): 0 PKE-authentication (ElGamal): 0 revised PKE-authentication (RSA): 0 revised PKE-authentication (ElGamal): 0 SIG-authentication (RSA): 0 SIG-authentication (ElGamal): 0 SIG-authentication (DSA): 0 SIG-authentication (Schnorr): 0 revised SIG-authentication (SDSS): 1:75jqj = 280 revised SIG-authentication (Schnorr): 1:75jqj = 280 Cost on the responder's side: PKE-authentication (RSA): 0:375jnj = 384 PKE-authentication (ElGamal): 1:5jpj = 1536 revised PKE-authentication (RSA): 0:375jnj = 384 revised PKE-authentication (ElGamal): 1:5jpj = 1536 SIG-authentication (RSA): 0:375jnj = 384 SIG-authentication (ElGamal): 4:5jpj = 4608 SIG-authentication (DSA): 3jqj = 480 SIG-authentication (Schnorr): 3jqj = 480 revised SIG-authentication (SDSS): 3jqj = 480 revised SIG-authentication (Schnorr): 3jqj = 480 The attacker of Type 2 does not have to pay computational cost in the conventional authentications, while revised SIG-authentication imposes computational cost which is 1:75jqj = 58:3% 3jqj of that on the responder's side. Thus the attacker must exhaust the same order of computational resource if he/she wants to exhaust the responder's resource.

7 It should be noted that revised SIG-authentication does not reduce the eciency in a normal situation where no DoS-attackers appear; neither computational load nor communication overhead. In SIG-authentication with Schnorr's signature or DSA, anyway, the initiator constructs hash payload and the responder checks it. The dierence is in whether an intermediate variable obtained during the signature-verication procedure is used as an additional input to the initiator's hash payload or not. In conclusion, the revised SIG-authentication is the most DoS-resistant with keeping the eciency of Aggressive Mode. A. Assumption V. Discussion on Security In the proposed protocol, security of secret keys relies on the hardness of discrete-logarithm (DL) problem. Let us consider whether this requires an additional assumption or not. ISAKMP/Oakley in itself is not devoted to any specic encryption/signature schemes. However, it is restricted to the use of DH public values for keying. This means that the diculty of DL problem is assumed in the security consideration of ISAKMP/Oakley since the DH problem is at most as hard as the DL problem [13]. Hence we can say that the proposed version does not require any additional assumption regarding the security in that sense. B. Memory Exhaustion When the responder has sucient memory such that precomputed values are never exhausted, the proposed protocol alone well defeats DoS attacks. When insucient, specic DoS-resistance is not trivial although the proposed falling-together strategy allows us to assume memory exhaustion is more signicant than CPU exhaustion. Aiming at DoS-resistance regarding memory exhaustion, we can use network ingress lter (NIF) [14]. NIF routers restrict outgoing trac to known valid prexes. This subsection studies how signicantly our proposal and NIF contribute to the system availability. (Model) NIF limits the amount of bogus packets per attack. We assume that the attackers use the same number (M) of bogus requests per attack. The proposed strategy in keyagreement protocol reduces the damage caused by bogus requests; responders have only to pay for precomputation. We can interpret the cost-reduction eect by replacing M with M where 1. We will refer to as costreduction coecient. For simplicity, the following analysis deals with the most pessimistic situation such that = 1. It should be noted that the falling-together strategy would give better DoS-resistance if the implementation is optimized to reduce the cost-reduction coecient. The analysis considers a statistically equilibrated model whose state-transition diagram is illustrated in Fig. 4. As typical parameter assignment, we use Fig. 4. State-transition diagram of a responder in an ingress-ltered network. Each state is represented by the number of available sets of precomputed materials. C = as responder's memory capacity for precomputed materials, R = 0:001 as rate of valid request, and M = 256 as the number of bogus requests per attack. Precomputation power U was kept constant as a time unit. We considered the same security level as in the previous section, i.e., jpj = 1024 and jqj = 160. So if the performance level is in the order of several hundreds Kbps for public-key primitives, C = corresponds to a few MB memory. In this case, R = 0:001 causes a few valid requests per minute. We can interpret the state-transition diagram into a set of equations as follows. dp C dt = UP C01 0 (D + R)P C (11) dp i dt = UP i01 0 (D + R + U)P i + RP i+1 (12) (C 0 M < i < C) dp i dt = UP i01 0 (D + R + U)P i + RP i+1 + DP i+m (13) dp 0 dt = 0UP 0 + RP 1 + D CX j=0 (0 < i C 0 M) MX j=1 P j (14) P j = 1 (15)

8 Blocking Probability Po [%] Rate of Bogus Request Fig. 5. Blocking probability as a function of rate of attack when each attack is composed of M = 256 bogus requests. The cost-reduction coecient is assumed to be 1. where P i is the probability that the server is in state i and D represents the rate of bogus request. When statistically equilibrated, we can set each derivative dpi dt to be zero. Thus P 0, P 1, 1 1 1, P C can be computed by solving the resultant following linear equations. UP C01 0 (D + R)P C = 0 (16) UP i01 0 (D + R + U)P i + RP i+1 = 0 (17) (C 0 M < i < C) UP i01 0 (D + R + U)P i + RP i+1 + DP i+m = 0 (18) (0 < i C 0 M) CX j=0 P j = 1 (19) where P i is the probability that the responder is in state i. P 0 is called blocking probability since precomputed materials are exhausted in state 0. Results Figure 5 shows blocking probability P 0 as a function of rate of attack D. The blocking probability P 0 is lower than 10% even if the rate of attack D is 0.1. This suggests the responder is usually alive even when attacked by several hundred sets of bogus requests per minute. VI. Concluding Remarks A \falling-together" strategy was used to construct a DoS-resistant resolution of three-pass ISAKMP/Oakley key-agreement (Phase 1). As a result, attackers fear their own resource exhaustion. Thus we obtain a deterrent to DoS attacks. If we consider key-agreement protocols in upper layers, one may argue that DoS protection should rely not on key-agreement protocols but on a lower-layer mechanism. In the development of the next-generation Internet, however, even a network-layer protocol is going to be equipped with security mechanisms including public-key cryptography. This motivated us to modify a currently known versions of ISAKMP/Oakley or IKE in IPv6; the proposed version provides a signicantly better resistance against CPU-exhaustion attack in IP layer itself. In our analysis, memory exhaustion was also considered in a non-optimized ingress-ltered network. For typical parameter assignment, the responder is usually alive even when attacked by several hundred sets of bogus requests per minute. If the implementation is optimized to make better use of the falling-together strategy for costreduction on the responder's side, DoS-resistance would be more signicantly improved. References [1] D. Harkins and D. Carrel, \The resolution of ISAKMP with Oakley," Internet Draft, draft-ietf-ipsec-isakmp-oakley-33.txt [2] D. Harkins and D. Carrel, \The Internet Key Exchange (IKE), " rfc2409, Nov [3] W. Die and M. Hellman, \New directions in cryptography," IEEE Trans. Information Theory, vol. IT-22, no. 6, pp. 644{ 654, [4] A. Menezes, P. van Oorschot, and S. Vanstone, Handbook of Applied Cryptography, CRC Press, Inc., Boca Raton, Florida, [5] K. Matsuura and H. Imai, \Protection of authenticated keyagreement protocol against a denial-of-service attack," Proceedings of 1998 International Symposium on Information Theory and Its Applications (ISITA'98), pp. 466{470, Oct [6] R. Canetti, P. Cheng, and H. Krawczyk, \A revised encryption mode for ISAKMP/Oakley," Internet Draft, draft-ietf-ipsecrevised-enc-mode-01.txt, July [7] Y. Zheng, \Digital Signcryption or How to Achieve Cost(Signature & Encryption) << Cost(Signature) + Cost(Encryption)," in Advances in Cryptology Crypto'97, Aug. 1997, Lecture Notes in Computer Science 1294, pp. 165{ 179, Springer-Verlag. [8] D. W. Kravitz, \Digital signature algorithm," U. S. Patent # 5,231,668, July [9] FIPS 186, \Digital Signature Standard," Federal Information Processing Standards Publication FIPS PUB 186, 1994, U. S. Department of Commerce/N.I.S.T., National Technical Information Service. [10] D. Pointcheval and J. Stern, \Security proofs for signature schemes," in Advances in Cryptology EUROCRYPT'96, U. Maurer, Ed., 1996, pp. 387{398, Springer-Verlag, Lecture Notes in Computer Science [11] C. P. Schnorr, \Ecient signature generation by smart cards," Journal of Cryptology, vol. 4, pp. 161{174, [12] T. ElGamal, \A public key cryptosystem and a signature scheme based on discrete logarithms," IEEE Trans. Information Theory, vol. IT-31, no. 4, pp. 469{472, [13] U. M. Maurer and S. Wolf, \Die-Hellman oracles"," in Advances in Cryptology CRYPTO'96, N. Koblitz, Ed., Aug. 1996, pp. 268{282, Springer-Verlag, Lecture Notes in Computer Science [14] P. Ferguson and D. Senie, \Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoong," rfc2267, Jan