Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

[Tero Kivinen <[e-mail]>]

Daniel Van Geest writes:
> 1) QS SA Negotiation
> 
> When negotiating a QS SA, it’s not enough to negotiate QS key
> agreement algorithm(s), one also has to ensure that the algorithms
> selected by the other transform types are also QS.

All of these kind of issues are really policy matters, thus outside
the PROTOCOL work. I.e., we can add security considerations section
text saying, that when using QS key agreement algorithm, other
algorithms needs to be considered too. I do not see any reason for
making any hard rules. 

> I don’t find the re-use of transform 4 in this proposal, and the implicit combination of QS +
> non-QS algorithms, to be the most elegant, though I can understand it in the context of not
> wanting to add a new transform type.

Adding new transform types is bit painfull, mostly because if you want
to allow old implementations to connect, you need to have two
proposals, one with new transform type and another without.

The responder MUST pick exactly one algorithm for each transform type
the initiator send, and if it does not understand transform type (thus
will not be able to pick any), it MUST ignore the specific proposal.
This means that for backwards compatibility there needs to be two
proposals, or 3/4 if AEAD algorithms are also needed. This will make
IKE_SA_INIT larger.

On the other hand this is ONLY needed if the initiator DOES NOT know
whether other end supports QS or not. Usually initiator can be
configured to assume either way, it is more important to configure the
responder so it will accept either QS or non-QS...

Anyways this is something we need to decided, and there are different
kind of tradeoffs with different proposals.

> The idea is to add the new transform type 6 (Q-S-Group) like CJ’s
> proposal, but don’t include it in the SA payload. Rather, introduce
> a new QS_SA payload which would be identical in structure to the SA
> payload except that it would also include the Q-S-Group transform
> type.

I think creating QS_SA is bad idea. First of all, I assume there are
implementations which will break when there is unknown payload
included in the exchange. Secondly this will require even more space
than adding 2nd proposal in the SA payload, thus adding new transform
type and two proposals is more efficient encoding. Thirdly there might
be policy mismatch issues, i.e., cases where the SA and QS_SA
algorithms do not match, and that might cause issues also.

And lastly this will break the base IKE_SA_INit exchange payload
listing, i.e., currently we assume that we send one SA payload and
receive one SA payload back. Implementations quite often do sanity
check very early in the processing to verify that all needed payloads
are included, and this will break it. 

> Also note that StrongSwan’s code assumes that IKE_AUTH will always
> have a message ID of 1, but this won’t hold if there are one or more
> PRE_AUTH exchanges.

That also does not hold for cases where EAP is used, where IKE_AUTH is
message IDs 1, 2, ...., n. The text in section 2.2 talking about the
message IDs in IKE_AUTH is descriptive, i.e., it describes normal
behavior, it is not normative, and if any implementation assumes
IKE_AUTH will have message ID 1, it is broken.

> Tero says:
> 
>     Note, that the PRE_AUTH happening between IKE_SA_INIT and IKE_AUTH
>     would be encrypted, and MACed, but it WILL NOT be authenticated, i.e.,
>     we have not yet authenticated the other peer, and we will not include
>     those octets to the AUTH payload calculations, so they will not be
>     authenticated in AUTH phase, like the IKE_SA_INIT contents will be
>     authenticated.
> 
> Couldn’t the IDi and IDr payloads in IKE_AUTH be modified to sign
> the PRE_AUTH message in addition to the IKE_SA_INIT message?

They could be, that that would again change the basic crypto
calculations done by the IKE library, and if we do not need to touch
it, it is better. I.e., if the result of the PRE_AUTH is authenticated
in some other ways (for example because the QS key exchange protocol
run there generates keys, which we use later), then we might not
need to add specific authentication step for them.

I was mostly just stating what the current text describes. I.e., the
RFC7296 text as written in section 2.15 will not authenticate those
messages unless we modify that. 
-- 
[e-mail]