[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Definition of PFS...
Actually, phase 2 rekeying without PFS already fully protects against
attacks based on encrypted data (unless you think you can break an HMAC more
easily than a DH).
If PFS is being used as an optimization to phase 1 rekeying (skipping the
authentication phase), then I was going to suggest what Dave said (replacing
SKEYID_D from the phase 1 with the new DH value and doing PFS only
occasionally).
But even so, I still can't think of any threat models (except for the
ethical law-enforcement one) that would be mitigated by using PFS as an
optimization.
Andrew
--------------------------------------
Beauty with out truth is insubstantial.
Truth without beauty is unbearable.
> -----Original Message-----
> From: Rajesh Mohan [mailto:RMohan@vpnet.com]
> Sent: Friday, October 13, 2000 5:47 PM
> To: sommerfeld@East.Sun.COM; 'Michael Richardson'; 'Andrew Krywaniuk'
> Cc: 'IP Security List'
> Subject: RE: Definition of PFS...
>
>
> The amount of data encrypted using a key is limited by doing phase 2
> rekeying with PFS. This prevents attack based on encrypted
> data. So, DH
> refresh without re-authentication prevents ciphertext only attack.
>
> Ofcourse, doing phase 1 rekeying with every phase 2 rekeying,
> is more safe
> but does have a overhead.
>
> Rajesh M
>
> ----------
> From: Andrew Krywaniuk [SMTP:andrew.krywaniuk@alcatel.com]
> Sent: Friday, October 13, 2000 11:51 AM
> To: sommerfeld@East.Sun.COM; 'Michael Richardson'
> Cc: 'IP Security List'
> Subject: 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: