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

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

Hi Paul,

thank you for the thorough review.

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

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

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.

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

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" :-)

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

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

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

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.

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

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.

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

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.

>     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" :)

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.

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

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?

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

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.

> Paul