Re: [core] [Technical Errata Reported] RFC7252 (5284)

Hello,

Please note there is also a security issue with re-use of tokens. The
following formulation is used in
https://tools.ietf.org/html/draft-ietf-core-echo-request-tag-01#section-5

"When CoAP is used with a security protocol not providing bindings
   between requests and responses, the client MUST NOT reuse 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."

Regards
Göran

On 2018-03-14 13:23, "core on behalf of mohamed.boucadair@orange.com"
<core-bounces@ietf.org on behalf of mohamed.boucadair@orange.com> wrote:

>Hi Achim,
>(ccing DOTS WG)
>
>Thank you for sharing your thoughts.
>
>I'm personally OK with any wording which makes clear that distinct tokens
>are generated to differentiate among concurrent requests involving the
>same source/destination endpoints.
>
>I'm not sure to understand what you meant by "per simultaneous request",
>though.  
>
>Cheers,
>Med
>
>> -----Message d'origine-----
>> De : Kraus Achim (INST/ECS4) [mailto:Achim.Kraus@bosch-si.com]
>> Envoyé : mercredi 14 mars 2018 12:59
>> À : RFC Errata System; zach.shelby@arm.com; hartke@tzi.org;
>>cabo@tzi.org;
>> ben@nostrum.com; aamelnikov@fastmail.fm; adam@nostrum.com; cabo@tzi.org;
>> jaime@iki.fi
>> Cc : BOUCADAIR Mohamed IMT/OLN; core@ietf.org
>> Objet : RE: [core] [Technical Errata Reported] RFC7252 (5284)
>> 
>> Hi,
>> 
>> if the current definition "tokens currently in use" is interpreted as
>>for
>> "all pending requests", I can't see, that adding "per request" improves
>>the
>> RFC.
>> If something is added, I would recommend to precise that also with the
>>time-
>> scope,
>> e.g. "per simultaneous request".
>> 
>> Mit freundlichen Grüßen / Best regards
>> 
>>  Achim Kraus
>> 
>> (INST/ECS4)
>> Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332
>>Waiblingen |
>> GERMANY | www.bosch-si.com
>> 
>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
>> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung:
>>Dr.
>> Stefan Ferber, Michael Hahn
>> 
>> -----Original Message-----
>> From: core [mailto:core-bounces@ietf.org] On Behalf Of RFC Errata System
>> Sent: Freitag, 9. März 2018 10:34
>> To: zach.shelby@arm.com; hartke@tzi.org; cabo@tzi.org; ben@nostrum.com;
>> aamelnikov@fastmail.fm; adam@nostrum.com; cabo@tzi.org; jaime@iki.fi
>> Cc: mohamed.boucadair@orange.com; core@ietf.org;
>>rfc-editor@rfc-editor.org
>> Subject: [core] [Technical Errata Reported] RFC7252 (5284)
>> 
>> The following errata report has been submitted for RFC7252, "The
>>Constrained
>> Application Protocol (CoAP)".
>> 
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata/eid5284
>> 
>> --------------------------------------
>> Type: Technical
>> Reported by: Mohamed Boucadair <mohamed.boucadair@orange.com>
>> 
>> Section: 5.3.1
>> 
>> Original Text
>> -------------
>> The client SHOULD generate tokens in such a way that tokens currently
>>in use
>> for a given source/destination endpoint pair are unique.
>> 
>> Corrected Text
>> --------------
>> The client SHOULD generate tokens in such a way that tokens currently
>>in use
>> for a given source/destination endpoint pair are unique per request.
>> 
>> Notes
>> -----
>> Multiple requests may be active for a given source/destination endpoint
>>pair.
>> The OLD text is thus broken.
>> 
>> The NEW text is aligned with the definition of the Token:
>> 
>>   A token is intended for use as a client-local identifier for
>>   differentiating between concurrent requests (see Section 5.3); it
>>   could have been called a "request ID".
>> 
>> Further, using the same token for a given source/destination endpoint
>>pair
>> have some implications, for example, for applications which require the
>> support of multiple observe queries because RFC7641 states the
>>following:
>> 
>>    The entry in the list of observers is keyed by the client endpoint
>>     and the token specified by the client in the request.  If an entry
>>     with a matching endpoint/token pair is already present in the list
>>     (which, for example, happens when the client wishes to reinforce
>>     its interest in a resource), the server MUST NOT add a new entry
>>     but MUST replace or update the existing one.
>> 
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If necessary, please use
>> "Reply All" to discuss whether it should be verified or rejected. When a
>> decision is reached, the verifying party can log in to change the
>>status and
>> edit the report, if necessary.
>> 
>> --------------------------------------
>> RFC7252 (draft-ietf-core-coap-18)
>> --------------------------------------
>> Title               : The Constrained Application Protocol (CoAP)
>> Publication Date    : June 2014
>> Author(s)           : Z. Shelby, K. Hartke, C. Bormann
>> Category            : PROPOSED STANDARD
>> Source              : Constrained RESTful Environments APP
>> Area                : Applications
>> Stream              : IETF
>> Verifying Party     : IESG
>> 
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
>
>_______________________________________________
>core mailing list
>core@ietf.org
>https://www.ietf.org/mailman/listinfo/core