Authentication Vulnerabilities in IKE and Xauth with Weak Pre-Shared Secrets

John Pliam

2 Oct 99

Note: This article combines a few of my messages to the IETF working group on IPSec. I am thankful to Jianying Zhou and Tamir Zegman for their comments. 1. Introduction --------------- IPSec demands strong authentication resistant to active attacks [MSST]. The primary purpose of strong authentication in IPSec is to ensure integrity in the key exchanges. It is well-known, for example, that unauthenticated Diffie-Hellman is vulnerable to a simple active attack (see [Stin], cf. [HAC]). However, without issuing public keys for every user (or some other elaborate key management system) the only available authentication mechanism in the Internet Key Exchange (IKE) [IKE] is the pre-shared key mechanism. Unfortunately, pre-shared secrets are often implemented as passwords and it is demonstrated below that IKE is vulnerable to offline dictionary attacks when weak passwords are used. Some have attempted to strengthen IPSec authentication with extensions to IKE or ISAKMP which support various unilateral authentication schemes such as username/password, token card, 1-time passwords or challenge-response (see [Mam], [OR] and [XAUTH]). In particular, Xauth has made its way into the IPSec working group. However, virtually all of these unilateral authentication protocols fall trivially to active attacks unless they are protected by a layer of strong encryption (reason: the attacker merely passes token-codes, passwords and correct responses along to the authenticating peer as if the attacker were their owner). There is clearly a nasty catch-22 here: We need strong authentication to establish a strong session key. We need a strong session key in order to protect unilateral authentication schemes and thereby provide strong authentication. Relying on weak phase 1 authentication followed by traditional unilateral schemes in Xauth (protected by suspect session keys derived in phase 1) must be considered a violation of ISAKMP [MSST]. In other words, Two weak authentications != A single strong authentication. On the other hand, Xauth provides some of the means to solve this dilemma: Public key schemes such as SSL and 1-way Diffie-Hellman (aka El Gamal key exchange) [HAC] provide both strong confidentiality and strong unilateral authentication of one peer (usually the edge device) with minimal key management. Remote users don't need their own public keys. If (strong) legacy unilateral authentication schemes anticipated in [XAUTH] were used *after* 1-way public-key protocols, then phase 2 would not proceed unless the remote peer were truly strongly authenticated. The remainder of this document presents further details. First we describe attacks which exploit the vulnerabilities of IKE with weak pre-shared secrets followed by Xauth. After that we propose a secure Xauth authentication mechanism which could be used to protect a weak phase 1 authentication. 2. Discovering a Weak Pre-Shared Secret in IKE ---------------------------------------------- (Part I. Aggressive Mode) ------------------------- In general when a protocol uses a weak key for authentication, it is often possible to discover that key by making use of each peers' expected behavior when forming the protocols messages. In the best case, the adversary can successfully recover the key by mounting an off-line brute-force attack, making use of protocol messages acquired passively (e.g. using sniffers). In other cases, the adversary may have to resort to actively manipulating messages en route. In IKE, weak keys in Aggressive Mode can be discovered passively, while in Main Mode they can be discovered actively. In this section we treat Aggressive Mode only, deferring the Main Mode attack to sect. 4 below. Ignoring most of the irrelevant data, phase 1 aggressive mode establishes a session key k (aka SKEYID_e) between initiator I and responder R as follows: 1). I -> R: (CKYi, SAi, g^i, Ni, IDi), 2). R -> I: (CKYr, SAr, g^r, Nr, IDr, hr), 3). I -> R: (hi), where we employ the following notation: ------------------------------------------------------------------ I Symbol for initiator in the protocol. R Symbol for responder in the protocol. pw Shared secret. g^i Initiator's DH message: g multiplied with itself a random number i times. The number i is kept secret. g^r Initiator's DH message: g multiplied with itself a random number r times. The number r is kept secret. g^ir The DH negotiated secret = (g^i)^r = (g^r)^i. CKYi Initiator's randomly generated cookie from its ISAKMP header. CKYr Responder's randomly generated cookie from its ISAKMP header. SAi Various ISAKMP information. SAr Various ISAKMP information. Ni Initiator's nonce (randomly generated number). Nr Responder's nonce (randomly generated number). IDi Initiator's identification payload. IDr Responder's identification payload. f A pseudo-random function. s An intermediate secret, formed by s = f(pw, (Ni, Nr)). sd An intermediate secret, f(s, (g^ir, CKYi, CKYr, 0)). sa An intermediate secret, f(s, (sd, g^ir, CKYi, CKYr, 1)). hi Initiator's digest used to authenticate the DH exchange. It is formed by, hi = f(s, (g^i, g^r, CKYi, CKYr, SAi, IDi)). hr Responder's digest used to authenticate the DH exchange. It is formed by, hr = f(s, (g^r, g^i, CKYr, CKYi, SAr, IDr)). k Final session key, f(s, (sa, g^ir, CKYi, CKYr, 2)). ------------------------------------------------------------------ We claim that the initiator digest message hi contains enough information to rule out incorrectly guessed passwords. The adversary conducts an off-line dictionary attack, enumerating all candidates pw* and for each computing: s* = f(pw*, (Ni, Nr)), and hi* = f(s*, (g^i, g^r, CKYi, CKYr, SAi, IDi)). If hi = hi*, then with high probability pw = pw*. Notice that all candidate computations use data which was sent in the clear. 3. An Active Attack Against IKE Phase 1 Key Exchange ---------------------------------------------------- Armed with the shared secret pw, the adversary can now carry out an active attack against the phase 1 key exchange. Now acting as an intruder in the middle, M, the adversary manipulates the IKE messages as follows: 1). I -> M: (CKYi, SAi, g^i, Ni, IDi), M computes random secret q. 2). M -> R: (CKYi, SAi, g^q, Ni, IDi). 3). R -> M: (CKYr, SAr, g^r, Nr, IDr, hr), M computes hr'. 4). M -> I: (CKYr, SAr, g^q, Nr, IDr, hr'), I checks hr' and then computes k'. 5). I -> M: (hi) M computes hi'. 6). M -> R: (hi') R checks hi' and computes k'', where the following additional notation is used: ------------------------------------------------------------------ M Symbol for the intruder in the middle. g^q Adversary's public DH key. sd' Forged intermediate secret during active phase: f(s, (g^rq, CKYi, CKYr, 0)). sd'' Forged intermediate secret during active phase: f(s, (g^iq, CKYi, CKYr, 0)). sa' Another forged secret: f(s, (sd', g^rq, CKYi, CKYr, 1)). sa'' Another forged secret: f(s, (sd'', g^iq, CKYi, CKYr, 1)). hi' Forged Initiator digest: hi' = f(s, (g^q, g^r, CKYi, CKYr, SAi, IDi)). hr' Forged Responder digest: hr' = f(s, (g^q, g^i, CKYr, CKYi, SAr, IDr)). k' Forged final session key: f(s, (sa', g^rq, CKYi, CKYr, 2)). k'' Forged final session key: f(s, (sa'', g^iq, CKYi, CKYr, 2)). ------------------------------------------------------------------ Aside from the digest forgeries, this is nothing but the standard active attack against Diffie-Hellman [Stin], after which I and M share secret g^iq and M and R share secret g^qr. Both established session keys k' and k'' are known to the adversary, and M can simulate an encrypted tunnel between I and R by repeated decryption and re-encryption. Notice that the two forged digests appear to be legitimate because the arguments used to compute them are correct as far as the legal parties I and R are concerned. 4. Discovering a Weak Pre-Shared Secret in IKE ---------------------------------------------- Part II. Main Mode ------------------ We return now to the harder problem of discovering a weak key when phase 1 Main Mode is used. Here, a critical piece of information, hi, is encrypted with the newly exchanged DH key. The adversary must mount partially successful man-in-the-middle attack in order to trick one side into encrypting hi for him. Normally Main Mode works as follows: 1). I -> R: (CKYi, SAi), 2). R -> I: (CKYr, SAr), 3). I -> R: (g^i, Ni), 4). R -> I: (g^r, Nr), both sided compute k, 5). I -> R: {(IDi, hi)}_k, 6). R -> I: {(IDr, hr)}_k. Consider an active attack which begins the same way as the eavesdropping attack from the previous section (which assumed we already knew k). 1). I -> M -> R: (CKYi, SAi), 2). R -> M -> I: (CKYr, SAr), 3). I -> M -> R: (g^i, Ni), 4). R -> M: (g^r, Nr), 5). M -> I: (g^q, Nr), I computes: * shared secret g^iq, * sd = f(s, (g^iq, CKYi, CKYr, 0)), * sa = f(s, (sd, g^iq, CKYi, CKYr, 1)), * hi = f(s, (g^q, g^i, CKYi, CKYr, SAi, IDi)), * k = f(s, (sa, g^iq, CKYi, CKYr, 2)). 6). I -> R: {(IDi, hi)}_k, Now, we must modify the dictionary computations, using trial keys k* computed from trial passwords pw*. For each pw* in Dict do s* = f(pw*, (Ni, Nr)). sd* = f(s*, (g^iq, CKYi, CKYr, 0)). sa* = f(s*, (sd*, g^iq, CKYi, CKYr, 1)). k* = f(s*, (sa*, g^iq, CKYi, CKYr, 2)). decrypt with k* to obtain IDi and hi. hi* = f(s*, (g^q, g^i, CKYi, CKYr, SAi, IDi)). if hi = hi* then return pw* endif done We again claim that if hi = hi*, then with high probability pw = pw*. 5. Thwarting Xauth after IKE is Defeated ---------------------------------------- If the adversary has defeated IKE and established mutual session keys k' and k'', unilateral authentication systems provide little protection. For a challenge-response authentication, the Xauth protocol is defeated as follows: 7). R -> M: ({challenge}_k'), M decrypts with k' and re-encrypts with k''. 8). M -> I: ({challenge}_k''). 9). I -> M: ({response}_k''), M decrypts with k'' and re-encrypts with k'. 10). M -> R: ({response}_k'). 11). I <-> M <-> R: exchange (ok) and (ack). After M presents the correct response, phase 2 begins between the adversary and the edge device. 6. Protecting Unilateral Authentication with 1-Way Public Keys -------------------------------------------------------------- Assuming that the edge device R has a public key p which is signed by a trusted authority, I and R can engage in the following more elaborate Xauth protocol between phase 1 and phase 2: 1). R -> I: (cert = {p}_trusted-CA, challenge), I verifies p and generates random K. 2). I -> R: ({K}_p, {hi, response}_K), R decrypts K with p and checks both hi and response. 3). I <-> R: (ok) and (ack). Since only I and R know the value of K, the phase 1 digest is finally authenticated strongly, and phase 2 may securely proceed. If there are further challenges (as is possible with SecurID), each must be tied to hi in exactly the same way as is done in (2) above. 7. Conclusion ------------- We recommend that the "Security Consideration" section of [IKE] include an explicit warning of the vulnerability when weak pre-shared secret authentication is used -- as in done in RFC 2288 [SKEY]. Xauth's goal of strong authentication without elaborate key management is easily achieved by minor additions to the Xauth functionality (which provide for checking hi as above). Our suggested solution is similar to the hybrid authentication described in [Hyb]. That draft elects to modify IKE itself to achieve strong 1-way authentication *before* Xauth is used. Meanwhile we address the problem of using Xauth alone to recover strong authentication after a potentially weak phase 1 IKE key exchange has taken place. References ---------- [HAC] A.J. Menezes, P.C. van Oorschot, S.A. Vanstone, Handbook of Applied Cryptography", CRC Press, 1997. [Hyb] M. Litvin, R. Shamir, T. Zegman, "A Hybrid Authentication Mode for IKE", draft-ietf-ipsec-isakmp-hybrid-auth-02.txt, 1999. [IKE] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [Mam] Mamros, S., "Pre-shared key extensions for ISAKMP/OAKLEY", draft-mamros-pskeyext-00.txt, November 1997. [MSST] Maughhan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [OR] J. O'Hara, M. Rosselli, "Token Card Extensions for ISAKMP/OAKLEY" Internet Draft: draft-ohara-tokencard-00.txt, 1997. [SKEY] N. Haller, et al., "A One-Time Password System", RFC 2289, 1998. [Sti] D. Stinson, Cryptography: Theory and Practice, CRC Press, 1995. [XAUTH] R. Pereira, S. Beaulieu, "Extended Authentication within ISAKMP/Oakley", draft-ietf-ipsec-isakmp-xauth-04.txt, 1999. ------------------------------------------------------------------- John Pliam Last Modified: Tue Aug 13 10:18:50 EDT 2013 (recovered from wayback, removed stale links)