Comments from Carsten to fix for -02

[emanjon]

Carsten was kind to review the whole document and has provided a lot of good comments. For the upcoming -01 version I have addressed Carsten's comments for Abstract, Introduction, and Denial-of-service attacks. The rest of the comments should be fixed for -02 together with the other issues from Achim and Christian which are also related to section 2.

    1.1.  Terminology

       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
       "OPTIONAL" in this document are to be interpreted as described in BCP
       14 [RFC2119] [RFC8174] when, and only when, they appear in all
       capitals, as shown here.

Explain how this terminology applies to an informational document.

    2.  Attacks

       Internet-of-Things (IoT) deployments valuing security and privacy,
       MUST use a security protocol such as DTLS, TLS, or OSCORE to protect
       CoAP.  This is especially true for deployments of actuators where
       attacks often (but not always) have serious consequences.  The
       attacks described in this section are made under the assumption that
       CoAP is already protected with a security protocol such as DTLS, TLS,
       or OSCORE, as an attacker otherwise can easily forge false requests
       and responses.

    2.1.  The Block Attack

       An on-path attacker can block the delivery of any number of requests
       or responses.  The attack can also be performed by an attacker
       jamming the lower layer radio protocol.  This is true even if a
       security protocol like DTLS, TLS, or OSCORE is used.  Encryption
       makes selective blocking of messages harder, but not impossible or
       even infeasible.  With DTLS and TLS, proxies have access to the

access = read, or full MITM, or what?

       complete CoAP message, and with OSCORE, the CoAP header and several
       CoAP options are not encrypted.  In both security protocols, the IP-
       addresses, ports, and CoAP message lengths are available to all on-
       path attackers, which may be enough to determine the server,
       resource, and command.  The block attack is illustrated in Figures 1
       and 2.

                     Client   Foe   Server
                        |      |      |
                        +----->X      |      Code: 0.03 (PUT)
                        | PUT  |      |     Token: 0x47
                        |      |      |  Uri-Path: lock
                        |      |      |   Payload: 1 (Lock)
                        |      |      |

                           Figure 1: Blocking a request

    Preuss Mattsson, et al. Expires November 17, 2021               [Page 4]
    
    Internet-Draft                CoAP Attacks                      May 2021

       Where 'X' means the attacker is blocking delivery of the message.

                   Client   Foe   Server
                      |      |      |
                      +------------>|      Code: 0.03 (PUT)
                      |      | PUT  |     Token: 0x47
                      |      |      |  Uri-Path: lock
                      |      |      |   Payload: 1 (Lock)
                      |      |      |
                      |      X<-----+      Code: 2.04 (Changed)
                      |      | 2.04 |     Token: 0x47
                      |      |      |

                           Figure 2: Blocking a response

       While blocking requests to, or responses from, a sensor is just a
       denial of service attack, blocking a request to, or a response from,
       an actuator results in the client losing information about the
       server's status.  If the actuator e.g. is a lock (door, car, etc.),
       the attack results in the client not knowing (except by using out-of-
       band information) whether the lock is unlocked or locked, just like
       the observer in the famous Schrodinger's cat thought experiment.  Due
       to the nature of the attack, the client cannot distinguish the attack
       from connectivity problems, offline servers, or unexpected behavior
       from middle boxes such as NATs and firewalls.

       Remedy: Any IoT deployment of actuators where confirmation is
       important MUST notify the user upon reception of the response, or
       warn the user when a response is not received.

What is a "user"?

It is not the "deployment" that can do this, but the client.

    2.2.  The Request Delay Attack

       An on-path attacker may not only block packets, but can also delay
       the delivery of any packet (request or response) by a chosen amount
       of time.  If CoAP is used over a reliable and ordered transport such
       as TCP with TLS or OSCORE, no messages can be delivered before the
       delayed message.  If CoAP is used over an unreliable and unordered
       transport such as UDP with DTLS, or OSCORE, other messages can be
       delivered before the delayed message as long as the delayed packet is
       delivered inside the replay window.  When CoAP is used over UDP, both
       DTLS and OSCORE allow out-of-order delivery and uses sequence numbers
       together with a replay window to protect against replay attacks.  The
       replay window has a default length of 64 in DTLS and 32 in OSCORE.
       The attacker can control the replay window by blocking some or all

What does "control the window" mean?

       other packets.  By first delaying a request, and then later, after
       delivery, blocking the response to the request, the client is not
       made aware of the delayed delivery except by the missing response.
       The server has in general, no way of knowing that the request was

    Preuss Mattsson, et al. Expires November 17, 2021               [Page 5]
    
    Internet-Draft                CoAP Attacks                      May 2021

       delayed and will therefore happily process the request.  Note that
       delays can also happen for other reasons than a malicious attacker.

       If some wireless low-level protocol is used, the attack can also be
       performed by the attacker simultaneously recording what the client
       transmits while at the same time jamming the server.  The request
       delay attack is illustrated in Figure 3.

                   Client   Foe   Server
                      |      |      |
                      +----->@      |      Code: 0.03 (PUT)
                      | PUT  |      |     Token: 0x9c
                      |      |      |  Uri-Path: lock
                      |      |      |   Payload: 0 (Unlock)
                      |      |      |
                        ....   ....
                      |      |      |
                      |      @----->|      Code: 0.03 (PUT)
                      |      | PUT  |     Token: 0x9c
                      |      |      |  Uri-Path: lock
                      |      |      |   Payload: 0 (Unlock)
                      |      |      |
                      |      X<-----+      Code: 2.04 (Changed)
                      |      | 2.04 |     Token: 0x9c
                      |      |      |

                           Figure 3: Delaying a request

       Where '@' means the attacker is storing and later forwarding the
       message (@ may alternatively be seen as a wormhole connecting two
       points in time).

       While an attacker delaying a request to a sensor is often not a
       security problem, an attacker delaying a request to an actuator
       performing an action is often a serious problem.  A request to an
       actuator (for example a request to unlock a lock) is often only meant
       to be valid for a short time frame, and if the request does not reach
       the actuator during this short timeframe, the request should not be
       fulfilled.  In the unlock example, if the client does not get any
       response and does not physically see the lock opening, the user is
       likely to walk away, calling the locksmith (or the IT-support).

       If a non-zero replay window is used (the default when CoAP is used
       over UDP), the attacker can let the client interact with the actuator
       before delivering the delayed request to the server (illustrated in
       Figure 4).  In the lock example, the attacker may store the first
       "unlock" request for later use.  The client will likely resend the
       request with the same token.  If DTLS is used, the resent packet will

    Preuss Mattsson, et al. Expires November 17, 2021               [Page 6]
    
    Internet-Draft                CoAP Attacks                      May 2021

       have a different sequence number and the attacker can forward it.  If
       OSCORE is used, resent packets will have the same sequence number and
       the attacker must block them all until the client sends a new message
       with a new sequence number (not shown in Figure 4).  After a while
       when the client has locked the door again, the attacker can deliver
       the delayed "unlock" message to the door, a very serious attack.

                   Client   Foe   Server
                      |      |      |
                      +----->@      |      Code: 0.03 (PUT)
                      | PUT  |      |     Token: 0x9c
                      |      |      |  Uri-Path: lock
                      |      |      |   Payload: 0 (Unlock)
                      |      |      |
                      +------------>|      Code: 0.03 (PUT)
                      | PUT  |      |     Token: 0x9c
                      |      |      |  Uri-Path: lock
                      |      |      |   Payload: 0 (Unlock)
                      |      |      |
                      <-------------+      Code: 2.04 (Changed)
                      |      | 2.04 |     Token: 0x9c
                      |      |      |
                        ....   ....
                      |      |      |
                      +------------>|      Code: 0.03 (PUT)
                      | PUT  |      |     Token: 0x7a
                      |      |      |  Uri-Path: lock
                      |      |      |   Payload: 1 (Lock)
                      |      |      |
                      <-------------+      Code: 2.04 (Changed)
                      |      | 2.04 |     Token: 0x7a
                      |      |      |
                      |      @----->|      Code: 0.03 (PUT)
                      |      | PUT  |     Token: 0x9c
                      |      |      |  Uri-Path: lock
                      |      |      |   Payload: 0 (Unlock)
                      |      |      |
                      |      X<-----+      Code: 2.04 (Changed)
                      |      | 2.04 |     Token: 0x9c
                      |      |      |

                    Figure 4: Delaying request with reordering

       While the second attack (Figure 4) can be mitigated by using a replay
       window of length zero, the first attack (Figure 3) cannot.  A
       solution must enable the server to verify that the request was
       received within a certain time frame after it was sent or enable the
       server to securely determine an absolute point in time when the

    Preuss Mattsson, et al. Expires November 17, 2021               [Page 7]
    
    Internet-Draft                CoAP Attacks                      May 2021

       request is to be executed.  This can be accomplished with either a
       challenge-response pattern, by exchanging timestamps between client
       and server, or by only allowing requests a short period after client
       authentication.

       Requiring a fresh client authentication (such as a new TLS/DTLS
       handshake or an EDHOC key exchange [I-D.ietf-lake-edhoc]) mitigates
       the problem, but requires larger messages and more processing than a
       dedicated solution.  Security solutions based on exchanging
       timestamps require exactly synchronized time between client and
       server, and this may be hard to control with complications such as
       time zones and daylight saving.  Wall clock time SHOULD NOT be used
       as it is not monotonic, may reveal that the endpoints will accept
       expired certificates, or reveal the endpoint's location.  Use of non-

That is a pretty strong statement that I don't agree with.

       monotonic clocks is not secure as the server will accept requests if
       the clock is moved backward and reject requests if the clock is moved
       forward.  Even if the clocks are synchronized at one point in time,
       they may easily get out-of-sync and an attacker may even be able to
       affect the client or the server time in various ways such as setting
       up a fake NTP server, broadcasting false time signals to radio
       controlled clocks, or expose one of them to a strong gravity field.

expose -> exposing (I'd love to hear more about your gravity attack. This is a bit like lighting a match under a temp sensor...)

       As soon as client falsely believes it is time synchronized with the
       server, delay attacks are possible.  A challenge response mechanism
       where the server does not need to synchronize its time with the
       client is easier to analyze but require more roundtrips.  The
       challenges, responses, and timestamps may be sent in a CoAP option or
       in the CoAP payload.

       Remedy: The mechanisms specified in [I-D.ietf-core-echo-request-tag]
       or [I-D.liu-core-coap-delay-attacks] SHALL be used for controlling
       actuators unless another application specific challenge-response or
       timestamp mechanism is used.

Too strong statement.

Why the alternative? One is an approved WG document.

(See comment about RFC2119 keywords in an informational document.)

    2.3.  The Response Delay and Mismatch Attack

       The following attack can be performed if CoAP is protected by a
       security protocol where the response is not bound to the request in
       any way except by the CoAP token.  This would include most general
       security protocols, such as DTLS, TLS, and IPsec, but not OSCORE.
       CoAP [RFC7252] uses a client generated token that the server echoes
       to match responses to request, but does not give any guidelines for
       the use of token with DTLS and TLS, except that the tokens currently
       "in use" SHOULD (not SHALL) be unique.  The attacker performs the
       attack by delaying delivery of a response until the client sends a
       request with the same token, the response will be accepted by the
       client as a valid response to the later request.  If CoAP is used
       over a reliable and ordered transport such as TCP with TLS, no
       messages can be delivered before the delayed message.  If CoAP is

    Preuss Mattsson, et al. Expires November 17, 2021               [Page 8]
    
    Internet-Draft                CoAP Attacks                      May 2021

       used over an unreliable and unordered transport such as UDP with
       DTLS, other messages can be delivered before the delayed message as
       long as the delayed packet is delivered inside the replay window.
       Note that mismatches can also happen for other reasons than a
       malicious attacker, e.g. delayed delivery or a server sending
       notifications to an uninterested client.

       The attack can be performed by an attacker on the wire, or an
       attacker simultaneously recording what the server transmits while at
       the same time jamming the client.  The response delay and mismatch
       attack is illustrated in Figure 5.

                   Client   Foe   Server
                      |      |      |
                      +------------>|      Code: 0.03 (PUT)
                      | PUT  |      |     Token: 0x77
                      |      |      |  Uri-Path: lock
                      |      |      |   Payload: 0 (Unlock)
                      |      |      |
                      |      @<-----+      Code: 2.04 (Changed)
                      |      | 2.04 |     Token: 0x77
                      |      |      |
                        ....   ....
                      |      |      |
                      +----->X      |      Code: 0.03 (PUT)
                      | PUT  |      |     Token: 0x77
                      |      |      |  Uri-Path: lock
                      |      |      |   Payload: 0 (Lock)
                      |      |      |
                      <------@      |      Code: 2.04 (Changed)
                      | 2.04 |      |     Token: 0x77
                      |      |      |

                Figure 5: Delaying and mismatching response to PUT

       If we once again take a lock as an example, the security consequences
       may be severe as the client receives a response message likely to be
       interpreted as confirmation of a locked door, while the received
       response message is in fact confirming an earlier unlock of the door.
       As the client is likely to leave the (believed to be locked) door
       unattended, the attacker may enter the home, enterprise, or car
       protected by the lock.

       The same attack may be performed on sensors, also this with serious

this with?

       consequences.  As illustrated in Figure 6, an attacker may convince
       the client that the lock is locked, when it in fact is not.  The
       "Unlock" request may be also be sent by another client authorized to
       control the lock.

    Preuss Mattsson, et al. Expires November 17, 2021               [Page 9]
    
    Internet-Draft                CoAP Attacks                      May 2021

                   Client   Foe   Server
                      |      |      |
                      +------------>|      Code: 0.01 (GET)
                      | GET  |      |     Token: 0x77
                      |      |      |  Uri-Path: lock
                      |      |      |
                      |      @<-----+      Code: 2.05 (Content)
                      |      | 2.05 |     Token: 0x77
                      |      |      |   Payload: 1 (Locked)
                      |      |      |
                      +------------>|      Code: 0.03 (PUT)
                      | PUT  |      |     Token: 0x34
                      |      |      |  Uri-Path: lock
                      |      |      |   Payload: 1 (Unlock)
                      |      |      |
                      |      X<-----+      Code: 2.04 (Changed)
                      |      | 2.04 |     Token: 0x34
                      |      |      |
                      +----->X      |      Code: 0.01 (GET)
                      | GET  |      |     Token: 0x77
                      |      |      |  Uri-Path: lock
                      |      |      |
                      <------@      |      Code: 2.05 (Content)
                      | 2.05 |      |     Token: 0x77
                      |      |      |   Payload: 1 (Locked)
                      |      |      |

                Figure 6: Delaying and mismatching response to GET

       As illustrated in Figure 7, an attacker may even mix responses from
       different resources as long as the two resources share the same
       (D)TLS connection on some part of the path towards the client.  This
       can happen if the resources are located behind a common gateway, or
       are served by the same CoAP proxy.  An on-path attacker (not
       necessarily a (D)TLS endpoint such as a proxy) may e.g. deceive a
       client that the living room is on fire by responding with an earlier
       delayed response from the oven (temperatures in degree Celsius).

    Preuss Mattsson, et al. Expires November 17, 2021              [Page 10]
    
    Internet-Draft                CoAP Attacks                      May 2021

               Client   Foe   Server
                  |      |      |
                  +------------>|      Code: 0.01 (GET)
                  | GET  |      |     Token: 0x77
                  |      |      |  Uri-Path: oven/temperature
                  |      |      |
                  |      @<-----+      Code: 2.05 (Content)
                  |      | 2.05 |     Token: 0x77
                  |      |      |   Payload: 225
                  |      |      |
                    ....   ....
                  |      |      |
                  +----->X      |      Code: 0.01 (GET)
                  | GET  |      |     Token: 0x77
                  |      |      |  Uri-Path: livingroom/temperature
                  |      |      |
                  <------@      |      Code: 2.05 (Content)
                  | 2.05 |      |     Token: 0x77
                  |      |      |   Payload: 225
                  |      |      |

          Figure 7: Delaying and mismatching response from other resource

       Remedy: If CoAP is protected with a security protocol not providing
       bindings between requests and responses (e.g.  DTLS and TLS) the
       client MUST NOT reuse any tokens until the traffic keys have been
       replaced.  The easiest way to accomplish this is to implement the
       Token as a counter, this approach SHOULD be followed.

    2.4.  The Relay Attack

       Yet another type of attack can be performed in deployments where
       actuator actions are triggered automatically based on proximity and
       without any user interaction, e.g. a car (the client) constantly
       polling for the car key (the server) and unlocking both doors and
       engine as soon as the car key responds.  An attacker (or pair of
       attackers) may simply relay the CoAP messages out-of-band, using for
       examples some other radio technology.  By doing this, the actuator
       (i.e. the car) believes that the client is close by and performs
       actions based on that false assumption.  The attack is illustrated in
       Figure 8.  In this example the car is using an application specific
       challenge-response mechanism transferred as CoAP payloads.

    Preuss Mattsson, et al. Expires November 17, 2021              [Page 11]
    
    Internet-Draft                CoAP Attacks                      May 2021

       Client   Foe         Foe   Server
          |      |           |      |
          +----->| ......... +----->|      Code: 0.02 (POST)
          | POST |           | POST |     Token: 0x3a
          |      |           |      |  Uri-Path: lock
          |      |           |      |   Payload: JwePR2iCe8b0ux (Challenge)
          |      |           |      |
          |<-----+ ......... |<-----+      Code: 2.04 (Changed)
          | 2.04 |           | 2.04 |     Token: 0x3a
          |      |           |      |   Payload: RM8i13G8D5vfXK (Response)
          |      |           |      |

                Figure 8: Relay attack (the client is the actuator)

       The consequences may be severe, and in the case of a car, lead to the
       attacker unlocking and driving away with the car, an attack that
       unfortunately is happening in practice.

       Remedy: Getting a response over a short-range radio MUST NOT be taken
       as proof of proximity and therefore MUST NOT be used to take actions
       based on such proximity.  Any automatically triggered mechanisms
       relying on proximity MUST use other stronger mechanisms to guarantee
       proximity.  Mechanisms that MAY be used are: measuring the round-trip
       time and calculate the maximum possible distance based on the speed
       of light, or using radio with an extremely short range like NFC
       (centimeters instead of meters) that cannot be relayed through e.g.
       clothes.  Another option is to including geographical coordinates

huh, clothes???

to including

       (from e.g.  GPS) in the messages and calculate proximity based on
       these, but in this case the location measurements MUST be very
       precise and the system MUST make sure that an attacker cannot
       influence the location estimation, something that is very hard in
       practice.

make sure or influence -- what is hard?

    2.5.  The Request Fragment Rearrangement Attack

       These attack scenarios show that the Request Delay and Block Attacks
       can be used against blockwise transfers to cause unauthorized
       operations to be performed on the server, and responses to
       unauthorized operations to be mistaken for responses to authorized
       operations.  The combination of these attacks is described as a
       separate attack because it makes the Request Delay Attack relevant to
       systems that are otherwise not time-dependent, which means that they
       could disregard the Request Delay Attack.

       This attack works even if the individual request/response pairs are
       encrypted, authenticated and protected against the Response Delay and
       Mismatch Attack, provided the attacker is on the network path and can
       correctly guess which operations the respective packages belong to.

    Preuss Mattsson, et al. Expires November 17, 2021              [Page 12]
    
    Internet-Draft                CoAP Attacks                      May 2021

    2.5.1.  Completing an Operation with an Earlier Final Block

       In this scenario (illustrated in Figure 9), blocks from two
       operations on a POST-accepting resource are combined to make the
       server execute an action that was not intended by the authorized
       client.  This works only if the client attempts a second operation
       after the first operation failed (due to what the attacker made
       appear like a network outage) within the replay window.  The client
       does not receive a confirmation on the second operation either, but,
       by the time the client acts on it, the server has already executed
       the unauthorized action.

       Client   Foe   Server
          |      |      |
          +------------->    POST "incarcerate" (Block1: 0, more to come)
          |      |      |
          <-------------+    2.31 Continue (Block1: 0 received, send more)
          |      |      |
          +----->@      |    POST "valjean" (Block1: 1, last block)
          |      |      |
          +----->X      |    All retransmissions dropped
          |      |      |

       (Client: Odd, but let's go on and promote Javert)

          |      |      |
          +------------->    POST "promote" (Block1: 0, more to come)
          |      |      |
          |      X<-----+    2.31 Continue (Block1: 0 received, send more)
          |      |      |
          |      @------>    POST "valjean" (Block1: 1, last block)
          |      |      |
          |      X<-----+    2.04 Valjean Promoted
          |      |      |

           Figure 9: Completing an operation with an earlier final block

       Remedy: If a client starts new blockwise operations on a security
       context that has lost packages, it needs to label the fragments in
       such a way that the server will not mix them up.

       A mechanism to that effect is described as Request-Tag
       [I-D.ietf-core-echo-request-tag].  Had it been in place in the
       example and used for body integrity protection, the client would have
       set the Request-Tag option in the "promote" request.  Depending on
       the server's capabilities and setup, either of four outcomes could
       have occurred:

    Preuss Mattsson, et al. Expires November 17, 2021              [Page 13]
    
    Internet-Draft                CoAP Attacks                      May 2021

       1.  The server could have processed the reinjected POST "valjean" as
           belonging to the original "incarcerate" block; that's the
           expected case when the server can handle simultaneous block
           transfers.

       2.  The server could respond 5.03 Service Unavailable, including a
           Max-Age option indicating how long it prefers not to take any
           requests that force it to overwrite the state kept for the
           "incarcerate" request.

       3.  The server could decide to drop the state kept for the
           "incarcerate" request's state, and process the "promote" request.
           The reinjected POST "valjean" will then fail with 4.08 Request
           Entity incomplete, indicating that the server does not have the
           start of the operation any more.

    2.5.2.  Injecting a Withheld First Block

       If the first block of a request is withheld by the attacker for later
       use, it can be used to have the server process a different request
       body than intended by the client.  Unlike in the previous scenario,
       it will return a response based on that body to the client.

       Again, a first operation (that would go like "Homeless stole apples.
       What shall we do with him?" - "Set him free.") is aborted by the
       proxy, and a part of that operation is later used in a different
       operation to prime the server for responding leniently to another
       operation that would originally have been "Hitman killed someone.
       What shall we do with him?" - "Hang him.".  The attack is illustrated
       in Figure 10.

Not a very nice example.

    Preuss Mattsson, et al. Expires November 17, 2021              [Page 14]
    
    Internet-Draft                CoAP Attacks                      May 2021

       Client   Foe   Server
          |      |      |
          +----->@      |    POST "Homeless stole apples. Wh"
          |      |      |        (Block1: 0, more to come)

       (Client: We'll try that one later again; for now, we have something
       more urgent:)

          |      |      |
          +------------->    POST "Hitman killed someone. Wh"
          |      |      |        (Block1: 0, more to come)
          |      |      |
          |      @<-----+    2.31 Continue (Block1: 0 received, send more)
          |      |      |
          |      @------>    POST "Homeless stole apples. Wh"
          |      |      |        (Block1: 0, more to come)
          |      |      |
          |      X<-----+    2.31 Continue (Block1: 0 received, send more)
          |      |      |
          <------@      |    2.31 Continue (Block1: 0 received, send more)
          |      |      |
          +------------->    POST "at shall we do with him?"
          |      |      |        (Block1: 1, last block)
          |      |      |
          <-------------+    2.05 "Set him free."
          |      |      |        (Block1: 1 received and this is the result)

                    Figure 10: Injecting a withheld first block

[emanjon]

-02 addresses all the comments closing.