draft-ietf-core-echo-request-tag-06.txt   draft-ietf-core-echo-request-tag-07.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: March 21, 2020 Ericsson AB Expires: March 22, 2020 Ericsson AB
September 18, 2019 September 19, 2019
CoAP: Echo, Request-Tag, and Token Processing CoAP: Echo, Request-Tag, and Token Processing
draft-ietf-core-echo-request-tag-06 draft-ietf-core-echo-request-tag-07
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 update to the client Token processing requirements of request. The update to the client Token processing requirements of
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 March 21, 2020. This Internet-Draft will expire on March 22, 2020.
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 37 skipping to change at page 2, line 37
3.4.1. Body Integrity Based on Payload Integrity . . . . . . 14 3.4.1. Body Integrity Based on Payload Integrity . . . . . . 14
3.4.2. Multiple Concurrent Block-wise Operations . . . . . . 15 3.4.2. Multiple Concurrent Block-wise Operations . . . . . . 15
3.4.3. Simplified Block-Wise Handling for Constrained 3.4.3. Simplified Block-Wise Handling for Constrained
Proxies . . . . . . . . . . . . . . . . . . . . . . . 16 Proxies . . . . . . . . . . . . . . . . . . . . . . . 16
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
6.1. Token reuse . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Token reuse . . . . . . . . . . . . . . . . . . . . . . . 18
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Methods for Generating Echo Option Values . . . . . 22 Appendix A. Methods for Generating Echo Option Values . . . . . 22
Appendix B. Request-Tag Message Size Impact . . . . . . . . . . 23 Appendix B. Request-Tag Message Size Impact . . . . . . . . . . 23
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 24 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 24
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
skipping to change at page 19, line 32 skipping to change at page 19, line 32
In some setups, Tokens can be reused without the above constraints, In some setups, Tokens can be reused without the above constraints,
as a different component in the setup provides the associations: as a different component in the setup provides the associations:
o In CoAP over TLS, retransmissions are not handled by the CoAP o In CoAP over TLS, retransmissions are not handled by the CoAP
layer and the replay window size is always exactly 1. When a layer and the replay window size is always exactly 1. When a
client is sending TLS protected requests without Observe to a client is sending TLS protected requests without Observe to a
single server, the client can reuse a Token as soon as the single server, the client can reuse a Token as soon as the
previous response with that Token has been received. previous response with that Token has been received.
o Requests whose responses are cryptographically bound to the o Requests whose responses are cryptographically bound to the
requests (like in OSCORE) can reuse Tokens indefinitely. <!- requests (like in OSCORE) can reuse Tokens indefinitely.
could be added but is probably not worth the lines of text
o Requests whose responses reflect all the data in the request that
is varied ofer reuses of the same token (for example, if a token
is always used on a single path with the single query parameter
"?t=X" for various values of X, then the response needs to contain
X in a unique position) can share a token, provided the
application does not rely on the freshness of the responses, or
sends different requests all the time. ->
In all other cases, a sequence number approach is recommended as per In all other cases, a sequence number approach is recommended as per
Section 5. Section 5.
Tokens that cannot be reused need to be blacklisted. This could be Tokens that cannot be reused need to be blacklisted. This could be
solved by increasing the Token as soon as the currently used Token solved by increasing the Token as soon as the currently used Token
cannot be reused, or by keeping a list of all blacklisted Tokens. cannot be reused, or by keeping a list of all blacklisted Tokens.
When the Token (or part of the Token) contains a sequence number, the 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 encoding of the sequence number has to be chosen in a way to avoid
skipping to change at page 24, line 20 skipping to change at page 24, line 9
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-06:
* Removed visible comment that should not be visible in Token
reuse considerations.
o Changes since draft-ietf-core-echo-request-tag-05: o Changes since draft-ietf-core-echo-request-tag-05:
* Add privacy considerations on cookie-style use of Echo values * Add privacy considerations on cookie-style use of Echo values
* Add security considerations for token reuse * Add security considerations for token reuse
* Add note in security considerations on use of nonvolatile * Add note in security considerations on use of nonvolatile
memory when dealing with pseudorandom numbers memory when dealing with pseudorandom numbers
* Appendix on echo generation: add a few words on up- and * Appendix on echo generation: add a few words on up- and
 End of changes. 6 change blocks. 
15 lines changed or deleted 11 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/