[Openswan Users] Key lifetimes (fwd)

Michael Richardson mcr at sandelman.ottawa.on.ca
Fri Oct 20 20:22:09 EDT 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


It has been asked why the IKE lifetime is 1hr and the ESP lifetime is 8
hours. BTW: there are no "maximums", just recommendations.

First, let's realize that the difference between them is <1 order of
magnitude, actually 3 powers of 2.  So, if an attacker can break AES in
less than 8 hours using some piece of hardware, using 8 copies of that
hardware they can break your IKE session in less than 1 hour.

There is therefore very little cryptographic reason to think that 1 hour
and 8 hours are very different. They are very close. 

So what are the operational reasons behind this?

In the absense of Dead Peer Detection, we will attempt to rekey the IKE
SA every hour. That means, we will attempt to determine if the the two
hosts can still communicate once an hour. This may well fail -- we
might have broken DNS servers, or cached data that is stale, etc. Recall
that DNS TTLs of 7200 seconds are common.

We get 7 chances to rekey the control connection before the IPsec SA
dies, and communication fails.  (Well, actually, if we fail it once we
try more often). Recall that TXT records may provide authorization, and
so infact a phase2 rekey may also fail due to DNS issues. Similar
arguments apply to LDAP. We don't retry a phase 1 when a phase 2 fails,
and it might be a problem in the phase 1 authorization that is
preventing the phase 2 from succeeded.

After 8 hours of communications failures, the important communication
fails. You will notice that part.

If we reversed it, we would find our IPsec SA needing rekeying after an
hour, and we'd try the IKE SA. If it had died, then you are SOL. What
would you do then? Probably kill the SA. If it happens regularly, you'd
abandon IPsec and just go clear.

- -- 
]            Bear: "Me, I'm just the shape of a bear."          |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr at xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [






-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBRTloMICLcPvd0N1lAQJU7QgAlIWEzlyR4kgO0g4AJRital/8785DtZTx
yrwmvdVYS+EOmo/mQZXpg1+VtGvihaXVPZP1xrbS6HADp3nNvYKFDWqc/pG0+TnD
clJ8vFYrnQ8aaTsUg3FRNEc/GXMGaQFBpBqPMl/FykUwbDZOEXPdN2ddMbt/W3LI
Ctc8ZBa7hOWk1v260HGS4sidhOxm/pIrFeQ7VD9B0a5/QcuPasRYpfhbYKkReHkT
Cc55ZqTniSudS/ofcmCMpPuFFr19ig5QyIYODRupUBcdpiPMXX74W1tHubOhv82T
l7UoKX1oYonRVFZXB/zl44h5wJPsRVAzBZnCSApdALSZtyXGzwf0mw==
=8j5u
-----END PGP SIGNATURE-----


More information about the Users mailing list