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

[Valery Smyslov <[e-mail]>]

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