Subject: RE: [Ipsec] Reauthentication in IKEv2

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

Yoav Nir writes:
> 
> Hi Jyothi.
> 
> As others have said, in IKEv2 there is only re-keying, no 
> re-authentication.  If you want the client to re-authenticate, 
> than the client needs to re-do the initial exchange.  The 
> gateway cannot be the initiator, especially in the case of EAP.
> 
> The missing piece is a way for the gateway to inform the client 
> that the client needs to re-authenticate.  I think this draft 
> solves this issue, but when I first published it, there was 
> little interest in the WG.  I guess not many see gateway-
> controlled (or periodic) re-authentication as important. If 
> you feel differently, please let me know.
> 
> http://www.ietf.org/internet-drafts/draft-nir-ikev2-auth-lt-00.txt

Yoav, I think this is an important issue, and the approach
presented in your draft is a good and simple way to solve it. 
Please continue work towards publishing this as an RFC!

WG chairs (& others), do you think that going for individual
submission for standards track would be the appropriate way
to proceed? Or would an informational document and/or making 
this a WG item be better?

Best regards,
Pasi

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

---

From: Jari Arkko <[email-masked]>
Date: Thu, 28 Oct 2004 16:06:48 +0300

> Please continue work towards publishing this as an RFC!

I support this draft too. Or maybe not the exact details
(see below) but I'd like to have this functionality.

Why would "please re-authenticate now" notification
not be simpler than a lifetime scheme? It would also
support other re-authentication policies than time-based
ones...

--Jari

---

From: Yoav Nir <[email-masked]>
Date: Thu, 28 Oct 2004 15:26:56 +0200

The reason I prefer a lifetime scheme to an "re-auth now" scheme is 
that re-authentication takes time.

When one peer tells the other to re-authenticate "now", it means that 
it will not accept any informational or create-chile-sa exchanges until 
the peer runs another initial exchange.  It might even mean that 
traffic will be blocked.  Take for example the case of SecurID.  A 
client for a SecurID user needs to show the user a dialog box, the user 
needs to find her token, type in the PIN, type in the temporary 
password and click the "re-auth" button.  All this can take many many 
seconds, certainly long enough for TCP connections to break.

This is why I prefer to let the client know in advance when 
re-authentication will be required.  The gateway has enough leeway to 
tell the client to re-authenticate within a short time (section 2: "The 
AUTH_LIFETIME notification ... MAY be sent by the original Responder at 
any time").  So while it may be reasonable to say "authenticate within 
1 minute", I don't think it's nice to say "you're blocked until you 
re-authenticate"

Please let me know what you think, as expiry time is just around the 
corner :-)

Yoav

On Oct 28, 2004, at 3:06 PM, Jari Arkko wrote:

>>> The missing piece is a way for the gateway to inform the client that 
>>> the client needs to re-authenticate.  I think this draft solves this 
>>> issue, but when I first published it, there was little interest in 
>>> the WG.  I guess not many see gateway-
>>> controlled (or periodic) re-authentication as important. If you feel 
>>> differently, please let me know.
>>>
>> presented in your draft is a good and simple way to solve it. Please 
>> continue work towards publishing this as an RFC!
>

---

From: Yoav Nir <[email-masked]>
Date: Thu, 28 Oct 2004 15:54:31 +0200

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.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 29 Oct 2004 11:47:25 +0300

> Please continue work towards publishing this as an RFC!

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.

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.

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.

Also why cannot the SAi1 change? 

> this a WG item be better?

When this was last time discussed here in the list there was not much
support for this. There were few emails and most of those argue either
the method how to do it, or the need for this.

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...
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 29 Oct 2004 12:17:24 +0300

> that re-authentication takes time.

So what? Server also know what it is asking, so it can set its own
timers so that client have enough time to do the authentication.

I.e for the RSA certificate authentication it could give 2 minutes,
and for SecurID authentication it could give 5 minutes. 

> the peer runs another initial exchange.  It might even mean that 

Why would it do that? The REAUTHENTICATE_NOW message means that start
reauthentication as soon as possible, but old IKE SA will stay active
and working until it is deleted. You can still create new child sa on
it and so on, but server will delete it quiet soon, so better create
new IKE SA...

> seconds, certainly long enough for TCP connections to break.

If you implement your client that way, then it is your problem.
Nowhere we mentioned that the old IKE SA or old IPsec SAs would stop
working. They continue work until they are explicitly deleted. 

> 1 minute", I don't think it's nice to say "you're blocked until you 

I think the REAUTHENTICATE_NOW means exactly that: reauthenticate as
soon as possible. The server will never BLOCK any traffic, it will,
simply send the delete to the IKE SA after it has decided that client
has had enough time to do the reauthentication. 
-- 
[email-masked]