RE: Suggestion for SOI wrt PFS

[andrew.krywaniuk@alcatel.com]

> I think that this (using phase 2 with D-H
> to generate a new SKEYSEED_d) works for PFS, but I am worried
> about the added
> complexity.  Adding a new type of phase 2 for calculating the
> SKEYSEED_d comes dangerously close to shoehorning in a
>  "phase 1 1/2", which we are trying to avoid.  Are the savings
> gained from avoiding a new Phase 1 exchange worth this added
> complexity?

I don't think this is what people are referring to when they talk about a
phase 1.5. Also I wasn't proposing a new type of phase 2 exchange.
Nevertheless, I have no objection to replacing PFS with more frequent phase
1 rekeying, except that this got shouted down as inefficient the last time I
proposed it. My new proposal attempts to be more efficient and also resolve
the PFS interop problem (so there is also a simplification benefit).

The problem I see is that PFS (as defined in IKE) is currently implemented
as a configuration parameter when it could be a runtime parameter. This
causes interop problems because PFS (and the DH group) can't be negotiated
in the same was as other parameters. I support Paul's idea for having a set
of named ciphersuites. I've been advocating this idea for years, but I
anticipated that PFS would be the main problem. If you use 3DES with SHA1,
that will work with most people's default configurations; therefore, the
ciphersuite will reflect what is already out there. But PFS will cause a
problem, because there is about a 50% chance that a given implementation
will have it on by default and a 50% chance that it will be off.

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.