Re: [IPsec] Paul Wouters' Discuss on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with DISCUSS and COMMENT)

[Paul Wouters <[e-mail]>]

Ok, all good with me. Thanks Valery!

Sent using a virtual keyboard on a phone

> On Nov 30, 2022, at 12:03, Valery Smyslov <[e-mail]> wrote:
> 
> We are converging :-)
> 
>>> I'm a bit reluctant to add all this information to the abstract. It is already a bit too long
>>> (since Éric and Warren suggested to augment it with the explanation text of how
>>> this design helps in situation when PQ algorithms are less trusted). So currently
>>> the abstract is:
>>> 
>>>       This document describes how to extend the Internet Key Exchange Protocol
>>>       Version 2 (IKEv2) to allow multiple key exchanges to take place
>>>       while computing a shared secret during a Security Association (SA) setup.
>>> 
>>>       The primary application of this feature in IKEv2 is the ability to perform one or more
>>>       post-quantum key exchanges in conjunction with the classical (Elliptic Curve) Diffie-Hellman (EC)DH
>> key exchange,
>>>       so that the resulting shared key is resistant against quantum computer attacks.
>>>       Since there is currently no post-quantum key exchange that is trusted at
>>>       the level that (EC)DH is trusted for against conventional (non-quantum)
>>>       adversaries, performing multiple key exchanges with different post-quantum algorithms along
>>>       with the well-established classical key exchange algorithms addresses this concern, since the
>>>       overall security is at least as strong as each individual primitive.
>>> 
>>>       Another possible application for this extension is the ability to combine several key exchanges
>>>       in situations when no single key exchange algorithm is trusted by both initiator and responder.
>>> 
>>>      This document updates RFC7296 by renaming a transform type 4 from "Diffie-Hellman Group (D-H)"
>>>       to "Key Exchange Method (KE)" and renaming a field in the Key Exchange Payload from "Diffie-
>> Hellman Group Num"
>>>       to "Key Exchange Method". It also renames an IANA registry for this transform type
>>>       from "Transform Type 4 - Diffie-Hellman Group Transform IDs" to
>>>       "Transform Type 4 - Key Exchange Method Transform IDs". These changes generalize
>>>       key exchange algorithms that can be used in IKEv2.
>>> 
>>> Do you *really* want to make it longer? I'm not sure that if we just mention
>>> the names of the added exchange and notifies, that will help readers of the abstract
>>> to understand what this document is about...
>> 
>> This document updates RFC7296. It introduces the IKE_FOLLOWUP_KE Exchange. It renames [...]
>> 
>>> [update]
>>> 
>>> I've just noticed your message sent in response to Warren. So, since you insist :-),
>>> I suggest adding the following text before "This document updates...":
>>> 
>>>   This document utilizes the IKE_INTERMEDIATE exchange to perform multiple key exchanges when
>>>   an IKE SA is being established and introduces a new IKEv2 exchange IKE_FOLLOWUP_KE to perform
>>>   them when IKE SA is up (during rekeys or creating additional Child SAs).
>>> 
>>> is it now OK?
>> 
>> Also fine :)
> 
> Great!
> 
>>>> I don't think it would hurt pointing to Section 2.4 of RFC 7296. I see
>>>> this as a likely possible implemention mistake.
>>> 
>>> My problem with your proposal here is that this situation is not
>>> specific to this document. In other words, whether the initiator
>>> proposes any additional key exchanges or not, if an attacker
>>> manages to send a response before the genuine responder
>>> and the initiator continues establishing IKE SA using this response,
>>> then it will fail. There is nothing specific to the multiple key exchanges.
>>> And we implicitly assume that implementations follow RFC 7296.
>> 
>> I want to prevent code like:
>> 
>>    if (AKE-required && !AKE-received)
>>        return STF_FATAL    // kills state
>> 
>> I know it is a "reminder", but I think an important one.
> 
> RFC 7296 states that the proposed defense against this attack is a MAY
> (due to relatively high cost of the defense). So, I've added the following text at the end
> of 3.2.1:
> 
>    It is possible that an attacker manages to send a response to the initiator's IKE_SA_INIT request 
>    before the genuine responder. If the initiator continues creating IKE SA using this response, the attempt will fail.
>    Implementers may wish to consider a possible defense technique described in Section 2.4 of [RFC7296].
> 
> We really cannot advise something marked as MAY, we can only remind that this technique exists.
> 
>>>> Just give it some thought, but if we leave it as is that is fine too.
>>> 
>>> As I'm lazy, I prefer to do nothing here (unless you or my co-authors strongly disagree :-))
>> 
>> Fine with me. Can't get worse than CREATE_CHILD_SA I guess :P
> 
> CREATE_CHILD_SA_FOLLOWUP_KEY_EXCHANGE? :-)
> Oh, sorry, you seemed to propose something similar :-)
> 
>>>> I also think that is only a reason to ignore the CREATE_CHILD_SA, and
>>>> not a reason to destroy the existing IKE SA (and thus any existing Child
>>>> SA)
>>> 
>>> Well, generally invalid response means that there is something wrong
>>> with the peer thus we cannot be sure that it follows spec.
>> 
>> Yeah but stabbing them in the heart in case they might be dying is a bit
>> drastic :P
>> 
>> Put it in another way, I would violate the RFC on this point and keep
>> the existing IKE SA until its lifetime has been reached.
>> 
>>>>> I think that the text may be clarified a bit. How about?
>>>> 
>>>> I guess first we need to agree on what to do.....
>>> 
>>> OK, let me clarify our point.
>>> 
>>> First, there is nothing specific to the multiple key exchanges here. The situation is that
>>> the responder sends a message that is inappropriate from the protocol point of view.
>>> There may be many reasons to consider it inappropriate - missing mandatory
>>> payload, incorrect choice of algorithms etc., this specification just adds one
>>> more reason - duplicated algorithms.
>>> 
>>> What should the initiator do in this situation? It generally cannot send INVALID_SYNTAX,
>>> since RFC 7296 discourages doing so (section 2.21.3):
>>> 
>>>  Because sending such
>>>  error messages as an INFORMATIONAL exchange might lead to further
>>>  errors that could cause loops, such errors SHOULD NOT be sent.
>>> 
>>> The initiator generally cannot continue using this SA, because of possible
>>> the states on the peers are now out of sync (the responder thinks the exchange completed
>> successfully).
>>> So the safe way is to delete the problem SA. If it is not yet created, then just stop creating it,
>>> otherwise send a Delete payload.
>>> 
>>> Note, that the text you proposed
>>> 
>>>   the initiator should log the error and MUST abort the exchange with a permanent error
>>> 
>>> actually has the same consequence. Since the responder sent a response with no error notify,
>>> it thinks that the exchange is completed successfully. On the other hand, your text suggests
>>> that the initiator treat this exchange as failed. So, the states on the initiator and the responder
>>> are now out of sync. RFC 7296 states (2.21.3):
>>> 
>>>  If errors are seen that indicate that the peers do not have the same
>>>  state, it might be good to delete the IKE SA to clean up state and
>>>  start over.
>> 
>> "might" :-)
> 
> Yes, RFC 7296 is not very clear here, using RFC 2119 language would be more appropriate :-)
> 
>> Again, I agree on killing the newly failed SA. But let's say you have an
>> IKE SA up and a Child SA up (might even be a child using classic algo
>> only), I don't see why adding a new Child SA that fails should kill the
>> existing functional Child SA and IKE SA.
>> 
>> Sure there should be a loop detection and exponential back-off on
>> failures to prevent a DoS of trying to get this post-quantum Child SA
>> up. But tearing down the existing Child SA and IKE SA will presumbly
>> just cause a more complicated loop anyway. These working SA's will come
>> back up again and then get torn down again when the post-quantum Child
>> SA fails. So I don't think your suggestion is better.
> 
> Well, to get to some compromise we can state in the draft that in this situation
> the initiator MAY send a Delete payload to delete the IKE SA itself
> and MUST NOT initiate any IKE_FOLLOWUP_KE exchanges.
> 
>    If the responder's message contains one or more duplicated choices, the initiator
>    should log the error and MUST treat the exchange as failed.
>    The initiator MUST NOT initiate any IKE_INTERMEDIATE (or IKE_FOLLOWUP_KE) exchanges, so that no new SA is created.
>    If this happens in the CREATE_CHILD_SA exchange, then the initiator MAY delete the IKE SA,  
>    over which the invalid message was received, by sending a Delete payload.
> 
> Is it OK now?
> 
>>>>>> ### Section 3.2.2
>>>>>> ```
>>>>>>   The other keying materials SK_d, SK_ai, SK_ar, SK_ei,
>>>>>>   SK_er, SK_pi, SK_pr are updated as:
>>>>>> 
>>>>>>   [...]
>>>>>> ```
>>>>>> Why not say: The other keying materials SK_d, SK_ai, SK_ar, SK_ei, SK_er,
>>>>>> SK_pi, SK_pr are generated from the SKEYSEED(n) as per RFC 7296.
>>>>> 
>>>>> No objection.
>>>> 
>>>> Just to clarify, where I wrote [...] I meant to cover the illustration
>>>> under the text as well. The point of this change was to not repeat a
>>>> stock 7296 exchange (which might confuse implementers in believeing this
>>>> is different from stock 7296)
>>> 
>>> I'd rather to keep the illustration. There is a subtle difference from RFC 7296 -
>>> while keys have "generation", the SPIs and nonces are used from the IKE_SA_INIT.
>>> The illustration makes this difference more clear, in my opinion.
>> 
>> If you want to keep the illustration, then just ignore this entire
>> change I proposed or it becomes duplicative.
> 
> OK.
> 
> The updated PR is available at:
> https://github.com/post-quantum/ietf-pq-ikev2/pull/22
> 
>> If you get a new draft before tomorrow 10am EST, I can update my DISCUSS
>> to a YES ballot :)
> 
> We'll do our best :-)
> 
> Thank you,
> Valery.
> 
>> Paul
> 
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec