Arcanum : a secure and efficient key exchange ... - Semantic Scholar

Arcanum : A Secure and Efficient Key Exchange Protocol for the Internet Ajmal S. Mian Computer Science & Software Engineering The University of Western Australia 35 Stirling Hwy, Crawley, WA 6009, Australia [email protected]

Abstract A VPN establishes a cryptographically secure network using the existing insecure infra structure of the Internet. A number of protocols, including IPSec have been designed to establish VPNs. However, keys must be shared between the communicating peers before a VPN can be established. IKE protocol is used for exchanging keys between authenticated peers over the Internet. However, IKE is vulnerable to DoS attacks and has security holes. A number of protocols have been proposed to replace IKE but these protocols also have vulnerabilities of their own. In this paper we present an analysis of IKE and identify its security holes and design weaknesses. We also propose a more secure and efficient key exchange protocol, Arcanum, and carry out its security analysis and comparison with existing protocols. Arcanum is more secure, robust to DoS attacks and efficient in terms of time and number of messages.

1. Introduction The Internet is highly insecure, because the traffic passes unencrypted through a shared media. Private networks are expensive and face the problem of physically securing their lines. Virtual Private Networks (VPN) offer an economical solution to this problem by establishing a virtually private network while physically sharing the Internet media. Privacy is achieved by creating a cryptographically secure tunnel between authenticated peers, making the traffic virtually invisible to the rest of the Internet. Many protocols have been designed to form VPNs including IPSec [4], L2TP and PPTP. However, before these protocols can function, keys must be exchanged between the communicating peers. Manual exchange of keys is not possible in large and geographically spread networks. Moreover, keys must be refreshed frequently to limit the amount of data encrypted with a single key. Therefore, it is essential to design a protocol that can exchange the keys automatically. Internet Key Exchange (IKE) [2] is the proposed key exchange standard by the IETF for IPSec. IKE has been de-

Ashraf Masood Signals R&D Establishment, MCS National University of Sciences & Technology Tamizuddin Rd, Rawalpindi, Pakistan [email protected]

rived from two protocols, namely, the Oakley [10] and the SKEME protocol [5]. IKE is presently in the form of an RFC and has not been declared as a standard because it has certain shortcomings and security holes. Many researchers have carried out the analysis of IKE [8][11][12]. A number of possible successors have also been proposed to replace IKE which include IKEv2 [3], Just Fast Keying (JFK) [1] and SIGMA [6]. However, these protocols also have problems. IKEv2 adds complexity by keeping variable number of messages and does not fully exploit the strength of authentication. It is also vulnerable to a DoS attack. JFK compromises on perfect forward secrecy ( ) by reusing the . SIGMA has odd number of messages, hence, the delivery of the last message cannot be confirmed. In this paper we will analyse the IKE protocol and give a brief introduction and comparison of famous key exchange protocols. We will also propose a more secure, efficient and DoS resistant key exchange protocol and carry out its comprehensive security analysis. The rest of this paper is organized as follows. Section 2 contains a list of notation. In Section 3 we present the analysis of IKE. In Section 4 and 5 we propose a new protocol, Arcanum and discuss its salient features. Some qualitative results are presented in Section 6. In Section 7 we carry out the security analysis of Arcanum. Finally conclusions are given in Section 8.

2. Notation

Authenticator of message Certificate (public key) Cookie, a pseudorandom value (to avoid DoS) Certificate request Diffie-Hellman ( public value, group, public/private value pair, shared secret) ISAKMP header (* encrypted payload) IP address of ( for source, for destination) ISAKMP payload used to exchange values Nonce, a random value (to avoid replay attacks) Public key of , Public Key Encryption Public Key Encryption

Proceedings of the International Conference on Information Technology: Coding and Computing (ITCC’04) 0-7695-2108-8/04 $ 20.00 © 2004 IEEE

Pre-Shared Key Security Association , Digital signature (payload) A pseudorandom function (e.g. HMAC) applied on message using key

, is optional, is encrypted with key

, , Initiator, responder, gateway in key exchange

Message concatenation

3. Analysis of IKE Protocol 3.1. Security Holes of IKE Protocol IKE has no protection against simple IP flooding DoS attack because of improper use of cookies. The use of cookies was first introduced in Photuris [13] and the idea was to keep the responder stateless until the initiator proves that it can receive at its claimed IP address. But in IKE, the responder does keep state after receiving message 1 (see Fig. 1, Fig. 2 and Fig. 3). Hence, an illegitimate initiator can exhaust its memory by sending requests from bogus IP addresses. Even if IKE somehow avoids this attack, a CPU exhaustion attack can be launched against the responder by initiating a large number of s up to message 3. Message 5, in which the initiator authenticates itself, is never sent. based aggressive mode of IKE passes identities in the clear whereas both identities could have been hidden [11]. Aggressive mode has no protection against DoS attacks and comprises of three messages. If the final message is lost, the initiator will keep sending data into an incomplete for some time. In authentication (Fig. 3) it is assumed that the initiator already has the responder’s public key, an unlikely case in large networks. Another problem with is that in case the private keys are escrowed, which is likely the case with encryption/decryption keys, the escrow agent can impersonate all its clients. IKE claims that its mode (Fig. 2) hides both the identities from active attackers whereas in practice both the identities are exposed to an eavesdropper [12]. The responder doesn’t know who he is talking to when he receives message 5 and doesn’t know which to use. IKE addresses this problem by binding the identities to the corresponding IP addresses that can be seen by eavesdroppers. A reflection attack is also possible on the quick mode of IKE [8]. Since the same encryption key is used in both the directions, all the intruder has to do is to swap the IP addresses and reflect the message. The end result is that the initiator thinks that it shares two s with the responder whereas it has none.

3.2. Design Weaknesses of IKE Protocol An proposal in IKE must be accepted in full or rejected. Therefore, the initiator must propose every acceptable algorithm for one purpose (say encryption) with all acceptable algorithms for another purpose (say authentication). This leads to a combinatorial explosion of pro-

IKE

IKEv2

INITIATOR

RESPONDER

RESPONDER

HDR, SA

HDR, SA

r1

HDR, SA

E, Ni

E, Nr

HDR*,

i1, KEi

, Ni

SIGi

ERTr],

SIGr

RQ]

, Nr, [C

r1, KEr

HDR, SA

IDr, [C

HDR, SA

i1, KEi

HDR, K

ERTi],

RESPONDER

, Ni

HDR, SA

HDR, K

IDi, [C

INITIATOR

i1, KEi

HDR, SA

HDR*,

ARCANUM

INITIATOR

HDR*, IDi, [IDr], SI Gi, SAi2 [CERTi], [C RQ] , TSi, TS r ERTr], TSr IDr, [C i, HDR*, Gr, SAr2, TS SI

, Ni

, r1, KEr [CRQ] HDR, SAKErid, Nr,

HDR, SA

i1, SAr1 , KEi Ni [CRQ],, Nr, {IDi, ID , KErid, r, [C SAi2, SI Gi}Ke, ERTi], AUTH Tr], Dr, [CER AUTH HDR, {I r2, SIGr}Ke, SA

Figure 1. DS authentication. The small arrows indicate the saving of state by the responder. posals. Moreover, in IKE the number of negotiable parameters is very large which adds complexity and increases the number of round trip messages. Another complexity in IKE is the eight possible ways in which Phase 1 can be accomplished. In IKE, it is possible for two different s to have the same set of cookies [3]. This can cause problems since IKE uses the cookie pair for identification. Moreover, identity hiding in IKE is done since there can be many identities behind the same IP address. But IKE does not specify how the responder comes to know about the identity with whom the initiator wants to communicate.

4. The Arcanum Key Exchange Protocol We propose a new protocol, Arcanum (“sacred secret” in Latin), which is inspired by JFK and IKEv2. Authors of JFK propose a single phased approach and argue that two phases add unnecessary overhead and complexity. However, in Arcanum, we used a two phased approach because we believe that this overhead will be distributed among many Phase 2 s and will make the protocol more efficient in the long run. A single Phase 2 negotiation can be used to establish many s, further distributing the overhead. Moreover, the first Phase 2 is piggy backed on the Phase 1 (this approach has also been used in [3]). With a Phase 1 established, it is very easy to setup Phase 2 s, rekey existing s and pass control/error messages. Arcanum uses weak cookies, which are random values and strong cookies, which are pseudorandom values. Weak cookies are used by the initiator who keeps state and strong cookies are used by the responder when it wants to eliminate state after replying. Strong cookies are regenerated by the responder for validating message 3. IKEv2 suggested proposing more than one algorithm for each purpose in a single proposal (e.g. three encryption algorithms with two authentication algorithms) so that the responder can choose one algorithm of each type. This avoids the combinatorial explosion of proposals but introduces another problem in which an algorithm of one type may not work with an algorithm of another type. Therefore, in our opinion, proposing algorithms in the form of suits is a bet-


ter technique after all. Moreover, it is logical to propose suits with algorithms providing the same level of security. Arcanum proposes algorithms in suits but instead of writing individual algorithms, pointers to pre-configured (and publically available) algorithm suits are used. This greatly simplifies the payload and reduces its size. is said to be achieved when keys of different sessions are totally independent. It requires a key exchange each time a new is setup or an old is rekeyed. Generation of involve heavy computations and may become a problem if a large number of or rekeying requests arrive simultaneously e.g. a new peer comes online or DoS attack is launched. We have developed a strong technique in Arcanum that solves this problem without compromising on . Arcanum calculates a stack of , when the processor is idle. When an request arrives, it uses the current value from this stack and increments the pointer. If the establishes successfully it deletes the associated with it in the stack and calculates a new one to fill up the stack. If the does not complete successfully, it reuses the once the pointer completes a round trip. The stack size is large enough to avoid use of the same for multiple s. Thus Arcanum avoids wasting time calculating for illegitimate requests and legitimate requests which do not reach completion. This technique improves efficiency as well as provides protection against DoS attacks.

5. Arcanum Message Exchanges All message of Arcanum begin with the ISAKMP header (which also contains the cookies). The encryption bit in the header is set only if the entire message is encrypted. The initiator chooses the authentication method and guesses the in case of and modes. Once a Phase 1 is in place, Phase 2 s can easily be established with only two messages according to the Phase 2 of IKEv2 [3].

5.1. SA Establishment using DS Fig. 1 shows the message exchanges of mode of IKE, IKEv2 and Arcanum. IKE comprises of six messages and the responder saves state at message 1. The first two messages of IKEv2 (dotted lines) are optional and are only performed if the responder thinks it is under DoS attack. In IKEv2 the responder saves state at message 3. Arcanum only consists of four messages and the responder saves state after message 3 which is equivalent to message 5 of IKE and IKEv2. Message 1 of Arcanum contains Phase 1 proposals, initiator’s and a nonce. Message 2 comprises of an containing selected proposal, responders taken from the pre-calculated stack, an index ( ) to the stack and a nonce. The responder includes a strong cookie (Eqn. 1) in message 2. In Eqn. 1, is a local secret and is changed frequently to counter cookie jar attack. Maximum fields of the first two messages are

included in the cookie calculation for their integrity protection. serves two purposes. First, the initiator does not have to echo the responder’s complete , hence saving message space. Second, it protects against replay attacks by providing freshness to the cookie. After message 2, the responder can delete all state. Receiving a duplicate message 1 is just like receiving a new message 1. The initiator upon receiving message 2 echoes it back in message 3, except for the responder’s , and repeats its proposal and nonce. The rest of message 3 is encrypted and contains the initiator’s identity, the intended responder’s identity, the initiator’s certificate, a request for the responder’s certificate, Phase 2 proposals and the initiator’s . The entire message is authenticated with . Upon receiving message 3, the responder first checks if the value of is currently in use. If not, it drops the message otherwise it retrieves the corresponding value from the stack and recalculates the cookie for verification. If the cookie is valid, the responder proceeds with calculating the and derives all the required keys. Then it verifies the authenticator and decrypts the encrypted part and verifies the initiator’s . If the signature is valid the responder replies with an encrypted message 4 containing its identity, its certificate, an containing selected proposal for Phase 2 and its . Message 4 is also authenticated with . The following keying material is derived for a Phase 1 .

(1)

½ ¾ ¿ ½ ¾ ½ Where can be or depending upon which key is calculated. and are the first required number of bits of . Note that different keys are being used in the two directions of the to avoid reflection attacks.

5.2. SA Establishment using PSK Fig. 2 shows the message exchanges of mode of IKE, IKEv2 and Arcanum. IKE comprises of six messages and the responder saves state at message 1. IKEv2 is similar to its mode except that instead of it uses (calculated with ) for authentication. Encryption starts from message 5 in IKE and IKEv2 whereas in Arcanum, the very first message is encrypted (excluding )


IKE

IKEv2

INITIATOR

RESPONDER

RESPONDER

HDR, SA

HDR, SA

IKE

RESPONDER

INITIATOR

r1

HDR, SA

E, Ni

HDR, K

id, {SAi

E, Nr

, Ni

RQ]

, Nr, [C

r1, KEr

HDR, SA

H [IDr], HDR*, IDi, [CER ASHi, SA Ti i2, TSi, ], [CRQ] TSr

IDi, HAS

Hi

Hr

IDr, HAS

1, KEi,

Er, Nr,

Ar1, K

HDR,{S

r, DHg,

r}PKi,

HDR, {N

HDR,{I

ERTr], i, TSr IDr, [C TS HDR*, ASHr, SAr2, H

Di, [ID r], SA HASHi}K i2, e, AUTH r2}Ke,

Dr, SA

HDR, {I

HDR, SA

Ki

HASHr}

HDR*,

(3) (4)

5.3. SA Establishment using PKE Fig. 3 shows the IKE and Arcanum protocols with authentication. IKEv2 does not have a mode. Arcanum uses two different types of public keys for the responder. The public key of the gateway (outer identity) associated with the IP address and the public key of the actual responder. Therefore, the initiator need not know the actual responder’s public key in advance. Advantages of this method are that can also be negotiated, values are passed encrypted providing additional security and both

}Ke r}PKi,

HDR, {N

Er}Kn,

{IDr, K

An

HDR, {H

ASHi, SA

i2, [KEi 2]}K AUTH e,

HASHi

HDR*,

(2)

]

[CERTg

HDR, SA {N i1 [{Ni2}P i}PKg, {IDi, K , SAr1, Kr], [C ERTi]}KEi, [IDr], n, An

e, {IDr

{KEr}K

AUTH

Figure 2. PSK authentication. with a key derived as per Eqn. 3. Encrypted part of message 1 comprises of Phase 1 proposals, initiator’s and a nonce. (Eqn. 2) is an identifier to the being used and is different every time a new is established. Since only a legitimate initiator is able to produce a valid , a DoS attack cannot be launched against this mode. The s must be unguessable and unlinkable. To avoid the same being used by both the peers in simultaneous initiation of s, one peer uses odd numbers and the other uses even numbers (a similar approach is used in [6]). The responder varifies the , saves state and replies. Message 2 (encrypted with ) contains an with the responder’s selected proposal, its , a nonce and which authenticates the responder and also provides integrity protection to and so that the responder is not tricked into selecting the weakest proposal. The initiator verifies and replies with message 3. Message 3 (encrypted and authenticated with keys derived from ) comprises of the initiator’s identity, the intended responder’s identity, a proposal for the Phase 2 and to authenticate the initiator. The responder replies after verifying the authenticator and . Message 4 is also encrypted and authenticated and comprises of the responder’s identity and selected Phase 2 . is calculated according to Eqn. 4 whereas the rest of the keying material is calculated according to Section 5.1.

RESPONDER

i1, DHg

HDR, [H ASH {KEi}K e, {IDi}K (1)], {Ni}PKr, e, {CER Ti}Ke

Ni}Ki

INITIATOR

HDR, SA

HDR, SA

i1, KEi

HDR, K

ARCANUM RESPONDER

HDR, SA

, Ni

HDR, SA

HDR, K

HDR*,

INITIATOR

i1, KEi

HDR, SA

HDR*,

ARCANUM

INITIATOR

HASHr

ASHr,

HDR,{H

e, Er2]}K TH AU

SAr2, [K

Figure 3. PKE authentication. identities are protected against active attacks. Message 1 contains Phase 1 proposals and options. The responder selects a proposal and a and sends a strong cookie (Eqn. 5) and its IP address certificate . Since it’s IP address is fixed, it does not require secrecy. Message 3 contains the proposed and selected , the initiators nonce encrypted with . The rest of the message is encrypted with a symmetric key derived from the initiator’s nonce (Eqn. 7) and contains the initiators identity, value, optionally the initiators certificate, the intended responder’s identity, a second nonce encrypted with the intended responder’s public key in case it is available and the initiator wants to establish keys directly with the responder. Message 3 is also authenticated with (Eqn. 8). The responder varifies its cookie in message 3, saves state and replies with message 4 containing its nonce encrypted with . The rest of the message is encrypted with a symmetric key (Eqn. 7) and contains its identity and . Message 5 is encrypted with a key derived from the and contains to authenticate the initiator, proposals for the Phase 2 and optionally a value in case is desired for the Phase 2 . Note that this option was not included in and modes since the message size was already too large. Message 6 is similar to 5 except that it contains a single selected proposal. is calculated according to Eqn. 6 and the remaining keying material is calculated according to Section 5.1.

(5) (6) (7) (8)

6. Results We have tested a prototype implementation of Arcanum protocol in Java (code available at [9]). We tested the protocol by launching two types of attacks namely, IP flooding DoS attack (message 1 only) and Man-in-the-Middle DoS attack (message 1 and message 3). The attacks were not successful in providing DoS but only caused a minor delay in the legitimate SA establishment. The delay was more in the case of the latter attack as compared to the former attack.


7. Security Analysis of Arcanum 7.1. Protection Against DoS Attacks

processor is idle. The message sizes are greatly reduced by and by using protocol suit identifiers in introducing payload.

Arcanum uses strong cookies in and mode to mode, a valid counter IP flooding attacks. In is required for each acceptable message 1. Therefore, this attack is not possible against mode. Arcanum is robust to Man-in-the-Middle DoS attacks because it does not require the responder to perform heavy computations before the initiator has authenticated itself. An attacker having control of a router can easily launch a CPU exhaustion DoS attack against the remaining key exchange protocols. The attacker sends message 1, receives a reply and sends message 3 to make the responder calculate and all the keying material only to find out that the initiator is illegitimate. The attacker repeats the attack with different IP addresses causing DoS. Arcanum is robust to such attacks because it calculates a new only if a pair out of its precalculated stack has been used in a successful . is not compromised here because a new is used for . JFK counters this situation by reusing every successful . the and thus compromises on

7.2. Protection Against Other Attacks Reflection attack is not possible against Arcanum because all s are unidirectional. Moreover, it has a message counter to differentiate requests from responses and uses sequence numbers to differentiate between different s in progress. Replay attack is countered through the use of strong cookies. Strong cookies also provide protection against three other attacks. First, they provide integrity protection to maximum fields of message 1 and message ½. This provides protection against an 2, including the attack in which the responder is tricked into selecting the weakest proposal. Second, a cookie jar attack cannot be launched against the protocol because the value of local secret is changed frequently. Third, all the fields required by the responder to recalculate its cookie appear first in message 3. In case it is fragmented the responder can calculate its cookie from the first fragment to decide whether it should wait for the remaining fragments or not.

7.3. Extra Security in PSK Mode and Efficiency

Arcanum fully exploits the power of authenticawhich provides a low level authentication by using tion of the initiator right at the first message. When a message with a valid arrives, the responder knows that it and payis most likely a legitimate initiator. The loads are encrypted in message 1 and message 2 providing extra security. Arcanum is more efficient in terms of time and message sizes. It completes the protocol in minimum number of messages without compromising on the security of the protocol. The responder replies instantly to message 1, by using a from a stack which is filled up when the

8. Conclusion We have identified the security holes and design weaknesses of IKE and have presented a brief literature review of other famous key exchange protocols. We have also proposed a new key exchange protocol, Arcanum which is more secure, efficient and robust to DoS attacks. Some qualitative results have also been presented. Finally, we have carried out a detailed security analysis of Arcanum and have compared it to IKE, JFK and IKEv2.

References [1] W. Aiello, S. Bellovin, M. Blaze, R. Canetti, J. Loannidis, A. Keromytis and O. Reingold, “Efficient, DoS-Resistant, Secure Key Exchange for Internet Protocols”, 9th ACM Conference on Computer and Comm. Security, pp. 48–58, 2002. [2] D. Harkins and D. Carrel, “The Internet Key Exchange Protocol (IKE)”, IETF RFC 2409, Nov, 1998. available at http://www.ietf.org/rfc/rfc2409.txt [3] D. Harkins, C. Kaufman, S. Kent, T. Kivinen and R. Perlman, “Proposal for the IKEv2 Protocol”, Internet Draft (draft-ietfipsec-ikev2-02.txt), April, 2002 (expired Oct, 2002). [4] S. Kent and R. Atkinson, “Security Architecture for the Internet Protocol (IPSec)”, IETF RFC 2401, Nov, 1998. available at http://www.ietf.org/rfc/rfc2401.txt [5] H. Krawczyk, “SKEME: a versatile secure key exchange mechanism for Internet”, IEEE Symposium on Network and Distributed System Security, pp. 114–117,1996. [6] H. Krawczyk, “The IKE-SIGMA Protocol”, Internet Draft (draft-krawczyk-ipsec-ike-sigma-00.txt), Nov, 2001 (expired May, 2002). [7] D. Maughan et al., “Internet Security Association and Key Management Protocol (ISAKMP)”, IETF RFC 2408, Nov, 1998. available at http://www.ietf.org/rfc/rfc2408.txt [8] C. Meadows, “Analysis of the IKE Protocol Using NRL Protocol Analyzer”, IEEE Symposium on Security and Privacy, pp. 216–231, 1999. [9] A. S. Mian, “Implementation of Arcanum Protocol”, http://www.cs.uwa.edu.au/ ajmal/key.html, January, 2004. [10] H. Orman, “The Oakley Key Determination Protocol”, IETF RFC 2412, Nov, 1998. available at http://www.ietf.org/rfc/rfc2412.txt [11] R. Perlman and C. Kaufman, “Key Exchange in IPSec: Analysis of IKE”, IEEE Internet Computing, Vol. 4, No. 6, pp. 50–56, 2000. [12] R. Perlman and C. Kaufman, “Analysis of the IPSec Key Exchange Standard”, Tenth IEEE International Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, pp. 150–156, 2001. [13] P.K. Qualum and W. Simpson and DayDreamer, “Photuris: Session Key Management Protocol”, IETF RFC 2522, March, 1999. available at http://www.ietf.org/rfc/rfc2522.txt
