[Docs] [txt|pdf] [Tracker] [Email] [Nits]
Versions: 00
CORE Working Group Y. Liu
Internet-Draft J. Zhu
Intended status: Standards Track Huawei
Expires: January 4, 2018 July 3, 2017
Mitigating delay attacks on Constrained Application Protocol
draft-liu-core-coap-delay-attacks-00
Abstract
Various attacks including delay attacks 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 that address some of the
disadvantages
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Liu & Zhu Expires January 4, 2018 [Page 1]
Internet-Draft CORE CoAP Delay attack July 2017
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. The Repeat Option . . . . . . . . . . . . . . . . . . . . 3
4.2. The Enhanced Options . . . . . . . . . . . . . . . . . . 5
4.2.1. Simple Single Action Actuators . . . . . . . . . . . 6
4.2.2. Multi-interrelated Actions . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. Tables . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
Various attacks including delay attacks have become a topic in the
security of Internet of Things (IoT) especially for the resource-
constrained nodes [RFC7252] utilizing sensors and actuators which
connect and interact with the physical world. It is recommended to
use the Constrained Application Protocol (CoAP) [RFC7252], which is
designed for resource-constrained nodes, and exchange messages
between them. Also, it is required to use security protocols such as
TLS [RFC5246], DTLS [RFC6347], TLS/DTLS profiles for the IoT
[RFC7925], or OSCOAP [I-D.ietf-core-object-security] to protect CoAP
messages due to security and privacy. The security protocols can
provide confidentiality, authentication and integrity protection of
CoAP messages at both the application layer and the network layer.
There are still issues related to delay attacks as descirbed in
[I-D.mattsson-core-coap-actuators]. For example,
[I-D.mattsson-core-coap-actuators] describes several serious attacks,
discusses tougher requirements and then recommends solution to
mitigate the attacks. The draft also indicates the disadvantage that
CoAP messages need two round trips for the solution. This document
will show alternative mechanisms which take CoAP messages only one
round trip by utilizing the sending messages containing valid time
window(s), Sequence Number and response policies.
Liu & Zhu Expires January 4, 2018 [Page 2]
Internet-Draft CORE CoAP Delay attack July 2017
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this specification are to be interpreted as described
in [RFC2119].
This specification requires readers to be familiar with all the terms
and concepts that are discussed in [I-D.mattsson-core-coap-actuators]
and [RFC7252].
3. Attacks
It is assumed that the reader is familiar with the following attacks
as described by section 2 of [I-D.mattsson-core-coap-actuators]:
o The Block Attack
o The Request Delay Attack
o The Response Delay and Mismatch Attack
o Relay Attack
4. Solutions
In order to mitigate the attacks as above,
[I-D.mattsson-core-coap-actuators] provides a challenge-response
mechanism for CoAP using a new CoAP Option "Repeat". This option is
described below in section 4.1. It is a copy of section 3 of the
[I-D.mattsson-core-coap-actuators]. An editor's note at the end of
that section indicates the disadvantage that the mechanism takes two
round trips and provides two potential enhancements utilizing time.
Section 4.2 in the document describes another method which takes only
one round trip CoAP messages which utilizes a "valid time window" ,
"Sequence Number" and "response policies" on receiving messages to
mitigate the delay attacks.
4.1. The Repeat Option
The Repeat Option is a challenge-response mechanism for CoAP, binding
a resent request to an earlier 4.03 forbidden response. The
challenge (for the client) is simply to echo the Repeat Option value
in a new request. The Repeat Option enables the server to verify the
freshness of a request, thus mitigating the Delay Attack. An example
message flow is illustrated in Figure:
Liu & Zhu Expires January 4, 2018 [Page 3]
Internet-Draft CORE CoAP Delay attack July 2017
Client Server
| |
+----->| Code: 0.03 (PUT)
| PUT | Token: 0x41
| | Uri-Path: lock
| | Payload: 0 (Unlock)
| |
|<-----+ t0 Code: 4.03 (Forbidden)
| 4.03 | Token: 0x41
| | Repeat: 0x6c880d41167ba807
| |
+----->| t1 Code: 0.03 (PUT)
| PUT | Token: 0x42
| | Uri-Path: lock
| | Repeat: 0x6c880d41167ba807
| | Payload: 0 (Unlock)
| |
|<-----+ Code: 2.04 (Changed)
| 2.04 | Token: 0x42
| |
Figure 1: The Repeat Option
The Repeat Option may be used for all Methods and Response Codes. In
responses, the value MUST be a (pseudo-) random bit string with a
length of at least 64 bits. A new (pseudo-) random bit string MUST
be generated for each response. In requests, the Repeat Option MUST
echo the value from a previously received response.
The Repeat Option is critical, Safe-to-Forward, not part of the
Cache-Key, and not repeatable.
Upon receiving a request without the Repeat Option to a resource with
freshness requirements, the server sends a 4.03 Forbidden response
with a Repeat Option and stores the option value and the response
transmit time t0.
Upon receiving a 4.03 Forbidden response with the Repeat Option, the
client SHOULD resend the request, echoing the Repeat Option value.
Upon receiving a request with the Repeat Option, the server verifies
that the option value equals the previously sent value; otherwise the
request is not processed further. The server calculates the round-
trip time RTT = (t1 - t0), where t1 is the request receive time. The
server MUST only accept requests with a round-trip time below a
certain threshold T, i.e. RTT < T, otherwise the request is not
processed further, and an error message MAY be send. The threshold T
is application specific.
Liu & Zhu Expires January 4, 2018 [Page 4]
Internet-Draft CORE CoAP Delay attack July 2017
4.2. The Enhanced Options
According to the method using a Repeat Option (see Section 4.1),
there are still the following potential situations:
o If the RTT of the second message or the third message (see
Figure 1) is larger than the certain threshold T, the server can
determine that the request message from the client is delayed and
then discard it.
o If the RTT of the second message or the third message (see
Figure 1) is large but does not exceed the certain threshold T,
the server treats these messages as valid and then processes them
normally. But these messages may have become invalid especially
in the situation where the request(s) containing actions relevant
for actuators are required to be processed in a specific and
limited period of time. For example, the actuator with the air
conditioning may be required to keep it open in a specific time
and temperature, which depends on some reasons such as people's
preferences and current weather. In other words, the specific
time may be varied, it is possible that the server determines the
request is valid by RTT < T but the potential specific time
associated with the request is actually past.
o If the RTT of the fourth message (see Figure 9) is larger than the
certain threshold T, it may cause that the client resends the
request message but the actuator's actions associated with the
previous message has already been processed.
o Regardless of whether the delay exists, the two round-trips
increase the delay in overall processing of the original action
(e.g. PUT)
In fact, the server cannot accurately know whether the messages are
delayed in a reasonable period of time or not, because the reasons
for the delay may be caused by the network itself and/or some attacks
such as man-in-the-middle. In other words, how to set T value
depends on many factors. Also, it is not enough to determine whether
the delay happens.
Due to IoT covering different vertical domains actuators have
different delay sensitivity requirements. Simple actuators (such as
a smart switch) support a single action and may not be delay
sensitive. There are others with complicated capabilities that are
able to process multi-interrelated actions especially in Industrial
Control and Production Systems. These actuators with multi-
interrelated actions are usually associated with strict time
requirements. Therefore, it is lack of a mechanism that assures them
Liu & Zhu Expires January 4, 2018 [Page 5]
Internet-Draft CORE CoAP Delay attack July 2017
process multi-continuous actions addressed in different request(s)
when the delay attack happens and even causes some mismatch/disorder.
4.2.1. Simple Single Action Actuators
For simple single action for the actuators, the Time Window Option is
introduced as a new CoAP option and is to address the validity period
of the request(s) from the client. The Time Window Option including
T-start (i.e., a start valid time) and T-duration (i.e., a valid
duration) of a request enables the server to accurately know the
freshness of a request, determine how to process it, and thus achieve
to mitigate the attacks described in Section 3.
Client Server
| |
+----->| Code: 0.03 (PUT)
| PUT | Token: 0x41
| | Uri-Path: lock
| | Payload: 0 (Unlock)
| | Valid-Window: T-start, T-duration
| |
|<-----+T-receive<T-start Code: 2.03 (Valid)
| 2.03 | Token: 0x41
| | Receipt: lining
| |
|<-----+T-start Code: 2.05 (Content)
| 2.05 | Token: 0x41
| | Receipt: OK
| |
Figure 2: The Time Window Option(1)
Upon receiving a request containing the Time Window Option, the
server extracts the T-start and T-duration from the first request
from the client.
If T-receive (a reception time for the server receiving a request) <
T-start as illustrated in Figure 2, it means that the server should
not do the actions carried in the request until T-start is coming.
The server should add this request to a waiting queue, and issues a
temporarily response (e.g. 2.03) to the client with the Receipt
Option indicating "Lining". When T-start is coming, the server gets
the corresponding request from the processing buffer, executes the
actions carried in the request, and sends a response 2.05 containing
a Receipt Option indicating "OK".
Liu & Zhu Expires January 4, 2018 [Page 6]
Internet-Draft CORE CoAP Delay attack July 2017
Client Server
| |
+----->| Code: 0.03 (PUT)
| PUT | Token: 0x41
| | Uri-Path: lock
| | Payload: 0 (Unlock)
| | Valid-Window: T-start, T-duration
| |
|<-----+T-receive in [T-start, T-start + T-duration] Code: 2.05 (Content)
| 2.05 | Token: 0x41
| | Receipt: OK
| |
Figure 3: The Time Window Option(2)
If T-receive (i.e., a reception time for the server receiving a
request) >= T-start and T-receive < (T-start + T-duration) as
illustrated in Figure 3, it means that the request is just in the
valid period of time. The server should process this request
immediately, stores a Receipt Option indicating "OK" in a normal
response for the client and returns this response with Code = 2.05.
Client Server
| |
+----->| Code: 0.03 (PUT)
| PUT | Token: 0x41
| | Uri-Path: lock
| | Payload: 0 (Unlock)
| | Valid-Window: T-start, T-duration
| |
|<-----+T-receive > (T-start + T-duration) Code: 4.03 (Forbidden)
| 4.03 | Token: 0x41
| | Receipt: Delay, Offset (T-receive - T-start)
| |
Figure 4: The Time Window Option(3)
If T-receive (i.e., a reception time for the server receiving a
request) > (T-start + T-duration) as illustrated in Figure 12, it
means that the request has become invalid. The server discards the
request and sends a 4.03 error response to the client with a "Delay"
Receipt Option indicating a time offset between T- receive and
T-current. The offset helps the client to estimate the RTT between
the client and the server, and thus set a more reasonable T-duration
for the subsequent messages.
Liu & Zhu Expires January 4, 2018 [Page 7]
Internet-Draft CORE CoAP Delay attack July 2017
4.2.2. Multi-interrelated Actions
When some complicated actuators are able to support multi-
interrelated actions with different request(s), it is desirable to be
required give some indications to the server to make actions
especially when there are delay caused by some attacks.
This document proposes the use of a Sequence Number CoAP option to
address the sending sequence of request(s) in the client side. This
document also proposes a new Response Polices CoAP option which is
valid with the Sequence Number Option. It is used to provide some
corresponding rules when the server recognizes that request(s) are
disorder via the Sequence Number Options in these messages. The
Response Policies are preemptive mode, sequential mode, and
sequential with conditional discard mode. Also, the Response
Policies may be pre-configured in the server side or may be specified
in the request(s) in the client side. If the server cannot get the
Response Policies, the server will default as preemptive mode.
Upon receiving a request containing the Sequence Number Option, the
server will do the following steps.
(1) The server is aware that the largest Sequence Number (SNmax) of
all previous request(s) is less than that of the current request
(SNcr). If SNmax is adjacent to SNcr and the previous request with
the SNmax has already been normally responded, the current request
should be responded based on Section 4.2.1. If the previous request
with SNmax is still to be lined, the server should respond the
current request with SNcr according to the response policies and the
validity period of the requests as below:
o preemptive mode: if T-start of the current request is coming, the
server does it immediately, and then discard the previous
request(s) who are in waiting queue and their Sequence Number(s)
are less than SNcr. If the later request(s)'s Sequence Number(s)
are less than SNcr, the server should discard them and then
respond an error indicating delay.
o sequential mode: the server should respond to the request(s)
orderly based on their Sequence Number(s). Although T-start of
the current request is coming, the server does not respond it
until the previous and later request(s) with Sequence Number(s)
less than SNcr has already been responded. Consequently, it is
possible that the current request may not be responded due to
expiration.
o sequential with conditional discard mode: the server should
respond to the request(s) strictly based on their Sequence Number
Liu & Zhu Expires January 4, 2018 [Page 8]
Internet-Draft CORE CoAP Delay attack July 2017
(s) till (T-start + T-duration) of the current request is coming.
At this time, the server must respond the current request and then
discard the previous and later request(s) with Sequence Number(s)
less than SNcr.
(2) The server is aware that the largest Sequence Number(SNmax) of
all previous request(s) is more than that of the current request
(SNcr).
o preemptive mode: if the request with SNmax has already been done,
the server should discard the current request and then answer an
error indicating delay. If the request with SNmax is still in
waiting queue, the server should add the current request to the
waiting queue and responds these previous requests based on
Section 4.2.1 till the T-start of the request with SNmax is
coming.
o sequential mode: the server should add the current request to the
waiting queue till the its' T-start is coming.
o sequential with conditional discard mode: the server should add
the current request to the waiting queue till the its' T-start is
coming. If the (T-start + T-duration) of the request with SNmax
is coming earlier than the T-start of the current request, the
server should do the request with SNmax and discard the current
request.
When some complicated actuators are able to support multi-
interrelated actions with different request(s), it is desirable to be
required give some indications to the server to make actions
especially when there are delay caused by some attacks
Note: It is to be added figures to illustrate the above examples in
the future.
5. Security Considerations
The whole document can be seen as security considerations for CoAP.
6. IANA Considerations
This document requests the registration of the following Option
Number, whose value have been assigned to the CoAP Option Numbers
Registry defined by [RFC7252].
Liu & Zhu Expires January 4, 2018 [Page 9]
Internet-Draft CORE CoAP Delay attack July 2017
+--------+-------------------+
| Number | Name |
+--------+-------------------+
| 30 | Time Window |
| | |
| 31 | Sequence Number |
| | |
| 32 | Response Policies |
+--------+-------------------+
7. Acknowledgements
TBD.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>.
[RFC7925] Tschofenig, H. and T. Fossati, "Transport Layer
Security(TLS)/ Datagram Transport Layer Security (DTLS)
Profiles for the Internet of Things", RFC 7925,
DOI 10.17487/RFC6347, December 2016,
<http://www.rfc-editor.org/info/rfc7925>.
Liu & Zhu Expires January 4, 2018 [Page 10]
Internet-Draft CORE CoAP Delay attack July 2017
8.2. Informative References
[I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security of CoAP", draft-ietf-core-object-
security-04 (work in progress), July 2017.
[I-D.mattsson-core-coap-actuators]
Mattsson, J., Fornehed, J., Selander, G., and F.
Palombini, "Controlling Actuators with CoAP", draft-
mattsson-core-copa-actuators-02 (work in progress),
November 2016.
Authors' Addresses
Yan Liu
Huawei
P.R.China
Email: scarlett.liuyan@huawei.com
Jintao Zhu
Huawei
P.R.China
Email: jintao.zhu@huawei.com
Liu & Zhu Expires January 4, 2018 [Page 11]
Html markup produced by rfcmarkup 1.122, available from
https://tools.ietf.org/tools/rfcmarkup/