[Openswan Users] Key lifetimes (fwd)

[Mike Horn]

Hi Michael,

Thanks for the explanation, in my experience when an IKE rekey fails you
usually also have a problem with IPsec SA's, but since these lifetimes are
configurable, users can configure these with values that they think are
appropriate.

One quick follow up question, you stated "BTW: there are no "maximums", just
recommendations."  The man  page for ipsec.conf states that the max for
IPsec SA lifetimes is 24 hours and the max IKE lifetime is 8 hours, are
these values incorrect?

keylife       <SNIP> (default 8.0h, maximum 24h). </SNIP>

ikelifetime   <SNIP> (default set by ipsec_pluto(8), currently 1h, maximum
8h) </SNIP>

<< Complete man page entries >>

keylife       how long a particular instance of a connection (a set  of
              encryption/authentication  keys  for user packets) should
              last, from successful negotiation to  expiry;  acceptable
              values are an integer optionally followed by s (a time in
              seconds) or a decimal number followed by m, h,  or  d  (a
              time  in  minutes,  hours, or days respectively) (default
              8.0h, maximum 24h).  Normally, the connection is  renego-
              tiated  (via  the keying channel) before it expires.  The
              two ends need not exactly agree on keylife,  although  if
              they  do  not,  there  will be some clutter of superseded
              connections on the  end  which  thinks  the  lifetime  is
              longer.

ikelifetime   how  long the keying channel of a connection (buzzphrase:
              ''ISAKMP SA'') should  last  before  being  renegotiated;
              acceptable   values   as  for  keylife  (default  set  by
              ipsec_pluto(8), currently 1h, maximum 8h).  The two-ends-
              disagree case is similar to that of keylife.

Thanks for your help.

-mike

-----Original Message-----
From: users-bounces at openswan.org [mailto:users-bounces at openswan.org] On
Behalf Of Michael Richardson
Sent: Friday, October 20, 2006 6:22 PM
To: users at openswan.org
Subject: Re: [Openswan Users] Key lifetimes (fwd)

-----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-----
_______________________________________________
Users at openswan.org
http://lists.openswan.org/mailman/listinfo/users
Building and Integrating Virtual Private Networks with Openswan: 
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155