Re: [Ipsec] Reauthentication in IKEv2

[Yoav Nir <ynir at checkpoint.com>]

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.

On Nov 1, 2004, at 10:48 AM, Tero Kivinen wrote:

> Pasi.Eronen at nokia.com 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.
> --
> kivinen at safenet-inc.com


_______________________________________________
Ipsec mailing list
Ipsec at ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec