Hi Paul,
first, I believe this discussion must be public, so I've added ipsec@ietf.org.
If there is IKE traffic other
than the identities that need to be protected against such an
adversary, implementations MAY rekey the initial IKE SA immediately
after negotiating it to generate a new SKEYSEED from the postquantum
SK_d. This would reduce the amount of data available to an attacker
with a Quantum Computer.
How does an immediate rekey of the IKE SA help hide some of the information,
like TS? I think we need to be more clear. So how about:
An attacker with a Quantum Computer that can read the decrypted
IKE SA from the initial exchanges has access to all the
configuration parameters exchanged via the IKE SA including
all negotiated IPsec SAs information with the exception of the
cryptographics keys used by those IPsec SAs which are protected
by the PPK. IKE SA information available to such an attacker
includes the traffic selectors that can expose the network
architecture and IP address ranges that are in use. Deployments
that are concerned with this MUST initiate a childless IKE SA
[RFC6023] using PPKs and immediately rekey the IKE SA so it gains
PPK protection before sending any other IKE messages such as
CREATE_CHILD_SA or Informational exchange. If other sensitive
information such as third party cryptographic keys for other
protocols are transmited via IKE, implementations MUST rekey
the IKE SA before sending those payloads over IKE to ensure this
information is protected by the PPK.
I think that the text is OK, however I'd replace "third party cryptographic
keys"
with just "cryptographic keys". In G-IKEv2 the keys transferred are not "thirs
party".
But I'd rather hear more from my co-authors and the WG.
It replaces the two old paragraphs? On the other hand, perhaps instead
of this being hidden in the Security Considerations section, it deserves
its own regular section?
Not sure. It was a WG's decision that the information exchanged over IKE SA is less important,
so we can live with the ability for an attacker to recover it.
That's why the text is in the Security Considerations.
What is not obvious from this text, is that it exposes information of
the first IPsec SA as well, such as traffic selectors used.
And actually not just the first IPsec SA, but all of them. And PFS would
not help here.
PFS is irrelevant here.
I wonder if we need to talk about RFC 4739 here? like:
If multiple authentication exchanges [RFC 4739] are required
for the IKE SA, the IKE SA MUST rekey before sending the second
IKE_AUTH exchange in response to the initial IKE_AUTH's ANOTHER_AUTH_FOLLOWS
payload to avoid exposing the second authentication form to a quantum
capable attacker.
But this would really complicate the state machine?
You can't do it. There is a single IKE_AUTH exchange with multiple messages
(like in EAP case). You can't do any rekeys until the IKE_AUTH exchange
(which in case of RFC4739 includes multiple authentications) completes.
Regards,
Valery.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
