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

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 1 Jan 2019 16:23:02 +0300

Hi Paul,

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

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

---

From: Paul Wouters <[email-masked]>
Date: Tue, 1 Jan 2019 21:38:05 -0500 (EST)

On Tue, 1 Jan 2019, Valery Smyslov wrote:

> first, I believe this discussion must be public, so I've added

Sure.

>>  information,

Sounds good to me.

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

Okay.

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

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 2 Jan 2019 10:26:17 +0300

> it is possible. It might not be worth the complication.

Well, _technically_ you can do it. But you can't do it if you follow IKEv2 rules.
Because in case of multiple authentications there is no multiple IKE_AUTH exchanges,
there is a single IKE_AUTH exchange with multiple rounds [1], and you suggest 
to insert a new exchange in the middle of the running IKE_AUTH exchange. 
It is not state machine issue, it would be violating of very basic IKEv2 rules: you cannot perform 
any actions on IKEv2 SA until the IKE_AUTH exchange completes successfully, you cannot
run multiple exchanges if your window size is 1, etc. 

Reductio ad absurdum: technically you can rekey right after IKE_SA_INIT completes,
no need to wait for IKE_AUTH :-)

[1] At least it is my reading of RFC4739. Actually, it is not very explicit about this,
but the phrase from it "The IKE_AUTH phase is considered successful only if all the individual 
authentication exchanges complete successfully." seems to imply that IKE_AUTH phase
cannot be interrupted with any other exchanges.

Regards,
Valery.