Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)

[Valery Smyslov <[e-mail]>]

Hi Mirja,

[...]

> > It is definitely better, thank you!
> >
> >    For this purpose, if using PPKs for communication with this responder
> >    is optional for the initiator (based on the mandatory_or_not flag),
> >    then the initiator includes a NO_PPK_AUTH notification in the above
> message
> >    to indicate this optionality to the responder.
> >
> > Is it OK now?
> 
> 
> I still think use of normative language would be appropriate here.

OK.

    For this purpose, if using PPKs for communication with this responder
    is optional for the initiator (based on the mandatory_or_not flag),
    then the initiator MUST include a NO_PPK_AUTH notification in the above
   message  to indicate this optionality to the responder.

> > [...]
> >
> >>>>>> 3) Waiting for one or two RTTs is probably a good rule. The side-
> effect
> >>>> could
> >>>>>> be that the initiator stays waiting for responses for too long which
> >> delays
> >>>>>> the handshake. I am not sure we can mandate in absolute time
> >> because
> >>>> it
> >>>>>> depends on the relative distance between client and server. We can
> >>>>>> probably include " (e.g., one round-trip) " in the text.
> >>>>>
> >>>>> I think one or two RTT is too short, moreover since it's an initial
> request,
> >>>>> no RTT is yet measured (IKEv2 uses UDP as primary transport).
> >>>>> We try here to be in line with core IKEv2 spec, which deliberately
> >>>>> doesn't give any concrete figures of how long to wait for an response
> >>>>> (section 2.4 of RFC7296). So, I'd leave the text as is.
> >>>>
> >>>> Kind of same here. Given you two disagree here already, I think it
> would
> >> be
> >>>> good to give further advise.
> >>>
> >>> I'm reluctant to provide concrete figures, because RFC7296 deliberately
> >>> doesn't do it and this is just an extension to the IKEv2. I'd rather
> reference
> >>> the core spec here. How about the following text:
> >>>
> >>> To thwart
> >>>  this kind of attack it is RECOMMENDED, that if using PPKs is
> >>>  mandatory for the initiator and the received response doesn't contain
> >>>  the USE_PPK notification, then the initiator doesn't abort the
> >>>  exchange immediately, but instead waits for more responses
> >>>  retransmitting the request until either the received message
> >>>  contains the USE_PPK or connection times out (see section 2.4 of
> >> [RFC7296]
> >>>  for more details). If all the received responses contain no USE_PPK,
> then
> >> the exchange is aborted.
> >>
> >> I looked at section 2.4 of RFC7296 and the situation is actually different
> >> there because the initiator will accept/open multiple connections and
> then
> >> close them again if detected to not be proper.
> >
> > I meant another part of 2.4:
> >
> >   The number of retries and length of timeouts are not covered in this
> >   specification because they do not affect interoperability.
> >
> >> So there is state anyway. Here you don’t have an open connection and
> therefore you need an
> >> timeout.
> >
> > Sure we need a timeout. But this is exactly the same timeout which
> > IKEv2 initiator uses when trying to establish initial connection with the
> peer.
> >
> >> I would recommend to at least say something like:
> >> "Ideally the timeout would be in the order of the RTT plus additional
> >> processing delays at the responder. As these times are not known the
> >> timeout should be choosen sufficiently larger, however, state may be
> >> removed anytime when needed (e.g. in an attack situation).”
> >>
> >> (Please use your own wording…)
> >
> > The whole idea of thwarting this attack is not to trust
> > the responses not containing USE_PPK notification (suspecting that they
> may be forged).
> > So the initiator continues to retransmit and wait for other responses.
> > For how long? For the same period of time that it would retransmit and
> wait for any response
> > as if no responses were received at all. So, we introduce no new timeouts
> here
> > comparing with the core spec.
> 
> Okay. I wasn’t aware that these are existing time-outs. I think the document
> could be more clear about this then.

Is this better?

To thwart
this kind of attack it is RECOMMENDED, that if using PPKs is
mandatory for the initiator and the received response doesn't contain
the USE_PPK notification, then the initiator doesn't abort the
exchange immediately, but instead waits for more response mesages
retransmitting the request as if no responses were received at all,
until either the received message contains the USE_PPK or exchange times out 
(see section 2.4 of [RFC7296] for more details on retransmission timers in IKEv2). 
If all the received responses contain no USE_PPK, then the exchange is aborted.

Regards,
Valery.

> Mirja
> 
> 
> 
> >
> > Regards,
> > Valery.
> >
> > [...]
> >
> >> Mirja
> >>
> >>
> >>>
> >>> Regards,
> >>> Valery.
> >>>
> >>>> Mirja
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>> Regards,
> >>>>> Valery.
> >>>>>
> >>>>>> Rgs,
> >>>>>> Panos
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: IPsec <[e-mail]> On Behalf Of Mirja
> Kühlewind
> >> via
> >>>>>> Datatracker
> >>>>>> Sent: Tuesday, January 07, 2020 8:41 AM
> >>>>>> To: The IESG <[e-mail]>
> >>>>>> Cc: [e-mail]; [e-mail];
> >> [e-mail];
> >>>>>> [e-mail]
> >>>>>> Subject: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-
> ipsecme-
> >> qr-
> >>>>>> ikev2-10: (with COMMENT)
> >>>>>>
> >>>>>> Mirja Kühlewind has entered the following ballot position for
> >>>>>> draft-ietf-ipsecme-qr-ikev2-10: No Objection
> >>>>>>
> >>>>>> When responding, please keep the subject line intact and reply to all
> >>>> email
> >>>>>> addresses included in the To and CC lines. (Feel free to cut this
> >>>> introductory
> >>>>>> paragraph, however.)
> >>>>>>
> >>>>>>
> >>>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-
> >> criteria.html
> >>>>>> for more information about IESG DISCUSS and COMMENT positions.
> >>>>>>
> >>>>>>
> >>>>>> The document, along with other ballot positions, can be found here:
> >>>>>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ----------------------------------------------------------------------
> >>>>>> COMMENT:
> >>>>>> ----------------------------------------------------------------------
> >>>>>>
> >>>>>> 1) One small question on section 3:
> >>>>>> "if using PPKs for communication with this responder
> >>>>>> is optional for the initiator, then the initiator MAY include a
> >>>>>> notification NO_PPK_AUTH in the above message."
> >>>>>> This does mean that NO_PPK_AUTH notification should not be sent
> >> when
> >>>>>> the mandatory_or_not flag indicates that PPK is mandatory, right?
> Or
> >> is
> >>>> that
> >>>>>> a separate configuration? Would be good to clarify in the doc!
> >>>>>>
> >>>>>> 2) Section 6 says:
> >>>>>> "In this situation, it is RECOMMENDED
> >>>>>> that the initiator caches the negative result of the negotiation for
> >>>>>> some time and doesn't make attempts to create it again for some
> >> time,"
> >>>>>> Would it be possible to give any hints about what "some time"
> means
> >> or
> >>>> at
> >>>>>> least the order of magnitude? Maybe it could be recommended to
> >> wait a
> >>>>>> couple of seconds? Or how long is it usually expected to take until
> the
> >>>> half-
> >>>>>> open connection will be expired?
> >>>>>>
> >>>>>> 3) Also here:
> >>>>>> "then the initiator doesn't abort the
> >>>>>> exchange immediately, but instead waits some time for more
> >> responses
> >>>>>> (possibly retransmitting the request)."
> >>>>>> How long should one wait? Probably 1-2 RTTs if the RTT is known or
> >>>> maybe
> >>>>>> there is some good max value like 500ms or 1s or more...?  Is there
> >> any
> >>>> risk
> >>>>>> in waiting too long?
> >>>>>>
> >>>>>> 3) And one high-level comment (without knowing to much details
> >> about
> >>>>>> IKEv2):
> >>>>>> Would it be possible do a downgrade detection, meaning when
> non-
> >> PKK
> >>>>>> encryption is established the initiator would tell the responser again
> >> that
> >>>> it
> >>>>>> was initially requesting PKK, just to double-check...?
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> IPsec mailing list
> >>>>>> [e-mail]
> >>>>>> https://www.ietf.org/mailman/listinfo/ipsec
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >
> >