Subject: RE: [Ipsec] Reauthentication in IKEv2

From: Uma Shankar Ch <[email-masked]>
Date: Thu, 28 Oct 2004 13:12:22 +0530

For policy lookups, it's very important to use the identity
(identifier) that was actually authenticated by the EAP method,
and this is not necessarily the same as IDi. Many EAP methods
have an internal identity exchange, and the initial identity
(e.g., IDi or EAP Identity Response) is used only for AAA
routing and selecting which method to use (see RFC 3748,
sections 5.1 and 7.3). "Reauthentication identities" in some
EAP methods are an obvious example where using IDi for policy
lookups fails, but that's not the main reason.

Uma: So, initiator wants to send the new authenticated identity by EAP 
Method (Say fast re authentication ID) what could be  the options at 
Responder side, so that it could successfully identify policy and can relay 
the same to EAP Server ---which eventually could cause Successful EAP Re 
Authentication too.

It seems with this,
Is it that, in the re authentication of IKE_SA case also IDi would be the 
same original IDi ???? and with this Responder  would relay the same and 
can't use the Re Authentication facility provided by EAP Method??
Or Really is there any other way, so that initiator can send two ID's one 
is the original IDi for policy matching and the second is the Authenticated 
EAP Re authentication ID to have EAP Re-authentication facility????? (It's 
not correct/possible)
Regards,
--Uma

At 09:25 AM 10/28/04 +0300, [email-masked] wrote:
>Hi,
>
>Do you mean reauthentication or rekeying an IKE SA?
>
>These are not the same in IKEv2: although reauthentication
>always does rekeying as well, the reverse is not true; and
>there are two separate lifetimes ("key lifetime" can be
>shorter than "authentication lifetime").
>
>CREATE_CHILD_SA exchange is related to rekeying without
>reauthentication, so EAP is not involved. Reauthentication is
>done by establishing a new IKE SA from scratch, creating new
>child SAs (equivalent to the old ones), and finally deleting
>the old IKE SA.
>
>For policy lookups, it's very important to use the identity
>(identifier) that was actually authenticated by the EAP method,
>and this is not necessarily the same as IDi. Many EAP methods
>have an internal identity exchange, and the initial identity
>(e.g., IDi or EAP Identity Response) is used only for AAA
>routing and selecting which method to use (see RFC 3748,
>sections 5.1 and 7.3). "Reauthentication identities" in some
>EAP methods are an obvious example where using IDi for policy
>lookups fails, but that's not the main reason.
>
>Best regards,
>Pasi
>
> > -----Original Message-----
> > From: Jyothi
> > Sent: Thursday, October 28, 2004 7:06 AM
> > To: [email-masked]
> > Subject: [Ipsec] Reauthentication in IKEv2
> >
> >
> > Hi all,
> >
> > I have some questions regarding the Reauthentication in IKEv2.
> >
> > 1. CREATE_CHILD_SA exchange is supported.
> >
> > In this when the IKE SA lifetime is completed, we use
> > CREATE_CHILD_SA exchange and form new IKE SA keys.
> >
> > Is it required to reauthenticate the peer may be after some
> > time???
> >
> > If reauthentication is required, in case of EAP
> > authentication, it says that CLIENT may use the EAP Fast
> > reauthentication ID in IKE exchange.
> >
> > In this case IKE policy lookup may fail, if we are searching
> > with the received identity.
> >
> > If reauthentication is required, what is the best way to proceed??
> >
> > May be the responder has to maintain some mapping between
> > policy identity and EAP negotiated identity.
> >
> > 2. CREATE_CHILD_SA exchange is not supported
> >
> > In this case, peer will always authenticate.
> >
> > If EAP authentication is used, do we have to go for EAP
> > re-authentication???
> >
> > Awaiting your responses.
> >
> > Thanks in advance,
> > Jyothi
>
>_______________________________________________
>Ipsec mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ipsec
_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: [email-masked]
Date: Thu, 28 Oct 2004 11:22:13 +0300

[email-masked] writes:

>> (identifier) that was actually authenticated by the EAP
>> method, and this is not necessarily the same as IDi. Many EAP
>> methods have an internal identity exchange, and the initial
>> identity (e.g., IDi or EAP Identity Response) is used only
>> for AAA routing and selecting which method to use (see RFC
>> 3748, sections 5.1 and 7.3). "Reauthentication identities" in
>> some EAP methods are an obvious example where using IDi for
>> policy lookups fails, but that's not the main reason.

> Uma: So, initiator wants to send the new authenticated
> identity by EAP Method (Say fast re authentication ID) what
> could be the options at Responder side, so that it could
> successfully identify policy and can relay the same to EAP
> Server ---which eventually could cause Successful EAP Re
> Authentication too.

The responder (acting as EAP pass-through authenticator) does
not, in general, know the real identity that will be authenticated 
by the EAP method before the EAP method starts. 

But fortunately this is not even necessary; the identity sent by 
the client (e.g., fast reauthentication id) still contains enough 
information to select the right AAA server and EAP method; and 
other policy lookups can be done after EAP is finished.

> It seems with this, Is it that, in the re authentication of
> IKE_SA case also IDi would be the same original IDi ???? and
> with this Responder  would relay the same and can't use the Re
> Authentication facility provided by EAP Method??  Or Really is
> there any other way, so that initiator can send two ID's one
> is the original IDi for policy matching and the second is the
> Authenticated EAP Re authentication ID to have EAP
> Re-authentication facility????? (It's not correct/possible)

The real identifier that was authenticated with EAP has to
come from the AAA server, not the initiator. With RADIUS,
this means the server has to include something in the 
Access-Accept message (e.g., User-Name attribute).

(See, e.g., draft-ietf-aaa-eap-09 (section 2.8.1), or
draft-adrangi-radius-chargeable-user-identity-02.)

Best regards,
Pasi

---

From: [email-masked]
Date: Fri, 29 Oct 2004 12:11:16 +0300

I also support idea of having just small extensions. Both of
the drafts mentioned here makes sense and I certainly would like
to see some progress with draft-eronen-ipsec-ikev2-eap-auth-01.txt.

Mika

> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> ext Jari Arkko
> Sent: 28 October, 2004 20:15
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Ipsec] Reauthentication in IKEv2
> 
> 
> [email-masked] wrote:
> > Yoav Nir writes:
> > 
> >>I think that other than my draft there are several other 
> >>ideas floating around like OCSP extensions, your own mobility 
> >>and multi-homing, IKE over TCP, IKE over SCTP, hash-and-URL 
> >>for PUT certificates, etc.
> >>
> >>Maybe instead of many small drafts, we need to join all these 
> >>into one big "Optional Extensions for IKEv2" document, which 
> >>will list all of these.
> > 
> > 
> > No, I don't think bundling them is a good idea. 
> > 
> > If we have a good solution for a relevant problem (like 
> your draft), 
> > there's rough consensus on that, and there are no important 
> > dependencies to/from other work, let's publish it. If we wait 
> > for everything else IKEv2-related to be finished, it'll take
> > several years before we have any RFCs.
> 
> I agree with this. Small, well-focused extensions is the
> way to go.
> 
> And I'd add your certificate-less server authentication
> with mutually authenticating EAP methods draft
> (draft-eronen-ipsec-ikev2-eap-auth-01.txt) to the list
> of good ideas to take forward. Mobility and multihoming
> is already being dealt with in a separate WG. If your
> draft and Yoav's draft could go forward somewhere then
> my highest priority items would be done.
> 
> --Jari
>

---

From: [email-masked]
Date: Fri, 29 Oct 2004 15:28:25 +0300

Tero Kivinen wrote:
>
> I think it would be much more simplier to siply send one
> informational message from the gateway when he wants the
> client to redo authentication, and if client does not finish
> reauthentication within some server specified timeframe then
> server will disconnect the connection.

Yes, but the client has more knowledge about the situation...  
E.g., if I have a long download ongoing, and I'm leaving for 
lunch, I could check how much time is remaining before the 
next reauthentication (instead of always reauthenticating
"just in case", or hoping for the best).

And sending the lifetime means one message exchange less
in >99% of the cases, so it's IMHO the simpler of the two
alternatives (but I guess we disagree here :-).

> We do not have negotiated lifetimes in the IKEv2, so why add
> them now?  You could already use the AUTH_LIFETIME specified
> in the draft that way, but I think that the lifetime parameter
> simply adds complexity and should be left out. The server
> needs to still keep the timers and verify that the client has
> done the authentication on time, so for the server he could
> simply keep timer and send the REAUTH_NOW notification when
> reauthentication is required.

Normal rekeying can be initiated by either end, and does not
require user interaction, so the peers can have their own
policies without any need for negotiation. But IMHO here
making the gateway's policy visible to the client would
(in some circumstances) provide benefits to the end user.

> Now client also must keep the timer and start authentication
> before the given time. If server would simply send the
> REAUTHENTICATE_NOW notifies, then client does not keep the
> timers to do this.

Unless the client also has a policy about reauthenticating the
server; then both parties need timers.

<snip>
>
> At least I didn't see enough support for this, in the list, so
> this could really be a WG item. I think this should propably
> be postponed to the IKEv2 extensions WG (I assume someone will
> someday create one), just like the
> draft-eronen-ipsec-ikev2-eap-auth-02.txt...

Are you against publishing them as individual submissions?

(Taking into account that it looks like several vendors will 
ship something like this in 2005, so the alternative is 
vendor-specific extensions.)

Best regards,
Pasi