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

RE: clarification on IKEv2 with EAP



Resend to the list. My apologies if this appears twice. Mail I sent hours
later has appeared already on the list and this didn't.

> -----Original Message-----
> From: William Dixon [mailto:ietf-wd@v6security.com] 
> Sent: Thursday, April 01, 2004 2:54 PM
> 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
> > > 
> > 
> >