[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Weak authentication in Xauth and IKE
I have read the previous threads on Xauth (/hybrid) and IKE and while I
think this horse has been well-flogged, for me it is not yet dead. The
idea in the following article is that Xauth's laudable goal of strong
authentication without user certificates is not quite achieved in its
current draft. However, I think it can and should be extended to provide
authentication which is neither "insecure" nor "superfluous". This is
easily done...
Authentication Vulnerabilities in IKE and Xauth with
Weak Pre-Shared Secrets
John Pliam
pliam@ima.umn.edu
http://www.ima.umn.edu/~pliam
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.
Vendors 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 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.
Discovering a Weak Pre-Shared Secret in IKE
-------------------------------------------
The following attack works against both Main Mode and Aggressive Mode, but
we present the details for Aggressive Mode only. Ignoring most of the
irrelevant data, phase 1 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, digr),
3). I -> R: (digi),
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)).
digi Initiator's digest used to authenticate the DH exchange. It
is formed by,
digi = f(s, (g^i, g^r, CKYi, CKYr, SAi, IDi)).
digr Responder's digest used to authenticate the DH exchange. It
is formed by,
digr = 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 digi 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
digi* = f(s*, (g^i, g^r, CKYi, CKYr, SAi, IDi)).
If digi = digi*, then with high probability pw = pw*. Notice that
all candidate computations use data which was sent in the clear.
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, digr),
M computes digr'.
4). M -> I: (CKYr, SAr, g^q, Nr, IDr, digr'),
I checks digr' and then computes k'.
5). I -> M: (digi)
M computes digi'.
6). M -> R: (digi')
R checks digi' 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)).
digi' Forged Initiator digest:
digi' = f(s, (g^q, g^r, CKYi, CKYr, SAi, IDi)).
digr' Forged Responder digest:
digr' = 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.
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.
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, {digi, response}_K),
R decrypts K with p and checks both digi 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.
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 digi as above).
Our suggested solution is similar to the hybrid authentication
described in [Hyb], but that document doesn't clearly indicate
the need for confidentiality in the Xauth exchanges.
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.
Follow-Ups: