ietf
[Top] [All Lists]

Re: [core] Last Call: <draft-ietf-core-block-18.txt> (Block-wise transfers in CoAP) to Proposed Standard

2016-02-01 02:20:42
Hi Jim

Thanks for picking up the thread.

We spent some time in Prague thinking about this. You are right that there
are different options with different characteristics. Here are the cases
we have considered.

Just to recap the objective, this is about protecting communication
between CoAP client and CoAP server while allowing legitimate operations
of one or more intermediary CoAP proxies. Client and server are assumed to
have a security association.

On a high level the candidate solutions are either built entirely on top
of CoAP or add new CoAP options.

Looking at the former first, one solution is to wrap just the CoAP
payload/content, e.g. using COSE [1]. (We called this object security of
content, OSCON). This is useful if the payload includes certain meta data,
like in the case of CWT, or if certain information, such as resource
identifier etc., is implicit from the security association.

This solution however does not protect the metadata sent in the CoAP
message, such as e.g. Code (GET/DELETE/etc), Uri-Path or Content Format.
Even if such information would be integrity protected, e.g. using
External-AAD in [1], it neither protects messages which do not have
payload, like e.g. GET requests, nor does it address confidentiality
desirable for a subset of such metadata for privacy reasons.

An alternative solution on top of CoAP is to move the RESTful protocol out
of CoAP and only use POST with some dummy Uri-Path, Content Format etc. In
this way all messages could carry a protected object as in [1] and the
nature of the interaction and content is contained in this object. This is
probably violating the purpose of CoAP too much to be of any interest.

Those are the only solutions we have considered on top of CoAP. I'm not
sure if the solution you propose is related to one of these?

All other solutions I'm aware of which address the general problem space,
e.g. OSCOAP, are built "within" CoAP, using CoAP options to carry
protected objects (such as [1]) which include integrity protection of the
payload and meta-data. Now, what happens if the payload is large? If the
originating endpoint does the fragmentation then the destination endpoint
can verify the integrity. If a proxy using the blockwise draft
(re-)fragments the payload (which also changes a Block option) such that
it is different when reaching the destination endpoint, then integrity
verification will fail. The destination endpoint cannot distinguish a
legitimate introduction/change of payload and Block option from any other
change of the message, hence it cannot verify integrity. This can be used
to disable integrity protection at CoAP layer also for shorter messages,
since the destination endpoint must treat the existence of a Block option
as a generic "security off" button.

This is quite different from the CoAP options standardized so far where
you can protect individual messages between client and server at the same
time as allowing legitimate proxy operation, even verifying that
intermediate nodes has performed the correct CoAP option manipulations
such as e.g. when forward proxies change the Uri-* options making the
message reach the correct destination URI.

IMHO CoAP should not allow an intermediate device to legitimately turn off
integrity protecting between client and server. CoAP should definitely
support integrity protection of short messages between client and server
through proxies. This is where CoAP shines brightly. Given that, it is
straightforward to integrity protect messages fragmented at the endpoints.
And with the Block options integrity protected the entire message built up
of the fragments is automatically protected as well.

Göran

[1] https://tools.ietf.org/html/draft-ietf-cose-msg





On 2016-01-29 00:18, "Jim Schaad" <ietf(_at_)augustcellars(_dot_)com> wrote:

Göran,

I finally got caught up on reading the CORE mailing list (lots of boredom
on issues I don’t think I care about) and I did not find any responses to
your mail on this issue.  I would like to propose a different solution to
the problem which I think you will find both workable and potential not
requiring any updates to the current draft.

When I read this draft the first time, I read it as a network
fragmentation draft rather than as a messaging draft.  As such I did not
have the same concerns about object security as you seem to have.  I made
the decision that I would apply the security to the entirety of the
message being sent, and then fragment it into blocks afterwards.  Such an
approach allows for a number of things that you are having problems with
to be ignored.

How the fragmentation is done, is change or is removed become immaterial
as the end recipient would need to have all of the fragments delivered
and in the correct order in order to process the message and do
validation.

Overhead is smaller because the overhead of encrypting/signing at the
object security level is done once rather than once per fragment.  This
allows for fewer bytes to be sent across the wire.

The headers of the first message in the fragment are the ones that the
object security system would be using both for security calculation
purposes and for the receiver to process the validated message.

There are still some question that potentially need to be dealt with:

1) Are the block option headers authenticated?  The probable answer
should be no as they are designed to be changed by intermediaries.  This
can be deferred until the general discussion about the rest of the
current headers.

2) What options are required to be copied forward into subsequent
messages and which can be omitted?  I was unable to find any guidance on
this issue from reading the document and thus would naively make the
assumption that all options not specified by this document are copied
forward and should be checked to make sure that they are unchanged in
future messages.  However I doubt that is the desire of the authors.
This however is not a security specific issue and needs to be addressed
in this document.

3) Do we want to apply per message security as well - that is an issue
that can and should be punted to a future object security draft.
However, I don't see the point except to protect the ACK/NACK or lack of
on each individual hop.  But this is point-to-point not end-to-end.

Jim



-----Original Message-----
From: core [mailto:core-bounces(_at_)ietf(_dot_)org] On Behalf Of Göran 
Selander
Sent: Wednesday, November 25, 2015 11:07 PM
To: ietf(_at_)ietf(_dot_)org
Cc: draft-ietf-core-block(_at_)ietf(_dot_)org; 
core-chairs(_at_)ietf(_dot_)org; core(_at_)ietf(_dot_)org;
barryleiba(_at_)gmail(_dot_)com
Subject: Re: [core] Last Call: <draft-ietf-core-block-18.txt>
(Block-wise transfers
in CoAP) to Proposed Standard



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.



_______________________________________________
core mailing list
core(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/core