[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Definition of PFS...
That's what I thought. To me, it makes more sense to limit key exposure via.
phase 1 rekeying rather than by PFS. It's slightly slower (if your
CertSign/CertVerify operations are comparable in CPU time to your DH
calculation), but the security tradeoffs make more sense.
I suppose that QM PFS does have a value (as an optimization of phase 1
rekeying) solely for the purpose of combatting search warrants. Assuming
that:
1. key escrow is not required
2. law enforcement officers can bypass your box's tamper-proof mechanisms
3. but they are ethically prevented from cryptographically impersonating you
then you would indeed be able to limit your key exposure using PFS.
But for the purpose of preventing against active or passive attacks by
persons other than law enforcement, DH refresh without re-authentication
doesn't do that much for you.
What concerns me is that, as with many things in IKE, the intent of this
feature is not documented, particularly the security model in which DH
refresh without re-authentication is "warranted" :-)
Consequently, most implementers I have talked to don't understand what the
supposed purpose of PFS is (most of them will cite the log(n) added security
argument, which really isn't significant).
Andrew
--------------------------------------
Beauty with out truth is insubstantial.
Truth without beauty is unbearable.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Bill Sommerfeld
> Sent: Thursday, October 12, 2000 10:47 AM
> To: Michael Richardson
> Cc: 'IP Security List'
> Subject: Re: Definition of PFS...
>
>
> > It also defends against the situation where a third party
> compels one
> > party to provide some set of keys. PFS guarantees that a
> simple search warant
> > only catches traffic *currently* in transit, not all
> previous and future
> > traffic.
>
> Not quite that simple; it's a matter of what the lifetimes of the IKE
> and AH/ESP SA's really are..
>
> If your AH/ESP SA lifetimes are 12 hours, this gives someone 12 hours
> of traffic even if quick mode with PFS was used to create them.
>
> Similarly, if you don't use PFS in quick mode, but limit your IKE SA's
> (and the AH/ESP SA's derived from them via quick mode) to a lifetime
> of 1 hour, you get 1 hour of traffic.
>
> - Bill
>
References: