Re: [core] WG Adoption Call for draft-mattsson-core-coap-attacks

[Marco Tiloca <[e-mail]>]

Dear all,

This mail closes the Adoption Call. The draft is adopted as a CoRE 
Working Group document.

Authors, once the submission system reopens, please submit a new version 
-00 as a Working Group document.

When doing so, please use the document name 
"draft-ietf-core-attacks-on-coap", thus making the agreed document scope 
evident.

We will also set up a CoRE Github repo to host the draft sources.

Thanks,
Marco, Jaime and Carsten


On 2022-02-25 21:32, [e-mail] wrote:
> Hi Achim,
>
> draft-mattsson-core-coap-attacks has a focus on using Request-Tag to mitigate attacks.  Usage of ETag is not mandated in RFC7252 or RFC7959 as far as I can tell (but is in to-be-RFC9177), but using ETag with Block2 mitigates potential attack confusion. See attack below.
>
> Otherwise, please see inline.
>
> Regards
>
> Jon
>
>> -----Original Message-----
>> From: Achim Kraus [mailto: [e-mail]]
>> Sent: 25 February 2022 16:22
>> To: [e-mail]
>> Cc: [e-mail]; 'Marco Tiloca'; [e-mail]
>> Subject: Re: [core] WG Adoption Call for draft-mattsson-core-coap-attacks
>>
>> Hi Jon,
>>
>> I'm not sure about:
>>
>>   > Again using Block-Wise transfers, there has not been consideration
>> for a delay attack causing the server to send back the wrong data in a
>> BLOCK2 response.  See
>> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcore-wg%2Fecho-request-tag%2Fissues%2F77&data=04%7C01%7Cmarco.tiloca%40ri.se%7C0d9dfd71175c489b8e1008d9f89ded79%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637814180496387412%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0T%2Bhaw%2FvEzciuzAdhsmmIxWXvIS13JM1LevFFOS2ntM%3D&reserved=0 .  If the attacker
>> delays the first request (which triggers a BLOCK2 response), and then
>> sends it just before/after the second request (also triggering a BLOCK2
>> response), the request for the next block for, say the second request,
>> from the client may get back the block from either the first or second
>> request.  This can only be mitigated using the Request-Tag on each
>> request, even though BLOCK1 is not being used for the request.  I think
>> this attack also needs to be included.
>>
>> Does this refer to RFC7959?
> Jon> Yes, as Block2s are being used as well as RFC9175
>>   > may get back the block from either the first or second request.
>>
>> But the response will contain a token, which is used for
>> request-response matching. So, do you assume, that both request are
>> using the same token (maybe then more a unintended violation of the
>> token uniqness)?
> Jon> No.  I would be expecting the Token to be different in each request that asks for the next payload of the body.  Use of the same Token is not recommended as per RFC9175, but people do not realize that an empty token should not be used across multiple requests (another attack if "Foe" was removing tokens as the CoAP packets passed through...).
>
> Jon> Client gets earlier value (ETag not used) against what it thought was the second request.
>
>     Client   Foe   Server
>        |      |      |
>        +------X      |    POST "request" T:1 { "offset":0, "length":2000}
>        |      |      |
>        +------------->    POST "request" T:2 { "offset":4000, "length":2000}
>        |      |      |
>        |      @------>    POST "request" T:1 { "offset":0, "length":2000}
>        |      |      |
>        <-------------+    2.04 T:2 Block2:0/1/1024 { data containing 4000:1024 }
>        |      |      |
>        <-------------+    2.04 T:1 Block2:0/1/1024 { data containing 0:1024 }
>        |      |      |
>        +------------->    POST "request" T:3 Block2:0/_/1024
>                           server - is this continuation of request using T:1 or T:2 ?
>        |      |      |
>        <-------------+    2.04 T:3 Block2:1/_/1024 { data containing 1024:2000 }
>                           Was this the expected data ?
>        |      |      |
>
> This is fixed if Request differentiating ETag is used in the response. The client may not be able to get the missing secondary block from the alternative request, unless Request-Tag is used in the initial request (hence issue 77).
>
> ~Jon>
>
>> best regards
>> Achim
>>
>> Am 25.02.22 um 11:24 schrieb [e-mail]:
>>> Hi All,
>>>
>>> I likewise am in favor of this document, but would like to see a few changes /
>> addition.
>>> Med is actually referring to 2.4, but this made me realize there was a trap of
>> seeing Block and hence thinking RFC7959 for 2.1 - "The Block Attack" which
>> actually has no reference to CoAP blocks.  A better section title could be "The
>> Blocking Attack" and s/Block Attack/Blocking Attack/ elsewhere.
>>> For 2.4, "Fragment" in terms of CoAP blocks is not defined, and is not used in
>> RFC7959 (RFC7959 refers to fragmentation issues outside of the CoAP layer), so
>> is unclear that "fragment" is meant to be referring to a CoAP RFC7959 (or
>> draft-ietf-core-new-block to-be-RFC9177) block.
>>> Thus, "2.4. The Request CoAP Block Rearrangement Attack" is a step in the
>> right direction for me.  Then most of the usage of the word fragment needs to
>> be replaced with block.
>>> As a note for mitigating 2.4.1, to-be-RFC9177 requires the use of Request-Tag
>> (https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-core-new-block%23section-4.3&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C0d9dfd71175c489b8e1008d9f89ded79%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637814180496387412%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=xOtwVuut7cr5b9XwymOOKszIa1o4wTy2JGsx3YZU%2Fcw%3D&amp;reserved=0)
>> and good use of tokens (https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-core-&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C0d9dfd71175c489b8e1008d9f89ded79%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637814180496387412%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=hGbqp8JV2ho9GDPEcoZoCG%2Bt3abngC23tkG%2B2pJfV4o%3D&amp;reserved=0
>> new-block#section-6).
>>> The lost blocks recovery mechanisms in to-be-RFC9177 mitigate the risk of
>> the wrong block being processed in a request by the server.
>>> Again using Block-Wise transfers, there has not been consideration for a delay
>> attack causing the server to send back the wrong data in a BLOCK2 response.
>> See https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcore-wg%2Fecho-request-tag%2Fissues%2F77&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C0d9dfd71175c489b8e1008d9f89ded79%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637814180496387412%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=0T%2Bhaw%2FvEzciuzAdhsmmIxWXvIS13JM1LevFFOS2ntM%3D&amp;reserved=0 .  If the attacker
>> delays the first request (which triggers a BLOCK2 response), and then sends it
>> just before/after the second request (also triggering a BLOCK2 response), the
>> request for the next block for, say the second request, from the client may get
>> back the block from either the first or second request.  This can only be
>> mitigated using the Request-Tag on each request, even though BLOCK1 is not
>> being used for the request.  I think this attack also needs to be included.
>>> Regards
>>>
>>> Jon
>>>
>>>> -----Original Message-----
>>>> From: [e-mail]
>> [mailto:[e-mail]]
>>>> Sent: 25 February 2022 07:24
>>>> To: Marco Tiloca; [e-mail] WG ([e-mail])
>>>> Subject: Re: [core] WG Adoption Call for draft-mattsson-core-coap-attacks
>>>>
>>>> Hi all,
>>>>
>>>> I support adoption.
>>>>
>>>> It would helpful to explicit in Section 2.1 that this is about 7959, not the
>> new
>>>> block (to-be-RFC9177). Assessing the case of the new-block would be useful
>> as
>>>> well.
>>>>
>>>> Thank you.
>>>>
>>>> Cheers,
>>>> Med
>>>>
>>>>> -----Message d'origine-----
>>>>> De : core <[e-mail]> De la part de Marco Tiloca
>>>>> Envoyé : jeudi 24 février 2022 17:21
>>>>> À : [e-mail] WG ([e-mail]) <[e-mail]>
>>>>> Objet : [core] WG Adoption Call for draft-mattsson-core-coap-attacks
>>>>>
>>>>> Dear all,
>>>>>
>>>>> This mail starts a 2 week Working Group Adoption Call for draft-
>>>>> mattsson-core-coap-attacks [1].
>>>>>
>>>>> Please, provide your feedback by Wednesday, March 10.
>>>>>
>>>>> Best,
>>>>> Marco and Jaime
>>>>>
>>>>> [1] https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mattsson-core-coap-attacks%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C0d9dfd71175c489b8e1008d9f89ded79%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637814180496387412%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3gOYdvrk2Vzwr8qaBE4F6TtZWIzt2Icwc39qw8AxIXg%3D&amp;reserved=0
>>>>>
>>>>> --
>>>>> Marco Tiloca
>>>>> Ph.D., Senior Researcher
>>>>>
>>>>> Division: Digital System
>>>>> Department: Computer Science
>>>>> Unit: Cybersecurity
>>>>>
>>>>> RISE Research Institutes of Sweden
>>>>> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ri.se%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C0d9dfd71175c489b8e1008d9f89ded79%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637814180496387412%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=ooZ8sdj2lmVZw16fHwTcBc7S975gUqJyT4b55WVmt4c%3D&amp;reserved=0
>>>>>
>>>>> Phone: [phone]
>>>>> Isafjordsgatan 22 / Kistagången 16
>>>>> SE-164 40 Kista (Sweden)
>>>>
>>>>
>> ___________________________________________________________________
>>>> ______________________________________________________
>>>>
>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>> confidentielles ou privilegiees et ne doivent donc
>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
>>>> message par erreur, veuillez le signaler
>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>>>> electroniques etant susceptibles d'alteration,
>>>> Orange decline toute responsabilite si ce message a ete altere, deforme ou
>>>> falsifie. Merci.
>>>>
>>>> This message and its attachments may contain confidential or privileged
>>>> information that may be protected by law;
>>>> they should not be distributed, used or copied without authorisation.
>>>> If you have received this email in error, please notify the sender and delete
>> this
>>>> message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that have been
>>>> modified, changed or falsified.
>>>> Thank you.
>>>>
>>>> _______________________________________________
>>>> core mailing list
>>>> [e-mail]
>>>> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcore&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C0d9dfd71175c489b8e1008d9f89ded79%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637814180496387412%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=HNmEKTfS3enlRp%2BpTiD1yQ5RnwEG4qKsiCRRFuY%2BmjU%3D&amp;reserved=0
>>> _______________________________________________
>>> core mailing list
>>> [e-mail]
>>> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcore&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C0d9dfd71175c489b8e1008d9f89ded79%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637814180496387412%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=HNmEKTfS3enlRp%2BpTiD1yQ5RnwEG4qKsiCRRFuY%2BmjU%3D&amp;reserved=0
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

RISE Research Institutes of Sweden
https://www.ri.se

Phone: [phone]
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)