There was a thread on the CoRE WG mailing list a couple of months ago on
the topic of blockwise and object security. The starting point was a
question if CoAP proxies can (re-)partition messages into blocks as
defined in this draft, and the implications on end-to-end security between
client and server through such a proxy. The conclusions of that discussion
has an impact on this draft, but there are no considerations of this kind
made in version -18. More details are given below, including some
alternative proposals for how to address this. Apologies for the long
e-mail.
Background:
There is an ongoing discussion in CoRE and ACE WGs since a year on the
end-to-end security properties of CoAP, i.e. protecting the communication
between a client and a server through proxies. RFC 7252 and other
specifications in the CoAP suite define a set of legitimate proxy
operations on CoAP messages which requires DTLS to be terminated at
proxies. This implies that the proxy has access not only with the data
required for perform the intended proxy operation but is also able to
eavesdrop or manipulate any part of the CoAP payload and metadata in
transit between client and server without being protected or detected by
DTLS.
One way to mitigate this threat is to complement or replace DTLS with
application layer protection of CoAP payload and metadata between client
and server for the use cases where the proxy should not be fully trusted.
This has been discussed in the CoRE WG meetings during the three last IETF
F2F meetings and there are draft solutions using the message format being
developed in the COSE WG.
With the COAP proxy operations standardized so far it has been possible to
protect the CoAP messages adequately with security on transport layer,
application layer or a combination thereof. In the case where the
legitimate proxy operation is predictable by client and server,
application layer security can be defined to both verify that no
illegitimate changes has been performed as well as verifying the
legitimate changes. In the case where proxy operations are not predictable
— even if the data the proxy is operating on cannot be protected — it has
so far been possible to use other information elements to provide the
required end-to-end security properities. For example, the CoAP header
field Token may be changed by a proxy, but instead a transaction
identifier can be introduced in the application security wrapper (COSE
header) to define a message (exchange) identifier common to client and
server.
Blockwise:
With the definition of blockwise transfer as specified in this draft a
proxy may partition or re-partitioning a message into blocks where the
size of the blocks are decided by the proxy. As a consequence, it is not
possible to integrity protect individual blocks end-to-end between client
and server: DTLS does not protect the message data within the proxy, and
application layer integrity protection of individual blocks cannot be
performed unless the partitioning into blocks as received by one endpoint
is identical to that sent by the other endpoint. Hence, when CoAP Block
options are used as defined in this draft, end-to-end security of the
individual CoAP request and response breaks down. For example: a proxy may
addBlock options, send any number of blocks with any payload to an
endpoint without being possible to detect or protect against. In contrast
to the existing standards in the CoAP suite, in this case it is not
possible to bypass the construction and define a secure end-to-end block
partitioning with less than disabling block partitioning as specified in
this draft.
One solution to this is to disallow proxies to re-partition a message,
thus redefine the Block options such that they are possible to integrity
protect end-to-end. Integrity protecting each block and corresponding
Block options as defined in the current draft has additional benefits: If
any block in the sequence fails verification, it can be individually
requested to be resent. When all blocks has been verified the entire
message has been verified. A receiving node may even perform certain
actions based on received verified blocks before the entire message has
been received.
Instead of delegating to proxies to partition into blocks, the sending
endpoint would need to anticipate or get information about the relevant
block size, e.g. using a size indication in the link-format description
[RFC6990]. Additional methods for blocksize discovery may also be defined.
While this may not be as simple as leaving it entirely to the proxy to
decide, considering the additional security benefits I believe this is the
right trade off to make.
An alternative solution is to prevent proxies from re-partitioning a
message only in the case where end-to-end security of CoAP message is
applied, which in current solution proposals is indicated with the
presence of a certain CoAP option X (which e.g. contains the COSE object).
This would have the same benefits as the previous solution, but requires
the code in the proxy implementing this draft to be aware of option X, and
hence that dependency needs to be specified in this draft. And option X is
not standardized yet, so would require introducing a placeholder.
There are other alternatives as well but this e-mail is already too long.
The main point I wanted to make is that given that we now have a better
understanding of how to achieve security between client and server through
proxies compared to when RFC7252 was written, my opinon is that we should
not ignore these security issues in new standards.
Göran
On 2015-11-20 22:32, "The IESG" <iesg-secretary(_at_)ietf(_dot_)org> wrote:
The IESG has received a request from the Constrained RESTful Environments
WG (core) to consider the following document:
- 'Block-wise transfers in CoAP'
<draft-ietf-core-block-18.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2015-12-04. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
Abstract
CoAP is a RESTful transfer protocol for constrained nodes and
networks. Basic CoAP messages work well for the small payloads we
expect from temperature sensors, light switches, and similar
building-automation devices. Occasionally, however, applications
will need to transfer larger payloads -- for instance, for firmware
updates. With HTTP, TCP does the grunt work of slicing large
payloads up into multiple packets and ensuring that they all arrive
and are handled in the right order.
CoAP is based on datagram transports such as UDP or DTLS, which
limits the maximum size of resource representations that can be
transferred without too much fragmentation. Although UDP supports
larger payloads through IP fragmentation, it is limited to 64 KiB
and, more importantly, doesn't really work well for constrained
applications and networks.
Instead of relying on IP fragmentation, this specification extends
basic CoAP with a pair of "Block" options, for transferring multiple
blocks of information from a resource representation in multiple
request-response pairs. In many important cases, the Block options
enable a server to be truly stateless: the server can handle each
block transfer separately, with no need for a connection setup or
other server-side memory of previous block transfers.
In summary, the Block options provide a minimal way to transfer
larger representations in a block-wise fashion.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-core-block/
IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-core-block/ballot/
No IPR declarations have been submitted directly on this I-D.