Subject: Re: [IPsec] Alternative Approach for Postquantum Preshared Keys in IKEv2

From: Paul Wouters <[email-masked]>
Date: Tue, 3 Dec 2019 13:34:23 -0500 (EST)

On Thu, 28 Nov 2019, Valery Smyslov wrote:

> some time ago I've posted a new draft "An Alternative Approach for Postquantum Preshared Keys in IKEv2".

> AS you all know we have "Postquantum Preshared Keys for IKEv2" (draft-ietf-ipsecme-qr-ikev2) draft
> that is already in Publication Requested state. This draft defines a mechanism to achieve PQ security
> by means of additional Preshared Key (PPK) that is mixed up in IKE SA keys calculation.
> This approach is believed to be a temporary solution until new PK KE primitives are standardized.

Yes, PPK is for use with non-PQ algorithms as a stop-gap meassure until
we have PQ algorithms/exchanges. But that means ideally that if or when
IKE_INTERMEDIATE is used, we are using PQ-safe algorithms and PPK's are
not used anymore.  We might also end up with something PA-safe that does
not require IKE_INTERMEDIATE.

> The problem is that in the "Group Key Management using IKEv2" (draft-yeung-g-ikev2),
> that is just adopted as a WG document, the responder (Group Controller / Key Server)
> transfers session keys to the initiator (Group Member) immediately once IKE SA between
> them is created. Obviously, keys are sensitive information and they are not protected
> by PPK in this case. The workaround suggested in draft-yeung-g-ikev2-16 is to perform
> quite long series of exchanges (consuming more resources) to postpone session
> keys transfer until the initial SA is rekeyed.

Understood.

> The draft "An Alternative Approach for Postquantum Preshared Keys in IKEv2" proposes
> an alternative approach for using PPK by utilizing the IKE_INTERMEDIATE exchange,
> in which PPK IDs are exchanged. This allows an initial IKE SA to be secure
> against QC, that would substantially simplify G-IKEv2 implementation if PQ security
> using PPK is needed.

Wouldn't this introduce the same bad error handling in IKE_INTERMEDIATE
we had in IKEv1 of getting unreadable messages?

> This alternative approach can also be used in regular IKEv2. Compared
> with draft-ietf-ipsecme-qr-ikev2 it has few advantages and a single
> drawback - it requires an additional exchange for IKE SA to set up.

That is likely less problematic than the PPK management involved? And
presumable this goes away when we have PQ-safe algorithms, so it is only
a temporary extra round trip? (still hoping that the new PQ-safe stuff
does not require the IKE_INTERMEDIATE exchange :)

> However, if IKE_INTERMEDIATE is used for some other (not yet defined)
> purposes too, the PPK IDs can be piggybacked and thus having no such penalty
> as an extra exchange.

But ideally, neither PPK or IKE_INTERMEDIATE would be needed for PQ-safe exchanges :P

> Comments, reviews, opinions are very welcome.
> Is it worth to adopt this draft as a WG document?

There is also another solution to your original problem: require PQ-safe
algorithms for Group SA's that need to be PQ-safe and don't use PPKs
at all. Since PPK's are a "stop gap" method meant for existing things,
and group SA's are still being designed, developed and implemented,
by the time the group sa work is done, we might already have PQ-safe
exchanges so PPK is no longer needed.

I'd be tempted to wait a bit for now before we do too much work that
ends up not being needed. I suspect most implementors would wait as
well anyway.

specific comments on the draft:

I don't like returning AUTHENTICATION_FAILED outside of IKE_AUTH as
proposed in your document. Since the only thing that could possibly
cause that is PPK failure, you might as well return a new error
that clearly states that (eg the original IKEv2 assumption to hide
presenting too much info by returning AUTHENTICATION_FAILED in many
cases does not apply here)

    If using PPK is optional for the responder, then she returns the
    empty PPK_IDENTITY notification, thus informing the initiator that
    the IKE SA can be created only without using PPK.

This is a strange concept of "optional" :)

Another issue I see is with connection selection and PPK selection.
At the IKE_INTERMEDIATE exchange, we don't know yet which connection
this will map to, as we haven't seen the AUTH payload nor the IDr
payload. So I think you would at the minimum need to also send the
IDr payload if you are sending a PPK payload. Or you need to overload
or derive this information from the supplied PPK_ID. I feel this might
cause operational problems.

For computing the IKE SA keys, I would prefer to leave this method as
unchanged as possible. Adding PPK mixing into the prf+ differently
from the standard one will make the code more complex. Isn't it enough
to make the PPK part of SKEYSEED? Why do we need to use this from the
additional prf+ calls as well?

Paul
Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 4 Dec 2019 11:34:36 +0300

Hi Paul,

thank you for the thorough review.

> not require IKE_INTERMEDIATE.

The IKE_INTERMEDIATE was designed so that it is not tied to PQ document
and can be used for other purposes too. Here is the instance of such an application :-)

> we had in IKEv1 of getting unreadable messages?

The IKE_INTERMEDIATE messages are always encrypted with the keys
that don't depend on PPK, so the responder can always decrypt them.
The selected PPK is only used to derive the keys for the IKE_AUTH (and thus for IKE SA).
So, there is no problem with the IKE_INTERMEDIATE, but if
the selected PPK mismatches on the peers, the responder won't be able 
to decrypt the IKE_AUTH message. I think this issue can be addressed
if some notification is included in the responder's IKE_INTERMEDIATE message
along with the selected PPK_ID, containing the data that proves the responder 
knows the PPK it has selected. Something like:

prf(PPK,Ni | Nr | SPIi | SPIr)

This will allow the initiator to detect PPK mismatch before PPK is used
and cancel the exchange.

> does not require the IKE_INTERMEDIATE exchange :)

Yes, the PPK solution was intended to be a temporary one.
However, in Russia we have a saying: "there is no more permanent than temporary" :-)

> But ideally, neither PPK or IKE_INTERMEDIATE would be needed for PQ-safe exchanges :P

In an ideal world - yes. But we all have quite a lot of experience 
demonstrating us that the real world is far from ideal :-)

> exchanges so PPK is no longer needed.

My primary motivation was to allow G-IKEv2 to have the same
level of security as IKEv2 has. We don't know when PQ-safe primitives are approved 
(some NIST competitions lasted for years) and we don't yet know the properties 
of the approved PQ KE primitives. With QSKE draft we try to be prepared, but I really hate 
to think that the approved KE method will have 100+ Kb public key (like McEliece).
Yes, we can handle this case too, but the cost is high. In this 
circumstances having pretty simple and reliable solution with PPK
may still be attractive for some applications, even after 
PQ methods are approved.

> ends up not being needed. I suspect most implementors would wait as

I don't think the amount of work here is really high.
The draft reuses the IKE_INTERMEDIATE and the way the PPK is mixed 
into key derivation defined in draft-ietf-ipsecme-qr-ikev2.
There are not much new stuff.

> cases does not apply here)

I was thinking about this, and decided not to introduce new notifications.
Do you have any specific concerns about AUTHENTICATION_FAILED
outside IKE_AUTH? It looks like the natural choice here...
The other possibility is to reuse the AUTHORIZATION_FAILED
notification, that is in G-IKEv2, or to add a new one.

> This is a strange concept of "optional" :)

Well, the text is confusing, I agree. The context is that the responder
doesn't have any of PPKs suggested by the initiator, but 
using PPK is optional for the responder. that's why it informs
the initiator: "I don't have any of suggested PPK, but we may
continue without PPK, if you like". I'll add clarification to this
text.

> cause operational problems.

Well, I'm not sure this is a real issue. If PPKs are fixed, then I see no problem:
the responder just selects one of the proposed PPKs and during IKE_AUTH 
he verifies that the selected PPK is configured for the IDi. If the responder
selects a wrong PPK, then it means that there is a misconfiguration and
the connection won't be established anyway.

Of course, the initiator must only propose the PPK identities that are suitable
for the connection being created. Otherwise the following situation may happen.
Consider there are two group of users each configured with own PPK (group PPKs).
If initiator is a member of both groups and he doesn't know which 
group the responder belongs to, he may include two PPK identities for the responder
to select. If the responder is also a member of both groups, he will select
an arbitrary PPK (he owns both). But if due to misconfiguration (or some transient
changes in configuration) it happens, that the responder thinks the initiator
belongs only to one of this groups (this becomes clear in IKE_AUTH) and
he made a wrong guess, the SA won't be set up (but it couldn't be if the
responder knew the IDi of initiator when he was selecting PPK).
I think it's rather weird situation and is also the result of misconfiguration,
however I admit that including IDi would help in this case.

The problem may also arise when PPK identity is generated and depends on peer identity 
(e.g. some OTP cases when each new connection uses new PPK_ID generated 
using the initiator's identity). Currently these use cases are mostly
theoretical ones.

Can you come up with more use cases when it is needed?

> additional prf+ calls as well?

I just re-used the way PPK is stirred into the IKE SA keys from draft-ietf-ipsecme-qr-ikev2.
Sure, for this draft it's possible to redefine this way and to mix PPK into SKEYSEED,
but I'm not sure it's easier to implement (I suppose this draft will be implemented
by those vendors who have already implemented draft-ietf-ipsecme-qr-ikev2,
so the already implemented mixing functions will be just re-used for all SK_* keys).

Thanks,
Valery.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 6 Dec 2019 19:05:10 -0800

> thank you for the thorough review.

Seconded!

> using the initiator's identity). Currently these use cases are mostly

It seems likely that some formal analysis would help shed light on the
issues here, if we could find someone interested and able to do the work.
I'll see if I can ask around...

-Ben