[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Weak authentication in Xauth and IKE
Hi,
Let me start by saying that I agree that a Phase1 exchange authenticated by a
guessable pre-shared key followed by an XAUTH exchange is weak.
However, this weakness is not shared by Hybrid since if Hybrid authentication
is used, the edge device is authenticated by public keys.
You wrote:
"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."
I'm a bit puzzled by this remark since the Hybrid draft explicitly says:
"The Phase 1 Exchange MUST be immediately followed by a Transaction
Exchange whose initiator is the Edge Device. The Transaction Exchange
MUST be protected by the IKE SA negotiated in the preceding Phase 1
Exchange. This IKE SA MUST NOT be used for any other exchange before
the Transaction Exchange terminates successfully and the User is
authenticated. If the User fails to authenticate the IKE SA MUST be
discarded."
By proposing Hybrid more than a year ago we tried to solve the same problems
you are raising.
Was there any weakness or drawback you found in Hybrid that made you come up
with a different proposal?
Furthermore, your proposal does not clearly state what happens if XAUTH needs
more than one exchange to complete. I think you should encrypt all responses
since the first challenge could be a simple "User Name" challenge which a man
in the middle attacker can easily reply to.
Tamir.
John Pliam wrote:
> 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:
References: