[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Definition of PFS...

My point was that a DH exchange in phase 2 contributes more random bits to
the IPSec key. Hence analysis of encrypted data using the previous key does
not help in analyzing the current encrypted data. 

I realize that NONCE provides random bits to the IPSec key during rekey but
DH does provide random bits that does not go over the wire. I do not know
much about cryptanalysis but if I have option of exchanging shared secret
over encrypted tunnel or DH exchange over encrypted tunnel, I will choose DH
exchange. Usually, phase 1 key is not used to encrypt much data but it can
be made to by making it sent, say, INVALID SPI. I do not know the
advancements in cryptanalysis. So I would prefer adding few safe random bits
to IPSec key during phase 2 rekey.

Thanks,
- Rajesh M
	----------
	From:  Andrew Krywaniuk [SMTP:andrew.krywaniuk@alcatel.com]
	Sent:  Friday, October 13, 2000 3:54 PM
	Cc:  'IP Security List'
	Subject:  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
	> 	>
	>