Hi Mirja,
> Hi Panos, hi Valery,
>
> Please see below.
>
> > On 8. Jan 2020, at 10:27, Valery Smyslov <s...@elvis.ru> wrote:
> >
> > Hi Panos, Mirja,
> >
> >> Hi Mirja,
> >>
> >> To try to answer your questions
> >>
> >> 1) You are right. This is mentioned in a paragraph below that reads
> >>
> >> [...] or continue without using the
> >> PPK (if the PPK was not configured as mandatory and the initiator
> >> included the NO_PPK_AUTH notification in the request).
> >>
> >> But for clarity we will slightly rephrase the sentence you pointed out to
> >>
> >> only if using PPKs for communication with this responder
> >> is optional for the initiator (based on the mandatory_or_not flag),
> >> then the initiator MAY include a notification NO_PPK_AUTH in the
> >> above message.
> >
> > After re-reading this para, I think that uppercase "MAY" is not needed
> here,
> > because if the initiator doesn't include NO_PPK_AUTH, then it leaves
> > no chances for the responder to complete IKE SA without using PPK,
> > so in this case using PPK becomes in fact mandatory. I think the proper
> text should be:
> >
> > 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 notification NO_PPK_AUTH in the
> > above message.
>
> I think what you propose is actually to replace the MAY by a MUST. In any
> case using normative language is helpful here because that is an action that
> needs to be implemented somehow, so the implementor would need to
> know what the protocol is supposed to do.
I have no problem with using normative MUST here, since it doesn't
change the meaning of the text. That said, I still prefer to avoid using
it here (by following section 6 of RFC2119), because in my
understanding it is just a description of protocol behaviour and not a special
requirement.
How about the following text?
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 indicates this optionality to the responder by including
a notification
NO_PPK_AUTH in the above message.
> >> 2) It is a little hard to include a time that would match all situations.
> >> It
> really
> >> depends on the server DoS protection policy and when it kicks on. The
> >> initiator cannot really know how fast is considered too fast for the
> >> responder so it has to make a conservative decision. Adding a " (e.g.,
> >> seconds) " would probably suffice here.
> >
> > Since this situation is most probably caused by misconfiguration (or some
> attack),
> > I think that the period of inactivity for the initiator should be longer, at
> least several minutes.
> > Anyway, I agree that it's hard to give universal advice here.
> > I'd leave the text as is, since the reference to "misconfiguration"
> > in this para gives in my opinion enough hint of how long to wait.
>
> Since you both disagree by an order of magnitude, it seems to me that
> some more advise would actually be helpful. It’s fully understood that there
> is no one value that fits all but providing further advise what this value
> depends on and what could be a good range in most cases could be helpful.
> I would actually think that given the misconfiguration is on the other end
> and the person implementing this value has no idea about what the
> misconfiguration would be, it’s anyway guessing, so why not guess now and
> give some advise.
How about:
In this situation, it is RECOMMENDED
that the initiator caches the negative result of the negotiation
and doesn't make attempts to create it again for some time.
This period of time may vary, but it is believed that waiting
for at least few minutes before next connection attempt will not cause
the responder to treat it as DoS attack. Note, that this situation
is most likely a result of misconfiguration and some re-
configuration of the peers would probably be needed.
> >> 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.
> >> 4) I am not sure adding one more notification for downgrade detection
> >> adds much here. Remember IKEv2 has subsequent messages to do
> >> IKE_AUTH etc and we wanted to not introduce more significant
> deviations
> >> on IKEv2.
> >>
> >> If the PPK is optional for both peers then downgrade is possible but it is
> the
> >> cost of being flexible to allow some peers to use PPK and some to not. If
> any
> >> of the peers has PPK as mandatory then downgrade will be caught and
> >> rejected as explained in the Sec Considerations section, so I think we are
> OK
> >> there.
> >
> > I agree with Panos: the downgrade is possible only if using PPK is optional
> > for both, in which case both parties agree that downgrade is OK.
>
> Having some downgrade detection would enable to log an attack if optional
> PPK was used.
The downgrade attack here is mostly a theoretical one. To successfully
mount it an attacker must be able to break digital signatures in real time
(i.e. within a minute). Given the figures Scott Fluhrer has posted to the
ipsecme list,
it is unlikely to be achievable even when full scale quantum computers
are build. Besides, prerequisites for this attack are that an attacker
be able to modify IKE messages (i.e. be on the path) and peers use signatures
for authentication.
> This could give further insights for the network admin or
> provide some motivation to move quickly to mandatory PPK. Alternative
> you could of course even have another config option where PPK is optional
> but you still close the connection with an error if downgrade is detected
> later on. Was just an idea…
Note, that a requirement to log the situation when both peers have PPK and the
SA is created
without using it is already in the draft (as SHOULD).
And any failed connection attempt is usually an auditable event.
Regards,
Valery.
> Mirja
>
>
>
> >
> > Regards,
> > Valery.
> >
> >> Rgs,
> >> Panos
> >>
> >> -----Original Message-----
> >> From: IPsec <ipsec-boun...@ietf.org> On Behalf Of Mirja Kühlewind via
> >> Datatracker
> >> Sent: Tuesday, January 07, 2020 8:41 AM
> >> To: The IESG <i...@ietf.org>
> >> Cc: ipsec@ietf.org; ipsecme-cha...@ietf.org; david.walterm...@nist.gov;
> >> draft-ietf-ipsecme-qr-ik...@ietf.org
> >> 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
> >> IPsec@ietf.org
> >> https://www.ietf.org/mailman/listinfo/ipsec
> >
> >
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
