 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
-g
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
_______________________________________________ Ipsec mailing list Ipsec at ietf.org https://www1.ietf.org/mailman/listinfo/ipsec