--- 1/draft-ietf-core-echo-request-tag-04.txt 2019-05-06 08:14:00.336583693 -0700 +++ 2/draft-ietf-core-echo-request-tag-05.txt 2019-05-06 08:14:00.388585013 -0700 @@ -1,20 +1,20 @@ CoRE Working Group C. Amsuess Internet-Draft Updates: 7252 (if approved) J. Mattsson Intended status: Standards Track G. Selander -Expires: September 25, 2019 Ericsson AB - March 24, 2019 +Expires: November 7, 2019 Ericsson AB + May 06, 2019 CoAP: Echo, Request-Tag, and Token Processing - draft-ietf-core-echo-request-tag-04 + draft-ietf-core-echo-request-tag-05 Abstract 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. The updated Token processing requirements for clients @@ -29,21 +29,21 @@ 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 https://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 September 25, 2019. + This Internet-Draft will expire on November 7, 2019. Copyright Notice Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -76,21 +76,21 @@ 3.5. Rationale for the Option Properties . . . . . . . . . . . 16 3.6. Rationale for Introducing the Option . . . . . . . . . . 16 4. Block2 / ETag Processing . . . . . . . . . . . . . . . . . . 17 5. Token Processing . . . . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative 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 C. Change Log . . . . . . . . . . . . . . . . . . . . . 22 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction The initial Constrained Application Protocol (CoAP) suite of specifications ([RFC7252], [RFC7641], and [RFC7959]) was designed with the assumption that security could be provided on a separate @@ -208,21 +208,21 @@ value and does not give stricter guidelines than that the tokens currently "in use" SHOULD (not SHALL) be unique. If used with a security protocol not providing bindings between requests and responses (e.g. DTLS and TLS) token reuse may result in situations where a client matches a response to the wrong request. 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. 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 zero for each new or rekeyed secure connection. This document updates the Token processing in [RFC7252] to always assure a cryptographically secure binding of responses to requests for secure REST operations like "coaps". 1.4. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and @@ -768,25 +768,23 @@ As described in Section 1.3, the client must be able to verify that a response corresponds to a particular request. This section updates the CoAP Token processing requirements for clients. The Token processing for servers is not updated. Token processing in Section 5.3.1 of [RFC7252] is updated by adding the following text: When CoAP is used with a security protocol not providing bindings between requests and responses, the tokens have cryptographic importance. The client MUST make sure that tokens are not used in a way so that responses risk being associated with the wrong request. - The easiest way to accomplish this is to implement the Token (or part - of the Token) as a sequence number starting at zero for each new or - rekeyed secure connection, this approach SHOULD be followed. To - avoid collisions the sequence number can be encoded with a fixed - length or with some length-value encoding. + One easy way to accomplish this is to implement the Token (or part of + the Token) as a sequence number starting at zero for each new or + rekeyed secure connection, this approach SHOULD be followed. 6. Security Considerations The availability of a secure pseudorandom number generator and truly random seeds are essential for the security of the Echo option. If no true random number generator is available, a truly random seed must be provided from an external source. A single active Echo value with 64 (pseudo-)random bits gives the same theoretical security level against forgeries as a 64-bit MAC (as @@ -826,20 +824,25 @@ Servers MAY reset the timer at certain times and MAY generate a random offset applied to all timestamps. When resetting the timer, the server MUST reject all Echo values that was created before the reset. Servers that use the List of Cached Random Values and Timestamps method described in Appendix A may be vulnerable to resource exhaustion attacks. One way to minimize state is to use the 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 Implementations SHOULD NOT put any privacy sensitive information in the Echo or Request-Tag option values. Unencrypted timestamps MAY reveal information about the server such as location or time since 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 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 without proxies or when using OSCORE with an Inner Echo option. @@ -1013,20 +1016,29 @@ o In OSCORE, the sequence number can be artificially increased so that all lost messages are outside of the replay window by the time the first request of the new operation gets processed, and all earlier operations can therefore be regarded as concluded. Appendix C. Change Log [ 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: * Mention token processing changes in title * Abstract reworded * Clarify updates to token processing * Describe security levels from Echo length