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

[Paul Wouters <[e-mail]>]

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