< draft-ietf-core-echo-request-tag-04.txt   draft-ietf-core-echo-request-tag-05.txt >
CoRE Working Group C. Amsuess CoRE Working Group C. Amsuess
Internet-Draft Internet-Draft
Updates: 7252 (if approved) J. Mattsson Updates: 7252 (if approved) J. Mattsson
Intended status: Standards Track G. Selander Intended status: Standards Track G. Selander
Expires: September 25, 2019 Ericsson AB Expires: November 7, 2019 Ericsson AB
March 24, 2019 May 06, 2019
CoAP: Echo, Request-Tag, and Token Processing CoAP: Echo, Request-Tag, and Token Processing
draft-ietf-core-echo-request-tag-04 draft-ietf-core-echo-request-tag-05
Abstract Abstract
This document specifies enhancements to the Constrained Application This document specifies enhancements to the Constrained Application
Protocol (CoAP) that mitigate security issues in particular use Protocol (CoAP) that mitigate security issues in particular use
cases. The Echo option enables a CoAP server to verify the freshness 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 of a request or to force a client to demonstrate reachability at its
claimed network address. The Request-Tag option allows the CoAP claimed network address. The Request-Tag option allows the CoAP
server to match Block-Wise message fragments belonging to the same server to match Block-Wise message fragments belonging to the same
request. The updated Token processing requirements for clients request. The updated Token processing requirements for clients
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 25, 2019. This Internet-Draft will expire on November 7, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 41 skipping to change at page 2, line 41
3.5. Rationale for the Option Properties . . . . . . . . . . . 16 3.5. Rationale for the Option Properties . . . . . . . . . . . 16
3.6. Rationale for Introducing the Option . . . . . . . . . . 16 3.6. Rationale for Introducing the Option . . . . . . . . . . 16
4. Block2 / ETag Processing . . . . . . . . . . . . . . . . . . 17 4. Block2 / ETag Processing . . . . . . . . . . . . . . . . . . 17
5. Token Processing . . . . . . . . . . . . . . . . . . . . . . 17 5. Token Processing . . . . . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Methods for Generating Echo Option Values . . . . . 20 Appendix A. Methods for Generating Echo Option Values . . . . . 21
Appendix B. Request-Tag Message Size Impact . . . . . . . . . . 22 Appendix B. Request-Tag Message Size Impact . . . . . . . . . . 22
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 22 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
The initial Constrained Application Protocol (CoAP) suite of The initial Constrained Application Protocol (CoAP) suite of
specifications ([RFC7252], [RFC7641], and [RFC7959]) was designed specifications ([RFC7252], [RFC7641], and [RFC7959]) was designed
with the assumption that security could be provided on a separate with the assumption that security could be provided on a separate
skipping to change at page 5, line 29 skipping to change at page 5, line 29
value and does not give stricter guidelines than that the tokens value and does not give stricter guidelines than that the tokens
currently "in use" SHOULD (not SHALL) be unique. If used with a currently "in use" SHOULD (not SHALL) be unique. If used with a
security protocol not providing bindings between requests and security protocol not providing bindings between requests and
responses (e.g. DTLS and TLS) token reuse may result in situations responses (e.g. DTLS and TLS) token reuse may result in situations
where a client matches a response to the wrong request. Note that where a client matches a response to the wrong request. Note that
mismatches can also happen for other reasons than a malicious mismatches can also happen for other reasons than a malicious
attacker, e.g. delayed delivery or a server sending notifications to attacker, e.g. delayed delivery or a server sending notifications to
an uninterested client. an uninterested client.
A straightforward mitigation is to mandate clients to not reuse A straightforward mitigation is to mandate clients to not reuse
tokens until the traffic keys have been replaced. The easiest way to tokens until the traffic keys have been replaced. One easy way to
accomplish this is to implement the token as a counter starting at accomplish this is to implement the token as a counter starting at
zero for each new or rekeyed secure connection. This document zero for each new or rekeyed secure connection. This document
updates the Token processing in [RFC7252] to always assure a updates the Token processing in [RFC7252] to always assure a
cryptographically secure binding of responses to requests for secure cryptographically secure binding of responses to requests for secure
REST operations like "coaps". REST operations like "coaps".
1.4. Terminology 1.4. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
skipping to change at page 17, line 33 skipping to change at page 17, line 33
As described in Section 1.3, the client must be able to verify that a As described in Section 1.3, the client must be able to verify that a
response corresponds to a particular request. This section updates response corresponds to a particular request. This section updates
the CoAP Token processing requirements for clients. The Token the CoAP Token processing requirements for clients. The Token
processing for servers is not updated. Token processing in processing for servers is not updated. Token processing in
Section 5.3.1 of [RFC7252] is updated by adding the following text: Section 5.3.1 of [RFC7252] is updated by adding the following text:
When CoAP is used with a security protocol not providing bindings When CoAP is used with a security protocol not providing bindings
between requests and responses, the tokens have cryptographic between requests and responses, the tokens have cryptographic
importance. The client MUST make sure that tokens are not used in a importance. The client MUST make sure that tokens are not used in a
way so that responses risk being associated with the wrong request. way so that responses risk being associated with the wrong request.
The easiest way to accomplish this is to implement the Token (or part One easy way to accomplish this is to implement the Token (or part of
of the Token) as a sequence number starting at zero for each new or the Token) as a sequence number starting at zero for each new or
rekeyed secure connection, this approach SHOULD be followed. To rekeyed secure connection, this approach SHOULD be followed.
avoid collisions the sequence number can be encoded with a fixed
length or with some length-value encoding.
6. Security Considerations 6. Security Considerations
The availability of a secure pseudorandom number generator and truly The availability of a secure pseudorandom number generator and truly
random seeds are essential for the security of the Echo option. If random seeds are essential for the security of the Echo option. If
no true random number generator is available, a truly random seed no true random number generator is available, a truly random seed
must be provided from an external source. must be provided from an external source.
A single active Echo value with 64 (pseudo-)random bits gives the A single active Echo value with 64 (pseudo-)random bits gives the
same theoretical security level against forgeries as a 64-bit MAC (as same theoretical security level against forgeries as a 64-bit MAC (as
skipping to change at page 18, line 42 skipping to change at page 18, line 41
Servers MAY reset the timer at certain times and MAY generate a Servers MAY reset the timer at certain times and MAY generate a
random offset applied to all timestamps. When resetting the timer, random offset applied to all timestamps. When resetting the timer,
the server MUST reject all Echo values that was created before the the server MUST reject all Echo values that was created before the
reset. reset.
Servers that use the List of Cached Random Values and Timestamps Servers that use the List of Cached Random Values and Timestamps
method described in Appendix A may be vulnerable to resource method described in Appendix A may be vulnerable to resource
exhaustion attacks. One way to minimize state is to use the exhaustion attacks. One way to minimize state is to use the
Integrity Protected Timestamp method described in Appendix A. Integrity Protected Timestamp method described in Appendix A.
When the Token (or part of the Token) contains a sequence number, the
encoding of the sequence number has to be chosen in a way to avoid
any collisions. This is especially true when the Token contains more
information than just the sequence number (e.g. serialized state).
7. Privacy Considerations 7. Privacy Considerations
Implementations SHOULD NOT put any privacy sensitive information in Implementations SHOULD NOT put any privacy sensitive information in
the Echo or Request-Tag option values. Unencrypted timestamps MAY the Echo or Request-Tag option values. Unencrypted timestamps MAY
reveal information about the server such as location or time since reveal information about the server such as location or time since
reboot. The use of wall clock time is not allowed (see Section 6) reboot. The use of wall clock time is not allowed (see Section 6)
and there also privacy reasons, e.g. it may reveal that the server and there also privacy reasons, e.g. it may reveal that the server
will accept expired certificates. Timestamps MAY be used if Echo is will accept expired certificates. Timestamps MAY be used if Echo is
encrypted between the client and the server, e.g. in the case of DTLS encrypted between the client and the server, e.g. in the case of DTLS
without proxies or when using OSCORE with an Inner Echo option. without proxies or when using OSCORE with an Inner Echo option.
skipping to change at page 22, line 40 skipping to change at page 22, line 45
o In OSCORE, the sequence number can be artificially increased so o In OSCORE, the sequence number can be artificially increased so
that all lost messages are outside of the replay window by the that all lost messages are outside of the replay window by the
time the first request of the new operation gets processed, and time the first request of the new operation gets processed, and
all earlier operations can therefore be regarded as concluded. all earlier operations can therefore be regarded as concluded.
Appendix C. Change Log Appendix C. Change Log
[ The editor is asked to remove this section before publication. ] [ The editor is asked to remove this section before publication. ]
o Changes since draft-ietf-core-echo-request-tag-04:
* Editorial fixes
+ Moved paragraph on collision-free encoding of data in the
token to Security Considerations and rephrased it
+ "easiest" -> "one easy"
o Changes since draft-ietf-core-echo-request-tag-03: o Changes since draft-ietf-core-echo-request-tag-03:
* Mention token processing changes in title * Mention token processing changes in title
* Abstract reworded * Abstract reworded
* Clarify updates to token processing * Clarify updates to token processing
* Describe security levels from Echo length * Describe security levels from Echo length
 End of changes. 8 change blocks. 
11 lines changed or deleted 23 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/