[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
> > >
> >
> >