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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
