Subject: [Ipsec] How to do authentication with EAP

From: Tom Stiemerling <[email-masked]>
Date: Mon, 7 Feb 2005 17:14:42 -0500

Can anybody provide clarification on this issue?

Section 2.16 of IKEv2 draft 17 states:

   For EAP methods that create a shared key as a side effect of
   authentication, that shared key MUST be used by both the initiator
   and responder to generate AUTH payloads in messages 5 and 6 using the
   syntax for shared secrets specified in section 2.15. The shared key
   from EAP is the field from the EAP specification named MSK. The
   shared key generated during an IKE exchange MUST NOT be used for any
   other purpose.

Should this not read messages 7 and 8 (as below)? Also how is the AUTH
processing to be done? What are you meant to do with the MSK?

   EAP methods that do not establish a shared key SHOULD NOT be used, as
   they are subject to a number of man-in-the-middle attacks [EAPMITM]
   if these EAP methods are used in other protocols that do not use a
   server-authenticated tunnel.  Please see the Security Considerations
   section for more details. If EAP methods that do not generate a
   shared key are used, the AUTH payloads in messages 7 and 8 MUST be
   generated using SK_pi and SK_pr respectively.

This would appear to be the case if using EAP-CHAP (MD5 password). In this
case how are SK_pi and SK_pr meant to be used in AUTH processing?

The draft seems to be very vague about these points...

Thanks, Tom

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 8 Feb 2005 14:12:45 +0200

Tom Stiemerling writes:
> Should this not read messages 7 and 8 (as below)?

Yes.

> Also how is the AUTH processing to be done? What are you meant to do
> with the MSK?

You use it as specified in the 2.15, i.e. calculate AUTH but instead
of the shared secret from the configuration you use MSK. 

> This would appear to be the case if using EAP-CHAP (MD5 password).

So you should not use such metehod :-)

> In this case how are SK_pi and SK_pr meant to be used in AUTH
> processing?

Instead of MSK use the SK_pi in the initiator end and SK_pr in the
responder end in place of shared secret. 
-- 
[email-masked]

---

From: Tom Stiemerling <[email-masked]>
Date: Tue, 8 Feb 2005 11:00:35 -0500

Thanks for elaborating. Also, it seems to me that if you use EAP-CHAP (MD5
password) along with
certificate based server authentication, then you are not subject to a man
in the middle attack, since
you know you are talking to the gateway before you do EAP.

Cheers, Tom

---

From: Jari Arkko <[email-masked]>
Date: Wed, 09 Feb 2005 13:41:00 +0200

> you know you are talking to the gateway before you do EAP.

Yes, but does the gateway know its really talking to you?
This depends on what you are doing. There are man-in-the-middle
attacks that take the victim's authentication run from somewhere
else and establish a tunnel where only the server is authenticated.
Suddenly the attacker is "authenticated" to the gateway, yet
the victim was doing something else. For instance, if you use
the same CHAP password for dial-in and VPN authentication,
someone who sees the PPP CHAP authentication run could use
it to construct a successful IKEv2-EAP-CHAP authentication
run. The victim sees a failed dial-in connection, and the
attacker gets access to the VPN.

This is one of the reasons why the use of weak methods such
as EAP-CHAP is discouraged.

--Jari