Re: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-05.txt

[Paul Wouters <[e-mail]>]

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