RE: [Ipsec] doubts about IKEv2 implementation
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Ipsec] doubts about IKEv2 implementation
Hilarie Orman pointed out to me that part of my posting was
tantalizingly glib (my characterization, not hers).
What I said was:
> Perfect forward secrecy comes from forgetting the DH private key (and
> SK_d) no later
> than when the child SA is closed. To get PFS for the initial pair of
> child SAs, it is necessary to first rekey the IKE SA, forget the
keying
> material associated with it, and then rekey the child SA. By design,
> PFS does not require an additional DH exchange, though it is allowed
> because some crypto people don't believe it.
What I meant was that there is disagreement over the exact definition of
perfect forward secrecy. IKEv2 key rollover meets some definitions even
without additional D-H exchanges, but some people don't believe those
definitions are sufficiently constraining.
I define PFS as the property that once a session has ended neither
endpoint holds any information that would be helpful in decrypting a
recorded conversation.
The process of rekeying an IKE SA generates new keying material by
taking what is effectively a one way hash of the previous keying
material (and the previous keying material cannot be derived from any
long lived state), so by my definition that exchange provides PFS even
without an additional D-H exchange.
A tighter definition of PFS is that no information stored on either
endpoint before a conversation begins is useful in decrypting a
subsequent conversation except by means of a man-in-the-middle attack.
The process of rekeying an IKE SA without D-H does not meet that bar. I
claim that tighter constraint provides no practical additional security,
but this would be a philosophical debate rather than a technical one.
--Charlie
_______________________________________________
Ipsec mailing list
Ipsec at ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.