Subject: RE: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt

From: [email-masked]
Date: Thu, 12 May 2005 12:57:19 +0300

Tero Kivinen writes:
> 
> As I have not used that kind of system, can you tell me what
> are the estimated values for timers. I mean how often do they
> require reauthentication. Every 5 minutes? Every 15 minutes?
> Every hour? Every 24 hours?
> 
> And can you also explain what is the reasoning behind this
> reauthentication, i.e. what is the expected benefit from it.
>
> It cannot be for revocation checking, as there is much easier
> ways to do that (i.e. reload for example CRL every time new
> one comes, and check that all current SAs are still
> authenticated).
>
> It cannot be used for detecting users moving away from
> keyboard, as the required time frame there would be way too
> small to be practical (unless the authentication is based on
> the automatic token, but then on the other hand it is easier
> for the client to remove the SAs when token is removed).
> 
> So what is the reasoning behind this feature. It would make
> easier to talk about this. The draft says "The purpose of this
> is to limit the time that SAs can be used by a third party who
> has gained control of the IPsec peer."
>
> Can you give some concrete examples.

In one system that I have used, you need to enter the code 
from your SecurID token every four hours. In another one, 
the interval was ten hours.

The reasoning is the same as reauthentication in other places,
managing risk by reducing time-of-check to time-of-use.  For
example, if I once open VPN connection from some machine, the
connection won't stay open forever (potentially for months
or years, depending on how often your PC crashes :-). The 
risks we're trying to manage might involve a malicious third 
party gaining control over the laptop (or something), a third 
party accidentally using the connection for something, the user 
losing the token (and not noticing it because the system does 
not require it), the user forgetting that he/she has the 
connection open, etc. (And no, reauthentication alone does
not _solve_ any of these problems, but it does help in managing
the risks in many cases.)

For some types of hardware tokens (like SIM card in a phone)
it's of course easy to close the connection when the token is
removed. But for authentication that requires user interaction,
doing it "every now and then" is often a reasonable compromise
with usability (and often better than never doing reauthentication
at all).

(Of course, here one size doesn't fit all; each environment
is different, and IT administrators/whoever should be able
to decide for themselves whether reauthentication is necessary
and how long the interval should be.)

Best regards,
Pasi

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

---

From: Yoav Nir <[email-masked]>
Date: Thu, 12 May 2005 17:37:30 +0300

It's often not up to the IT administrator.  In many cases the security 
policy is dictated by some regulatory agency.  This is very common in 
financial institutions in Europe.  There is a government agency that 
publishes a security policy that all financial institutions must 
follow.
These usually include algorithms (3DES and SHA-1 are nearly universal 
for such things) as well as encryption key timeouts and authentication 
timeouts.

The times I usually see are from as little as 1 hour to as much as 24 
hours.  2 hours is probably the median.