Subject: RE: [Ipsec] Reauthentication in IKEv2

From: Tero Kivinen <[email-masked]>
Date: Mon, 1 Nov 2004 10:48:37 +0200

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

So the client does not have any more information in this case, but the
user of the client does. The user in the client end can do much more
intelligent things regardless of the lifetimes sent in the protocol.

> 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 :-).

Note, that in the proposal the lifetime is sent AS A SEPARATE
informational exchange, so the number of packets and exchanges stays
same. Only difference is that if the lifetime parameter is there, then
BOTH client and server will need to keep track of it. If it is not
there, then only the AAA server need to keep track of it, and it can
inform the server that now it is time to do reauthentication, and the
server will then inform client etc.  

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

Some people do consider giving out the lifetime also gives out too
much information, i.e. the attacker knows that he has this much time
before the vpn connection to the corporate hq is cut out from the
laptop he stole. 

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

No, but I would think it would be better to start WG to take care of
them. There is people who are interested in them, and as the IPsec WG
is going to be shutdown, we need some place to discuss and process
them. 
-- 
[email-masked]

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

---

From: Yoav Nir <[email-masked]>
Date: Mon, 1 Nov 2004 12:07:40 +0200

IMO if it's a gateway's policy to trust a user for only 2 hours after 
authentication, then it must delete all SAs after two hours, unless the 
user authenticates again.  All this information is available to the 
gateway at the time of the Initial exchange, and this seems like the 
most natural time to inform the client.

Obviously, we can't send a "reauth_now" after two hours, as this would 
break connections, so a "reauth_now" would need to be sent earlier.  
How much earlier?  The IKE gateway cannot know how much time it takes 
to re-authenticate.  This involves packet lag, fumbling for the SecurID 
card or the USB token with the cert, typing and checking, and maybe 
even repeating the whole process if you typed wrong.  This time can be 
as short as 2 seconds in the case of a certificate on the client or 
softID (like SecurID but in software), or it can be as much as several 
minutes for a real token.

In any case, this sends the user a message saying "quickly enter your 
password or else your connections will be broken real soon, we don't 
know how soon."  OTOH, if at the Initial exchange the client gets a 
message saying "2 hours to go", it can show a countdown timer, or it 
can pop a re-authentication window an appropriate time in advance.  
This way, the client software has control of the user experience, which 
is much better than leaving it to some gateway.

As long as we're using Check Point clients with Check Point gateways or 
Cisco clients with Cisco gateways there will always be IKE or non-IKE 
ways of passing this information and fixing the user experience.  I'm 
thinking about generic clients that may come from companies like 
Microsoft or Apple, or some GPL project for Linux.  These clients 
should not have to depend on vendor-specific extensions to display the 
time before re-authentication is required.

Unless I hear some very compelling argument as to why "reauth_now" is 
superior, I think I'll stick with a lifetime message.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 1 Nov 2004 14:35:17 +0200

> most natural time to inform the client.

But lets say the gateways policy is "client need to reauthenticate
after it has done more than $10000 worth of transactions in the shop".
We do not want to send that policy to the client, so why should we try
to send the lifetime policy to the client? We did remove all the
lifetimes in the IKEv2, so why are we trying to add another. The
lifetimes did cause lots of trouble in IKEv1, so lets try to keep them
away from the IKEv2...

> How much earlier?

About few minutes is enough. I.e. propbably few times more than what
you would be willing to wait for the other end to finish its initial
exchange too. So if the server assumes that the client must finish the
initial authentication in 4 minutes, then the server would send the
reauth_now notify about 12 minutes before it will send delete
notifications. 

> The IKE gateway cannot know how much time it takes 

If it does not require user interaction it really does not matter
whether it is done 10 minutes before the actual hard deadline. And
server will most likely know what kind of authentication the client is
going to use, and it can modify the parameters accordinly (but there
is no need to do that).

> know how soon."

I do not see the reason why you have to hurry here, if you do not have
to hurry in the case where you know the time before. If the client is
written so that it starts doing the reauthentication 10 seconds before
the actual expiry, and assumes you can write in your password in that
time, then you will have even more hurry there.

On the other hand, if some adminstrator configures his gateway to
allow only 10 seconds to the reauthentication, then his users will
propably ask him to make that time longer. 

> superior, I think I'll stick with a lifetime message.

It is simplier and easier to implement. And I will continue arguing
against adding lifetimes to the IKEv2. The whole lifetime concept goes
against the design principles of the IKEv2. Your draft is the IKEv1
way to do the thing, not IKEv2. 
-- 
[email-masked]

---

From: Geoffrey Huang <[email-masked]>
Date: Tue, 02 Nov 2004 10:59:42 -0800

I have to agree with Tero on this thread.  The idea of the AUTH_LIFETIME 
notify strikes me as very similar to the negotiated lifetimes of IKEv1. 
  I quite like the way lifetimes are done in IKEv2.  Since it's a policy 
matter that each peer needs to enforce locally, I don't see a reason why 
the lifetime ever needs to be communicated.

Note that the idea of a REAUTH_NOW message also allows for signalling a 
peer's desire to re-authenticate at an arbitrary time.  I like this 
flexibility.

-g

Yoav Nir wrote:
> break connections, so a "reauth_now" would need to be sent earlier.  How 
> much earlier?  The IKE gateway cannot know how much time it takes to 
> re-authenticate.  This involves packet lag, fumbling for the SecurID 
> card or the USB token with the cert, typing and checking, and maybe even 
> repeating the whole process if you typed wrong.  This time can be as 
> short as 2 seconds in the case of a certificate on the client or softID 
> (like SecurID but in software), or it can be as much as several minutes 
> for a real token.
> 
> message saying "2 hours to go", it can show a countdown timer, or it can 
> pop a re-authentication window an appropriate time in advance.  This 
> way, the client software has control of the user experience, which is 
> much better than leaving it to some gateway.
> 
> Microsoft or Apple, or some GPL project for Linux.  These clients should 
> not have to depend on vendor-specific extensions to display the time 
> before re-authentication is required.
>

---

From: Yoav Nir <[email-masked]>
Date: Mon, 8 Nov 2004 10:18:35 +0200

And yet, even in IKEv2 when lifetimes are appropriate they are used.

Take the Cfg payload.  Since the back-end server is usually a DHCP 
server, we want to make the client request an extension to the 
INTERNAL_IPx_ADDRESS.  That is why there is an attribute called 
INTERNAL_ADDRESS_EXPIRY.

To quote from the draft, "INTERNAL_ADDRESS_EXPIRY - Specifies the 
number of seconds that the host can use the internal IP address.  The 
host MUST renew the IP address before this expiry time."  So IKEv2 is 
not averse to forcing hosts to keep timers when there is good reason.

Although being able to re-authenticate at an arbitrary time is nice 
flexibility, this is an attribute that involves human interaction, so 
the key consideration is not flexibility for the RA gateway, but 
predictability for the user.  Users hate pop-up demands for 
authentication.  That is why almost no websites use http 
authentication, but rather have an elaborate login screen.  Users would 
much rather have a countdown timer telling them how long they have 
before they need to type in their credentials again.  As others have 
mentioned, there is also the issue of going to lunch and leaving the 
long ftp going, as well as other protocols that require long TCP 
connections such as telnets, X11 and remote desktops.

My proposal still allows you to demand authentication at an arbitrary 
time, but such a demand should not be "reauthenticate now!" but rather 
"reauthenticate within 3 minutes".  IMO demanding reauthentication 
means you do not trust your peer anymore, and if that's the case it is 
only correct to refuse traffic and send a delete.  If the notification 
says "reauthenticate now" the user has no way of knowing how long she 
has to enter her credentials.  At least the pop-up authentication 
window should have countdown.

I've noticed that's it's a very small group here that is talking about 
it.  Do you think this means that there is little interest in 
re-authentication?

Yoav

On Nov 2, 2004, at 8:59 PM, Geoffrey Huang wrote:

> I have to agree with Tero on this thread.  The idea of the 
> AUTH_LIFETIME notify strikes me as very similar to the negotiated 
> lifetimes of IKEv1.  I quite like the way lifetimes are done in IKEv2. 
>  Since it's a policy matter that each peer needs to enforce locally, I 
> don't see a reason why the lifetime ever needs to be communicated.
>
> Note that the idea of a REAUTH_NOW message also allows for signalling 
> a peer's desire to re-authenticate at an arbitrary time.  I like this 
> flexibility.
>
> -g
>

---

From: Geoffrey Huang <[email-masked]>
Date: Wed, 10 Nov 2004 17:27:39 -0800

Yoav Nir wrote:
> To quote from the draft, "INTERNAL_ADDRESS_EXPIRY - Specifies the number 
> of seconds that the host can use the internal IP address.  The host MUST 
> renew the IP address before this expiry time."  So IKEv2 is not averse 
> to forcing hosts to keep timers when there is good reason.

You make a good point here.

> authentication.  That is why almost no websites use http authentication, 
> but rather have an elaborate login screen.  Users would much rather have 
> a countdown timer telling them how long they have before they need to 
> type in their credentials again.  As others have mentioned, there is 
> also the issue of going to lunch and leaving the long ftp going, as well 
> as other protocols that require long TCP connections such as telnets, 
> X11 and remote desktops.
 >
> "reauthenticate within 3 minutes".  IMO demanding reauthentication means 
> you do not trust your peer anymore, and if that's the case it is only 
> correct to refuse traffic and send a delete.  If the notification says 
> "reauthenticate now" the user has no way of knowing how long she has to 
> enter her credentials.  At least the pop-up authentication window should 
> have countdown.

I can see arguments from both sides, I guess.  Even with your re-auth 
scheme, a value of "0" seconds could mean "do it now," right?

> it.  Do you think this means that there is little interest in 

Um, no.  I think this is a valid problem that needs to be solved.

-g

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 10 Nov 2004 20:58:59 -0500

> scheme, a value of "0" seconds could mean "do it now," right?

I'd think so; I'd also hope that the encoding should also allow for
"reauth in 8 hours" notifications as well.

As was pointed out in the secsh working group yesterday for a related
user-authentication timeout, there are also accessibility concerns here;
some people enter text *very* slowly; 3 minutes may not be sufficient
for some.  

						- Bill

---

From: Yoav Nir <[email-masked]>
Date: Thu, 11 Nov 2004 12:05:53 +0200

A zero value would mean "reauthenticate now", but usually in such a 
case the gateway is not going to follow this notification with a delete 
immediately.

I would much rather have the gateway sending "reauth within 5 minutes"

> some people enter text *very* slowly; 3 minutes may not be sufficient

That is the reason why the gateway should send it together with the 
last packet of the IKE_AUTH exchange.  It might, for example, be a good 
idea for the client software to pop up an authentication dialog 3 
minutes before the authentication timeout elapses, but do it 3 extra 
minutes earlier if accessibility options are turned on.  It's 
definitely a client-side decision.

---

From: Geoffrey Huang <[email-masked]>
Date: Thu, 11 Nov 2004 09:07:09 -0800

> some people enter text *very* slowly; 3 minutes may not be sufficient

Yes, but as was pointed out earlier, you don't need this "re-auth in X 
seconds" scheme to achieve this.  You could simply have the server send 
a reauth_now message ahead of time.

I'm not disagreeing with you -- I'm just pointing out that the 2 main 
schemes I've read about in this thread differ only in *how* they 
communicate the reauth message.  One scheme says "re-auth in X number of 
seconds," whereas the other simply says "re-auth right now."

-g