[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Simplifying IKE
> > This is why I have never liked the PFS option. One of the
> main purposes of
> > quick mode is to thwart traffic analysis on ESP data
> without greatly slowing
> > down the protocol. That's why it's called "quick".
> No, the main purpose of quick mode was to be able to amortize the
> cost of authentication over many SAs. Different SAs can be established
> to protect different flows as specified by different selectors without
> having to reauthenticate every time. And SAs for a particular flow can
> expire and be reestablished, again, without having to reauthenticate.
And what is the purpose of having different SAs to protect different flows?
(besides thwarting traffic analysis)
"Quick" mode is hardly quick if you have to repeat the Diffie-Hellman
exchange each time. Why can't quick mode be used to amortize the cost of
authentication *AND* forward secrecy over many SAs?
> You may not like PFS but it has been a continued requirement in this
> working group. That is why the SKIP folks had to come up an optional
> PFS extention.
Firstly, the problem with SKIP was that it didn't provide any kind of PFS at
all. If you cracked the RSA private key you could get all session keys
negotiated with that private key. I wasn't following this group that closely
back when SKIP was being proposed, but that's my understanding of the
problem. Am I wrong?
PFS is not optional in IKE because the DH group is not optional in phase 1.
All that is optional is whether you do a single level of PFS or two levels
of PFS. In fact, if you wanted to be ultra-paranoid we could add a 3rd level
of PFS where you refresh the keying material on every packet. How 'bout
that?
Designing the protocol so that cracking (or, more likely, stealing) a
long-term RSA key doesn't compromise all past traffic is a worthwhile
feature. Designing the protocol so that cracking a short-lived IKE phase 1
key doesn't reveal the (even more short-lived) phase 2 keys is a less useful
and more esoteric feature.
It is a shame that this bastard form of forward secrecy came to be known as
*the* PFS mode of IKE because it gives people the mistaken impression that
IKE w/o QM PFS doesn't have any PFS at all.
I suggest that you take some time (as I have done) to consider for each case
of {no PFS, PFS in phase 1, PFS in both phase 1 and phase 2} what is the
work factor for {the hosts to rekey phase 1, the hosts to rekey phase 2, the
attacker to brute force a key} and how much damage is done if {an RSA
private key, phase 1 DH key, phase 2 DH key, etc.} is cracked.
I have come to the conclusion, as have several others, that QM PFS is not
useful in the vast majority of situations as it doesn't make good use of the
engineering tradeoffs. When it is "required", the same threats can be
addressed by other means such as more frequent phase 1 rekeying or by
establishing the phase 1 with a bigger DH modulus.
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
Follow-Ups:
References: