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

["Valery Smyslov" <[e-mail]>]

Hi Paul,

first, I believe this discussion must be public, so I've added [e-mail].

>>>    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