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

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Tue, 07 Jan 2020 05:41:13 -0800

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...?

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 8 Jan 2020 04:55:02 +0000

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.

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. 

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. 

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. 

Rgs,
Panos

-----Original Message-----
From: IPsec <[email-masked]> On Behalf Of Mirja Kühlewind via Datatracker
Sent: Tuesday, January 07, 2020 8:41 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)

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.)

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
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Valery Smyslov <[email-masked]>
Date: Wed, 8 Jan 2020 12:27:04 +0300

Hi Panos, Mirja,

>    then the initiator MAY include a notification NO_PPK_AUTH in the

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.

> 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.

> 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.

> 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.

Regards,
Valery.

> 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.)
> 
> 
> 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:
> 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:
> 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?
> 
> 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...?
> 
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 8 Jan 2020 10:41:45 +0100

Hi Panos, hi Valery,

Please see below.

> On 8. Jan 2020, at 10:27, Valery Smyslov <[email-masked]> wrote:
> 
> Hi Panos, Mirja,
> 
>> Hi Mirja,
>> 

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.

> 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.

> (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.

> 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. 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…

Mirja

---

From: Valery Smyslov <[email-masked]>
Date: Wed, 8 Jan 2020 14:55:26 +0300

Hi Mirja,

> 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.

> 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.
 
> 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.

> 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.

> email

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 8 Jan 2020 13:10:26 +0100

Hi Valery,

Please see inline.

> On 8. Jan 2020, at 12:55, Valery Smyslov <[email-masked]> wrote:
> 
> Hi Mirja,
> 
>> Hi Panos, hi Valery,
>> 
>> Please see below.
>> 

This depends: if you look at this from the receiver side, it a description of the protocol behaviour. But for the sender it’s an action that must be specified. I think the below text is mention to describe the requirement on the sender, so normative language is appropriate. Maybe the wording “the initiation indicates” is confusing here and it should actually say “the initiator includes a NO_PPK_AUTH notification to indicate this optionality to the responder“…?

>   configuration of the peers would probably be needed.

Sounds good to me. Thanks!

>   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. So there is state anyway. Here you don’t have an open connection and therefore you need an timeout. 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…)

> And any failed connection attempt is usually an auditable event.

Okay!

Mirja

---

From: Valery Smyslov <[email-masked]>
Date: Wed, 8 Jan 2020 16:27:49 +0300

Hi Mirja,

> This depends: if you look at this from the receiver side, it a description of
> the protocol behaviour. But for the sender it’s an action that must be
> specified. I think the below text is mention to describe the requirement on
> the sender, so normative language is appropriate. Maybe the wording “the
> initiation indicates” is confusing here and it should actually say “the initiator
> includes a NO_PPK_AUTH notification to indicate this optionality to the
> responder“…?

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?

[...]

> >>>> the handshake. I am not sure we can mandate in absolute time
> because
> >> it
> >> Kind of same here. Given you two disagree here already, I think it would
> be
> >> good to give further advise.
> >
> 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).”
> 

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.

Regards,
Valery.

[...]

> >>>> From: IPsec <[email-masked]> On Behalf Of Mirja Kühlewind
> via
> >>>> Datatracker
> >>>> Cc: [email-masked]; [email-masked];
> [email-masked];
> >>>> [email-masked]
> >>>> Subject: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-
> qr-
> >>>> ikev2-10: (with COMMENT)
> >>>>
> >>>> the mandatory_or_not flag indicates that PPK is mandatory, right? Or
> is
> >> that
> >>>> Would it be possible to give any hints about what "some time" means
> or
> >> at
> >>>> 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):
> >>>> encryption is established the initiator would tell the responser again
> that
> >> it

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 8 Jan 2020 14:31:20 +0100

Hi Valery,

Inline again.

> On 8. Jan 2020, at 14:27, Valery Smyslov <[email-masked]> wrote:
> 
> Hi Mirja,
> 
>> Hi Valery,
>> 
>> Please see inline.
>> 

I still think use of normative language would be appropriate 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.

Mirja

---

From: Valery Smyslov <[email-masked]>
Date: Wed, 8 Jan 2020 17:04:17 +0300

Hi Mirja,

[...]

> 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
> >>>  for more details). If all the received responses contain no USE_PPK,
> then
> >> the exchange is aborted.
> >>

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.

> >>>>>> couple of seconds? Or how long is it usually expected to take until
> the
> >>>> half-
> >>>>>> Would it be possible do a downgrade detection, meaning when
> non-
> >> PKK

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 8 Jan 2020 15:06:31 +0100

Hi Valery,

Both look good to me. Thanks!

One typo: s/mesages/messages/

Thanks!
Mirja

> On 8. Jan 2020, at 15:04, Valery Smyslov <[email-masked]> wrote:
> 
> Hi Mirja,
> 
> [...]
>

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 8 Jan 2020 17:09:48 +0300

> One typo: s/mesages/messages/

Thank you!

Regards,
Valery.

> >>> as if no responses were received at all. So, we introduce no new
> timeouts
> >> here
> >> 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 does mean that NO_PPK_AUTH notification should not be
> sent
> >>>> when
> >>>>>>>> least the order of magnitude? Maybe it could be recommended
> to
> >>>> wait a
> >>>>>>>> How long should one wait? Probably 1-2 RTTs if the RTT is known
> or
> >>>>>> maybe

---

From: Paul Wouters <[email-masked]>
Date: Wed, 8 Jan 2020 12:22:17 -0500

> On Jan 8, 2020, at 04:41, Mirja Kuehlewind <[email-masked]> wrote:
> 
>> 

I agree with Valerie. We don’t do that on purpose. A 100gbps connection is different from a satellite connection. Let the implementation handle that part.

> Having some downgrade detection would enable to log an attack if optional PPK was used.

That would be lost in the noise when using mixed ppl/noppk use I think. As said, one is expected to only allow noppk during migration, which would be very limited in time (like hours or days for static tunnels, maybe weeks or a few months for remote access VPN updates to happen)

Paul