RE: PFS + rekeying interconnection

["Rajesh Mohan" <rajeshmn@future.futsoft.com>]

I would like to know what PFS in Ikev2 tries to acheive.

Option 1: When a key is compromised, then the data send in that PFS interval
is compromised. Data send during previous interval is safe. It seems to me
that this can be achieved by having Phase 2 lifetime less than PFS Interval
and Phase 1 lifetime equal to PFS interval. In this case, we do not need PFS
in IKEv2.

Option 2: When Phase 1 SA's SKEYID_d is compromised, this does not mean that
Phase 2 keys are compromised. If we want this, then PFS is required.


-Rajesh M






-----Original Message-----
From: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Andrew Krywaniuk
Sent: Friday, June 21, 2002 4:01 AM
To: 'IP Security List'
Subject: PFS + rekeying interconnection


> 1:00 - establish phase 1
> 1:01 - establish first phase 2
> 1:02 - establish second phase 2
> 1:03 - establish third phase 2
> 1:52 - rekey first phase 2
> 1:54 - rekey second phase 2
> 1:56 - rekey third phase 2
> 2:00 - delete DH exponent
> 2:46 - rekey first phase 2 w/ PFS folded back into phase 1
> [or just rekey
> phase 1]


I had a few requests to clarify some aspects of this timeline.

> 2:00 - delete DH exponent

It's not the DH exponent that matters here, it's SKEYID_d. You can delete
the DH exponent at 1:01 if you wish. Sorry about being unclear.


> 2) how long do you retain keys derived from the shared secret (one way
>     hash of the DH-generated secret).

For upto the PFS interval. The key here is to assume that the PRF is not
reversable.

> 1:00 - establish phase 1
> 1:52 - rekey first phase 2
> 2:00 - delete DH exponent

If someone breaks into your box at 1:59, they can get key1 and key2 and
SKEYID_d, but your PFS interval hasn't elapsed yet so only 1 hour's worth of
data is compromised.

If someone breaks into your box at 2:01, they can only get key2, which has
only been used for 9 minutes. You can continue to use key 2 up until 2:52
without violating your PFS interval.


> 3) how long after the declared expiration time do you keep the SA
>    alive to catch stragglers.

I assume that you delete the SA as soon as it expires. To avoid stragglers,
you rekey in advance.


> > 6 phase 2s for the price of one DH without sacrificing PFS.
>
> admittedly the long-term steady-state here will be more like 3 phase
> 2's per DH

It depends. If your jitter is completely random then the phase 2s will
eventually end up being distributed randomly through the timeline and you
will get 4 phase 2s per DH steady state.

If you tweak the jitter so the rekeys are distributed within a fixed window
then you can get 6 rekeys per DH steady state.


>     All the phase 2 sessions may not fall in the same
> intervel. In you example all the phase 2 connections
> are started  approximatetly at same time. In normal
> case the sessions are distributed evenly in the
> intervel. Let me know if I am missing anything ...

> 2:00 - delete DH exponent
> 2:46 - rekey first phase 2 w/ PFS folded back into phase 1

In the example above, the host had no SKEYID_d for 46 minutes. If you needed
to negotiate an SA earlier than that, you would negotiate a new key sometime
between 2:00 and 2:46. As I mentioned above, this might result in you
getting 4 SAs per DH rather than 6.

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.


***************************************************************************
This message is proprietary to Future Software Limited (FSL) 
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information 
and should not be circulated or used for any purpose other than for 
what it is intended. 

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. 
FSL accepts no responsibility for loss or damage arising from 
the use of the information transmitted by this email including
damage from virus.
***************************************************************************