Re: [core] Block Transfer and Object Security .... Re: Agenda

[Göran Selander <[e-mail]>]

Hi Hannes,

Such a solution only is not very robust against denial of service unless
there is additional security at lower layer or that it is possible to
protect fragments in sizes of certain upper limit such as in HTTP content
encryption. In the case of application layer security only, one would thus
have to invent something like the latter. While this is possible, it would
be very unfortunate if for each CoAP "feature" being defined, you need to
separately define the corresponding "e2e secure feature", instead of
making these considerations before standardizing the feature in question.
In particular as in the case of Block where all feaures of a secure
fragmentation scheme are present if you only were able to apply integrity
protection of each CoAP block message between the endpoints.

That is the problem statement. In terms of solution, it actually seems
possible to separate options intended for proxies from options intended
for endpoints without additional intrusion on CoAP. This means that you
can reuse Block, which although wasn't designed for end-to-end security,
of course does work in the absense intermediaries making changes.

Since you seem to be interested in the details here it goes: The
application layer security solutions presented so far which are applicable
to 3.1 and 3.2 of draft-hartke-core-e2e-security-reqs are based on
wrapping an unprotected CoAP message in a COSE object and send this in a
("protected") CoAP message.  The idea for simultaneously managing
end-to-end and proxy options is based on the concept of “duplicate”
options introduced in the latest version of OSCOAP: For certain options we
may allow the use of an “inner” option encrypted inside the COSE object
intended for the endpoint, and an “outer” option in the options part of
protected CoAP message intended for a proxy.

The block options could potentially be used in this way, allowing the
sending endpoint using an inner block option to fragment a large message
where each fragment can be protected end-to-end. This allows for a policy
of an upper limit for fragments which can be verified, the lack of which
was one of the concerns.

These secure fragments can, if necessary, in turn be fragmented by a proxy
using an outer block option. The receiving endpoint then first defragments
the protected CoAP message, then verifies and decrypts, then after
verifying and decrypting all protected fragments, defragments the
unprotected CoAP message which becomes verified by this process. (The
outer and inner options may be independent, so either the endpoint or the
proxy or both fragment, the scenario above is the case of “both”, which of
course is the most complicated.)

This is in brief what I propose to discuss in the CoRE WG under the topic
of "blockwise" in the security section.


Göran




On 2016-03-28 16:58, "Hannes Tschofenig" <[e-mail]> wrote:

>Hi Goeran,
>
>normally you would do the following:
>
> 1) You take the entire payload (for example a firmware image).
> 2) You add some security protection in the front.
> 3) Then, you make it available for download.
> 4) A server may then chunk it into pieces and delivery them separately
>using the Blockwise Transfer mechanism.
> 5) The client receives all the pieces, puts them together, verifies the
>signature or MAC, and then updates the firmware.
>
>This sequence of steps should be the same regardless of whether there is
>a proxy that caches pieces or not.
>
>So, what exactly is the concern here?
>
>Ciao
>Hannes
>
>On 03/28/2016 03:36 PM, Göran Selander wrote:
>> Hi Hannes
>> 
>> Complementing Carsten’s explanation:
>> 
>> There is a conflict between being able to protect a message fragment
>> end-to-end between endpoints and giving any intermediate node the right
>>to
>> refragment a message. Block operations performed by proxies cannot be
>> verified which has two consequences. Blockwise cannot be directly
>>applied
>> to secure message fragmentation, and the Block option opens up for DoS
>>by
>> any on-path adversary. I found this serious enough to warrant a security
>> consideration, which is included in -19.
>> 
>> It turns out that while plaintext CoAP block options passing proxies
>> cannot be protected in the way  blockwise works, they could potentially
>>be
>> used end-to-end if you were certain there were no changes being made in
>> transfer, and that is something an object security solution could be
>>used
>> for. This is one of the topics I’d like to discuss in the security
>>section
>> on the CoRE agenda.
>> 
>> Göran
>> 
>> 
>> 
>> On 2016-03-28 14:14, "core on behalf of Carsten Bormann"
>> <[e-mail] on behalf of [e-mail]> wrote:
>> 
>>> Hi Hannes,
>>>
>>>> I have re-read the Blockwise Transfer draft and the document does not
>>>> give me the impression that there is any specific need to tie it to
>>>> Object Security.
>>>>
>>>> Can you explain what the relationship is?
>>>
>>> After the last call completed, we had a discussion on the IETF mailing
>>> list how to employ object security in a block-wise transfer that spans
>>> proxies.
>>> If you secure only the complete representation, the cache in a proxy
>>> might be poisoned by fake blocks, and you get an availability problem.
>>> If you secure each of the blocks (and have a way for the proxy to be
>>> part of a security association needed so it also can verify the
>>>blocks),
>>> you can prevent that, but you still have to secure the way the entire
>>> representation is composed from those blocks, and that might mean
>>> additional components are needed in an object security protocol.
>>>
>>> I agree that none of these considerations have a bearing on the
>>> block-wise protocol itself, and this also was the resolution we reached
>>> after the discussion.  But it was useful to have the discussion, and it
>>> will inform the discussion about object security.
>>>
>>>> I hope there is no plan to make the completion of Blockwise transfer
>>>> dependent on the progress of object security.
>>>
>>> No, as far as the CoRE WG is concerned, block-wise is done.
>>> It is currently in IESG evaluation and on the agenda of the 2016-04-21
>>> IESG telechat; Matthias Kovatsch is the shepherd.
>>>
>>> Grüße, Carsten
>>>
>>> _______________________________________________
>>> core mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/core
>>