CoAP AttacksEricsson ABSE-164 80 StockholmSwedenjohn.mattsson@ericsson.comEricsson ABSE-164 80 StockholmSwedenjohn.fornehed@ericsson.comEricsson ABSE-164 80 StockholmSwedengoran.selander@ericsson.comEricsson ABSE-164 80 StockholmSwedenfrancesca.palombini@ericsson.comEnergy Harvesting Solutionsc.amsuess@energyharvesting.atBeing able to securely read information from sensors, to securely control actuators, and
to not enable distributed denial-of-service attacks are essential in a world of
connected and networking things interacting with
the physical world. This document summarizes a number of known attacks on CoAP and
show that just using CoAP with a security protocol like DTLS, TLS, or OSCORE is not
enough for secure operation. The document also summarizes different denial-of-service
attacks using CoAP. The goal with this document is motivating generic
and protocol-specific recommendations on the usage of CoAP. Several of the
discussed attacks can be mitigated with the solutions in
draft-ietf-core-echo-request-tag.RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this
draft is maintained in GitHub. Issues and pull requests can be submitted
at https://github.com/EricssonResearch/coap-actuatorsBeing able to securely read information from sensors and to securely control actuators
are essential in a world of connected and networking things interacting with
the physical world. One protocol used to interact with sensors and actuators
is the Constrained Application Protocol (CoAP) . Any
Internet-of-Things (IoT) deployment valuing security and privacy would
use a security protocol such as DTLS , TLS , or
OSCORE to protect CoAP, where the choice of security
protocol depends on the transport protocol and the presence of intermediaries.
The use of CoAP over UDP and DTLS is specified in and the
use of CoAP over TCP and TLS is specified in . OSCORE
protects CoAP end-to-end with the use of COSE and the CoAP
Object-Security option , and can therefore be used over any
transport.The Constrained Application Protocol (CoAP) was designed
with the assumption that security could be provided on a separate
layer, in particular by using DTLS . The four properties
traditionally provided by security protocols are:Data confidentialityData origin authenticationData integrity checkingReplay protectionIn this document we show that protecting CoAP with a security protocol on
another layer is not nearly enough to securely control actuators (and in
many cases sensors) and that secure operation often demands far more than
the four properties traditionally provided by security protocols. We describe
several serious attacks any on-path attacker (i.e., not only “trusted intermediaries”)
can do and discusses tougher requirements and mechanisms to mitigate the
attacks. In general, secure operation of actuators also requires the three
properties:Data-to-data bindingData-to-space bindingData-to-time binding“Data-to-data binding” is e.g., binding of responses to a request or binding
of data fragments to each other. “Data-to-space binding” is the binding of
data to an absolute or relative point in space (i.e., a location) and may
in the relative case be referred to as proximity. “Data-to-time binding”
is the binding of data to an absolute or relative point in time and may in
the relative case be referred to as freshness. The two last properties may
be bundled together as “Data-to-spacetime binding”.The request delay attack (valid for DTLS, TLS, and OSCORE and
described in ) lets an attacker control an actuator at a
much later time than the client anticipated. The response delay and
mismatch attack (valid for DTLS and TLS and described in )
lets an attacker respond to a client with a response meant for an
older request. The request fragment rearrangement attack (valid for
DTLS, TLS, and OSCORE and described in ) lets an attacker
cause unauthorized operations to be performed on the server, and
responses to unauthorized operations to be mistaken for responses to
authorized operations.Protecting CoAP against attacks is not enough. CoAP deployments
need to make sure that they are not used for distributed denial-of-service
attacks. summarizes different
denial-of-service attacks using CoAP. When transported over UDP, the CoAP
NoSec mode is susceptible to source IP address spoofing and as a single
request can result in multiple responses from multiple servers, CoAP
can have very large amplification factors.The goal with this document is motivating generic
and protocol-specific recommendations on the usage of CoAP.
Mechanisms mitigating some of the attacks discussed in this document can
be found in .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 when, and only when, they appear in all capitals, as shown here.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.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 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 and .Where ‘X’ means the attacker is blocking delivery of the message.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.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 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 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 .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
). 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 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
). 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.While the second attack () can be mitigated by
using a replay window of length zero, the first attack ()
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
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 ) 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-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. 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
or SHALL be used for controlling
actuators unless another application specific
challenge-response or timestamp mechanism is used.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 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 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 .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 consequences.
As illustrated in , 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.As illustrated in , 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).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.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
. In this example the car is using an application specific
challenge-response mechanism transferred as CoAP payloads.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
(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.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.In this scenario (illustrated in ), 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.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
. 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: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.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.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.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
.In a Denial-of-Service (DoS) attack, an attacker sends a large number of requests
or responses to a target endpoint. The denial-of-service might be caused by
the target endpoint receiving a large amount of data, sending a large amount
of data, doing heavy processing, or using too much memory, etc. In a Distributed
Denial-of-Service (DDoS) attack, the request or responses come from a large
number of sources.In an amplification attack, the amplification factor is the ratio between the
total size of the data sent to the target and the total size of the data
sent by the attacker. In the attacks described in this section, the
attacker sends one or more requests, and the target receives one or more
responses. An amplification attack alone can be a denial-of-service attack on a server,
but often amplification attacks are combined with the attacker spoofing the
source IP address of the targeted victim. By requesting as much information
as possible from several servers an attacker can multiply the amount of
traffic and create a distributed denial-of-service attack on the target.
When transported over UDP, the CoAP NoSec
mode is susceptible to source IP address spoofing.Amplification attacks with CoAP is unfortunately not only theory, amplification
factors of 10-100 are commonly reported from NoSec deployments. and
report average amplification factors of 27 and 34 respectively
from a single response to a GET request for /.well-known/core to the default UDP port 5683.
NoSec CoAP servers accessible over the Internet are mostly concentrated to a few countries
and a few implementations, which do not follow the recommendations in Section
11.3 of (but the requirements are a bit soft).An amplification attack using a single response is illustrated in .
If the response is c times larger than the request, the amplification factor is c.An attacker can increase the bandwidth by sending several GET requests. An attacker can
also increase or control the amplification factor by creating or updating resources.
By creating new resources, an attacker can increase the size of /.well-known/core.
An amplification attack where the attacker influences the amplification factor
is illustrated in .Amplification factors can be significantly worse when combined with
observe and group requests . As a single
request can result in multiple responses from multiple servers, the amplification
factors can be very large.An amplification attack using observe is illustrated in
. If each notification response is c times larger than the registration
request and each request results in n notifications, the amplification factor is c * n.
By registering the same client several times using different Tokens or port numbers,
the bandwidth can be increased. By updating the observed resource, the attacker
may trigger notifications and increase the size of the notifications. By using
conditional attributes an attacker may increase the frequency of
notifications and therefore the amplification factor. The maximum period attribute pmax
indicates the maximum time, in seconds, between two consecutive notifications (whether or not the
resource state has changed). If it is predictable when notifications
are sent as confirmable and which Message ID are used the acknowledgements may be spoofed.An amplification attack using a group request is illustrated in
. The group request is sent over multicast or broadcast
and in this case a single request results in m responses
from m different servers. If each response is c times larger than the request,
the amplification factor is c * m. Note that the servers usually do not know
the variable m.An amplification attack using a multicast request and observe is
illustrated in . In this case a single request results
in n responses each from m different servers giving a total of n * m
responses. If each response is c times larger than the request,
the amplification factor is c * n * m.While CoAP has always considered amplification attacks, the recommendations
in , , and are a bit soft.
Most of the requirements are “SHOULD” instead of “MUST”, it is undefined what a
“large amplification factor” is, does not specify how many notifications
that can be sent before a potentially spoofable acknowledgement must be sent, and
in several cases the “SHOULD” level is further softened by “If possible” and “generally”.
does not have any amplification attack considerations.QUIC mandates that ”an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address” without any exceptions. This approach should be seen as current best practice.In CoAP, an address can be validated with a security protocol like DTLS, TLS, OSCORE, or by using the Echo Option . Restricting the bandwidth per server is not enough as the number of servers the attacker can use is typically unknown. For multicast requests, anti-amplification limits and the Echo Option do not really work unless the number of servers sending responses is known. Even if the responses have the same size as the request, the amplification factor from m servers is m, where m is typically unknown. While DoS attacks from CoAP servers accessible over the Internet pose the largest threat, an attacker on a local network might use local CoAP servers to attack targets on the Internet or on the local network.Remedy: should be updated with a strict normative requirement (MUST) on implementations similar to QUIC with a specified anti-amplification limit and no exceptions. It should be clear that any devices used in DDoS attacks are violating IETF requirements.The whole document can be seen as security considerations for CoAP.This document has no actions for IANA.Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.The Constrained Application Protocol (CoAP)The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.Observing Resources in the Constrained Application Protocol (CoAP)The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server.CoAP: Echo, Request-Tag, and Token ProcessingEricsson ABEricsson AB This document specifies enhancements to the Constrained Application
Protocol (CoAP) that mitigate security issues in particular use
cases. The Echo option enables a CoAP server to verify the freshness
of a request or to force a client to demonstrate reachability at its
claimed network address. The Request-Tag option allows the CoAP
server to match block-wise message fragments belonging to the same
request. This document updates RFC 7252 with respect to the client
Token processing requirements, forbidding non-secure reuse of Tokens
to ensure binding of response to request when CoAP is used with a
security protocol, and with respect to amplification mitigation,
where the use of Echo is now recommended.
Conditional Attributes for Constrained RESTful EnvironmentsSmartThingsTampere University This specification defines Conditional Notification and Control
Attributes that work with CoAP Observe (RFC7641).
Editor note
The git repository for the draft is found at TBD
Group Communication for the Constrained Application Protocol (CoAP)IoTconsultancy.nlInterDigitalRISE AB This document specifies the use of the Constrained Application
Protocol (CoAP) for group communication, including the use of UDP/IP
multicast as the default underlying data transport. Both unsecured
and secured CoAP group communication are specified. Security is
achieved by use of the Group Object Security for Constrained RESTful
Environments (Group OSCORE) protocol. The target application area of
this specification is any group communication use cases that involve
resource-constrained devices or networks that support CoAP. This
document replaces RFC7390, while it updates RFC7252 and RFC7641.
Datagram Transport Layer Security Version 1.2This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]CBOR Object Signing and Encryption (COSE)Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.CoAP (Constrained Application Protocol) over TCP, TLS, and WebSocketsThe Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control.Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport.The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.Object Security for Constrained RESTful Environments (OSCORE)This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252.QUIC: A UDP-Based Multiplexed and Secure TransportThis document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.Mitigating delay attacks on Constrained Application ProtocolHuaweiHuawei Various attacks including delay attack have become a topic in the
security of Internet of Things (IoT), especially for the constrained
nodes utilizing sensors and actuators which connect and interact with
the physical world. [I-D.mattsson-core-coap-actuators] describes
several serious delay attacks, discusses tougher requirements and
then recommends mechanisms to mitigate the attacks. It also
specifies some disadvantages with the mechanisms. This document
proposes alternative mechanisms to address some of the disadvantages
Ephemeral Diffie-Hellman Over COSE (EDHOC)Ericsson ABEricsson ABEricsson AB This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a
very compact and lightweight authenticated Diffie-Hellman key
exchange with ephemeral keys. EDHOC provides mutual authentication,
perfect forward secrecy, and identity protection. EDHOC is intended
for usage in constrained scenarios and a main use case is to
establish an OSCORE security context. By reusing COSE for
cryptography, CBOR for encoding, and CoAP for transport, the
additional code size can be kept very low.
The Datagram Transport Layer Security (DTLS) Protocol Version 1.3This document specifies Version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection/non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347.CoAP Attacks In The WildAccessible CoAP ReportThe authors would like to thank Carsten Bormann, Klaus Hartke, Jaime Jiménez, Ari Keränen,
Matthias Kovatsch, Achim Kraus, Sandeep Kumar, and András Méhes for their valuable comments
and feedback.