On Thu, 29 Jul 2004, Thomas Hertz wrote:
> 
> To put it simply, the ipsec protocol consists of two parts. The first part

Or more precisely, the IKE protocol that sets up the SAs for IPsec.  None
of this part actually uses IPsec at all.

> (phase 1) is what is called ISAKMP key exchange. This is a protocol that
> takes places between the two isakmp-daemons running on the peers (on
> m0n0/FreeBSD this is racoon). This phase is where the authentication and
> initial keying takes place. On the m0n0, only a pre shared text string can
> be used as a key (commonly referred to as a PSK). When the negotiation
> succeeds it will result in a ISAKMP security association, based on the PSK.
> This link will further on be used to send new _random_ keys for the IPSEC
> SA:s. The IPSEC SA:s will in turn be used to encrypt the traffic with the
> random keys.

The P1 exchange also involves random session keys.  The PSK is only used
for establishing the peer's identity, and is never sent in the clear or
directly used to encrypt anything else.

> 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. 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.

The P1 and P2 exchanges are less different than you imply.  Both involve
session keys with some lifetime.  Both involve something else to establish
the peer's identity (the PSK for P1; the P1 SAs for P2).  In fact, some
have suggested that the benefits of the two-phase approach are highly
overrated and just add unnecessary complexity.

> > Question: when in use, will a tunnel transparently renew its SA without
> > having to disconnect and then reconnect? Will it delay the SA
> > re-negotiation until there is no activity on the link. Or will it cache
> > SA for further use?

Both the condition for "wanting the link up" and whether new SAs are kept
"on deck" for an upcoming expiration are implementation-specific.  One way
to get an idea is to look at the logs.

On Fri, 30 Jul 2004, Thomas Hertz wrote:

> 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:

> > > 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 biggest risk isn't directly related to the renewal rate, it's related
to aggressive mode.  In aggressive mode, the parties are in too much of a
hurry to complete the exchange to wait for the DH keys to be set up before
"proving identity", so the (hashed, of course) version of the PSK is sent
in the clear.  This doesn't directly reveal the PSK, but it means that a
single captured exchange has enough information to apply a dictionary
attack to the PSK.  Capturing additional exchanges is of no value at all
to an attacker, so the *only* benefit of a longer P1 lifetime is a reduced
exposure to capture.

In main mode, the identity proof is encrypted by the DH keys, so an
attacker would need to first break that encryption and *then* try to crack
the PSK.  Using RSA keys instead of a PSK introduces yet another level of
encryption, so it's safer than the PSK in each mode.

I'm not sure how many of the frequent recommendations (here) to use
aggressive mode are really warranted.

In either case, the PSK vulnerability mainly depends on the strength of
the PSK itself.  Your dog's name is not a good choice. :-) But with a
reasonably long, reasonably random key, you're at far more risk from a
compromised endpoint than intercepted traffic.  Especially when the key is
included in every backup of the config file. :-)

Excessively long P1 lifetimes have the same problem as excessively long P2
lifetimes, namely that the amount of data that's compromised as a result
of breaking a session key is larger, and the amount of ciphertext that's
available for cryptanalysis is larger.  Given the different nature of the
"P1 channel" usgae, it would seem that a longer lifetime makes sense, but
not ridiculously long.  In particular, not long enough to crack a session
key before it expires.

					Fred Wright