Did I? :D I think I just hit reply. But stranger things have happened with
M$ Outlook.

> funny, you changed the Subject: of Vincent's message to that of my
> last message, and I didn't notice it until I've read it to the end ;-)
> 
> Thomas Hertz wrote:
> > So, the P1 can be seen as a "control channel" for the P2. P1 is
> performing a
> > more or less "intelligent" key exchange, and P2 is just static "dumb"
> rules
> > for how to encrypt the packets in question. For this reason the only
> real
> > vulnerable transaction is the initial P1 negotiation. If this is
> compromised
> > (or maybe even brute force cracked?) you could theoretically intercept
> the
> > keys used for the P2 transactions, and see the traffic the IPSEC is
> trying
> > to hide from prying eyes. That's why the P1 lifetime should be as long
> as
> > possible, especially when dealing with PSK:s.
> 
> Hmm, I don't get it. Why should it be as long as possible? To give an
> attacker more time to crack the key?
> 

It should be long to limit (and lower) the number of key exchanges. The key
exchange is what _really_ is vulnerable when using a (sometimes bad)
pre-shared key. I have to admit that I'm not an expert at encryption in
general, and not IPSEC in particular though. :)

> > The P2 is not as vulnerable as
> > the only thing you can get if you'd brute force it is the content of the
> > data transmitted during that particular Ipsec SA:s lifetime. This is a
> > reason for making the P2 shorter.
> 
> Same here: why shorter (and not longer)?

Here we have a real good reason for making a short TTL, because the key is
random! For the next SA lifetime we will deal with a brand new, random, key.
If you somehow would manage to (bruteforce?) find a key it would only be
valid to decrypt the packets during that SA:s lifetime. And, more
importantly, you cant use that key to derive the key used in the next SA.

But, as I mentioned, I'm not an encryption expert so my opinions are open
for discussion ;)
 
// Thomas Hertz