[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: clarification on IKEv2 with EAP




No, it is the common situation you point out, the EAP messages terminate in a different host that the IKEv2 ones (although they are originated in the same host).
But the EAP messages, as these EAP methods have own protection mechanisms, will be protected in the entire path anyway.

-----Original Message-----
From: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of William Dixon
Sent: jueves, 01 de abril de 2004 21:54
To: David Mariblanca (ML/EEM); 'Tschofenig Hannes';
Pasi.Eronen@nokia.com; ipsec@lists.tislabs.com
Subject: RE: clarification on IKEv2 with EAP


David, is your situation also one where the path of EAP payloads originates
and terminates on the same hosts that IKEv2 ISAKMP SA does ? I'd think that
many uses of EAP will end up decapsulating it out of IKEv2 on the VPN
gateway & carrying it through Radius to the authentication server - in which
case EAP's protections are needed for its entire path.

> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com 
> [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of David 
> Mariblanca (ML/EEM)
> Sent: Thursday, April 01, 2004 11:13 AM
> To: 'Tschofenig Hannes'; 'Pasi.Eronen@nokia.com'; 
> ipsec@lists.tislabs.com
> Subject: RE: clarification on IKEv2 with EAP
> 
> 
> Hi,
> well, I am not specially worried about that, but rather to 
> implement extra protections when it's not needed. The EAP 
> methods I am now thinking about are EAP SIM and EAP AKA, 
> which already provide some protection mechanisms. If IKEv2, 
> on top of that, gives integrity and encryption to the EAP 
> messages, maybe we will spend unnecessary resources when 
> using EAP SIM/AKA over IKEv2, if we consider that either 
> IKEv2 or EAP SIM/AKA levels of protection are secure enough.
> But I guess other EAP methods do not provide the same level 
> of protection and that's why IKEv2 has to be designed in 
> order to not depend on EAP implementations.
> 
> In the other hand, after reading your paper (the one you are 
> writing with Pasi) I see very reasonable your proposal to 
> omit AUTH in message 4: if IKEv2 says that in messages 7 and 
> 8 the AUTH payloads will protect messages 1 and 2 
> (respectively), why to send AUTH in message 4 ? Does message 
> 2 need to be authenticated twice ?
> 
> Cheers,
> David.
> 
> -----Original Message-----
> From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com]
> Sent: jueves, 01 de abril de 2004 17:31
> To: David Mariblanca (ML/EEM); 'Pasi.Eronen@nokia.com'; 
> ipsec@lists.tislabs.com
> Subject: RE: clarification on IKEv2 with EAP
> 
> 
> hi david, 
> 
> i am only curious: 
> why do you worry about the protection of eap messages? 
> 
> ciao
> hannes
> 
> 
> > Ok, I see. I did not remember the EAP messages were already 
> integrity 
> > protected and encrypted with Sk_a and Sk_e. Then the AUTH payloads 
> > protect the IKE_INIT messages, the ones which were not sent 
> protected 
> > since there was not key material yet to do it, correct ?
> > 
> > 
> > -----Original Message-----
> > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]
> > Sent: jueves, 01 de abril de 2004 13:19
> > To: David Mariblanca (ML/EEM); ipsec@lists.tislabs.com
> > Subject: RE: clarification on IKEv2 with EAP
> > 
> > 
> > 
> > David Mariblanca wrote:
> > 
> > > I will give my interpretation of  chapter 16 and please confirm 
> > > if it is correct.
> > > - The EAP payloads are sent in the IKEv2 messages without 
> > > AUTH payloads. The AUTH payloads are sent only in the last 
> > > two IKEv2 messages, and they correspond to the last two EAP 
> > > messages, that is, AUTH in message 7 to EAP payload in 
> > > message 5, and AUTH in message 8 to EAP payload in message 6
> > 
> > No, AUTH payloads do not authenticate the EAP messages, they
> > authenticate the IKEv2 SA (basically information from the 
> > first two IKEv2 messages; first paragraph of Section 2.15 
> > explains exactly what is included in the "<message octets>").
> > 
> > (All EAP messages are also MAC'd with SK_ar/SK_ai, but this is 
> > not related to AUTH payloads; the integrity protection is 
> > included in the "SK{...}" notation).
> > 
> > Best regards,
> > Pasi
> > 
> 
>