On Tue, 1 Jan 2019, Valery Smyslov wrote:
first, I believe this discussion must be public, so I've added
Sure.
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.
Sounds good to me.
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.
Okay.
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.
We can't, you prefer not to?
You _can_ protect the identities of the second authentication if you
would first rekey. I agree it is tricky in a state machine because right
now it is easy to state an unauthenticated IKE SA can never rekey. But
it is possible. It might not be worth the complication.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
