Subject: [Ipsec] RE: Extended Authentication IKEv1 - IKEv2

From: Uma Shankar Ch <[email-masked]>
Date: Mon, 13 Sep 2004 23:12:08 +0530

Hi Hannes,

If you can permit me I want to clarify my queries with you personally.

Thanks for the reply.

-Uma

At 10:38 AM 9/13/04 +0200, Tschofenig Hannes wrote:
>hi uma,
>
>the work done in the ipsra working group had a different focus: add secure
>legacy authentication without changing ike. as a result see for example pic.

Uma:

Okay.

>the work on ikev2 and the discovered man-in-the-middle attack problems
>caused people to think in a different direction.

Uma:

It's unfortunate that even IKEv2 come in the category of PEAP, TTLS or PIC 
where only unilateral authentication is happening, i.e, server is 
authenticating to client. This caused the MITM attacks on all tunneled 
protocols which EAP methods. And IKEv2 got added to the list, of course 
with the cryptographic binding between inner EAP protocol and outer 
protocol avoided the MITM attack on all these including IKEv2.

The only exception is PANA over TLS --- POTLS. Where mutual authentication 
happens for outer protocol before EAP where client is authenticated to EAP 
server.

But, IKEv2 can inherently capable of avoiding the MITM attack, if client 
can authenticate to IKE responder.

And apart from that it could have avoided so many DoS attacks.

  My worry is DoS attacks on EAP-SIM with IKEv2
-------------------------------------------------------------------------

With this EAP-SIM didn't get the advantage of working with IKEv2, even 
though IKEv2 capable of giving the advantage.

My worry is in EAP-SIM in the initial rounds with  a simple Failure notify 
attacker  can close the connection causing DoS, just because client is not 
authenticated to server before the start of EAP.

EAP-SIM guys pushed this problem on PEAP or IKEv2 but unfortunately both 
didn't solve the problem. IKEv2 could have solved it.

Can you answer this.

And one more thing is, I strongly feel with out the 
"draft-eronen-ipsec-ikev2-eap-auth-01.txt" section 2.16 in IKEv2 doesn't 
give any advantage. As 2.16 mandating unilateral authentication and AUTH 
payload in the 4th message MUST be verified by client which would be a 
problem in real deployment scenarios where the client has to be configured 
with pre shared key or public key certificate. (If client is  a handset 
device).

Regards,
Uma

>ciao
>hannes
>
>________________________________
>
>         From: Uma Shankar Ch [mailto:[email-masked]]
>         Sent: Friday, September 10, 2004 7:32 PM
>         To: [email-masked]
>         Cc: [email-masked]; Tschofenig Hannes
>         Subject: Extended Authentication IKEv1 - IKEv2
>
>
>
>
>         Can IKEv1 be used with any mutual authentication  method using
>Xauth?
>         Am not aware of it.
>
>         In IKEv2 extended authentication happen as part of AUTH exchange
>before authenticating the
>         Client by the server. But, in IKEv1 it happens after establishing
>trusted authentication
>         channel with whatever way authentication is configured ( by
>pre-shared key or public key
>         certificates) by the administrator. Is it because with IKEv1, we
>can't use mutual authenticating
>         method?
>
>         In this context, in summary, I have the following questions
>
>         1. What is the rationale of changing the way extended authentication
>starts from v1 to v2?
>
>         Of course, there would be definitely certain advantages with this
>change, but am not able to
>         understand what are those.
>
>         (i) Is that, the repercussion of this change is the text in
>Security Considerations section
>         (Section 5) of the draft?
>
>         "Use of EAP authentication changes the probing possibilities
>somewhat.
>         When EAP authentication is used, the responder proves its identity
>         before the initiator does, so an initiator that knew the name of a
>         valid initiator could probe the responder for both its name and
>         certificates."
>
>         2.  I could not find any text relating to the change of the way
>extended authentication happen in  IKEv1 and the proposed standard in IKEv2
>in "Appendix A: Summary of changes from IKEv1" of
>"draft-ietf-ipsec-ikev2-15.txt".
>
>         3. The last minor point.
>
>         (i) Even "draft-ietf-ipsec-ikev2-15.txt" refers [EAP] as RFC 2284
>which is obsolete and the
>         new one being  RFC 3748?
>         (ii) In the text wherever applicable, the draft is mentioning
>"Extended Authentication ..."
>         it should have been "Extensible Authentication..."
>
>         Can any body clarify on this?
>
>         -Uma
>
>         www.intoto.com <http://www.intoto.com/>
>
>
>
>

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 13 Sep 2004 17:52:42 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Uma" == Uma Shankar Ch <[email-masked]> writes:
    Uma> But, IKEv2 can inherently capable of avoiding the MITM attack,
    Uma> if client can authenticate to IKE responder.

  Yes.
  But, if the clients can authenticate to the IKE responder... 
  -> WE DO NOT NEED EAP!

    Uma> With this EAP-SIM didn't get the advantage of working with
    Uma> IKEv2, even though IKEv2 capable of giving the advantage.

    Uma> My worry is in EAP-SIM in the initial rounds with a simple
    Uma> Failure notify attacker can close the connection causing DoS,
    Uma> just because client is not authenticated to server before the
    Uma> start of EAP.

  EAP-SIM is a Key Generating protocol, so we can do some kind of
channel binding.

  Is there a requirements document that explains why using, for
instance, EAP-SIM with IKEv2 is useful?
  (I'm serious)

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: "Srinivasa Rao Addepalli" <[email-masked]>
Date: Mon, 13 Sep 2004 15:49:55 -0700

>  My worry is DoS attacks on EAP-SIM with IKEv2

'Attacker' in this context, I assume MITM. If that is the case, how can he/she
send the 'Failure Notify' message?  How does this attacker know the 
DH shared secret, that was established between IKE peers during INIT
exchange?
Intoto Inc.
www.intoto.com

---

From: Uma Shankar Ch <[email-masked]>
Date: Tue, 14 Sep 2004 17:54:10 +0530

Yes.

Uma:

  Client (Initiator) would authenticate to both -- NAS (IKE Responder) with 
IKEv2(if 3rd message contains AUTH payload) and Back End EAP Server -- 
ultimately with the EAP configured authentication method as part of EAP 
mutual authentication/client to Server.

I was talking only about  DoS  attacks that could have been avoided with 
these--- otherwise these would be propagated up till  EAP method 
authentication round-trips.

Problem with this Way:
----------------------------------
As rightly pointed by Srini, there would be deployment problems as both IKE 
authentication related credentials and EAP related credentials need to be 
configured at the initiator.

Thanks,
--Uma

At 05:52 PM 9/13/04 -0400, Michael Richardson wrote:
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.2 (GNU/Linux)
>Comment: Finger me for keys
>
>iQCVAwUBQUYWpoqHRg3pndX9AQGuFAP9GVPObZaEuPZwVx8WNfBcXkPpPpDixqhm
>34bqWhN3NRFt64UjpKN0FBSmNGwUSsAvUiTZbT27z/j6vCipkuVk4FbQ9Ct542uV
>Fk+RY8x9IZdKVVZ90PEpPzVpdDlNqz3nNtkVlaT3WgwVxfM+esCguKjpSxpjpofV
>fdKay+6VLxE=
>=xxPr
>-----END PGP SIGNATURE-----
>