|
RE: [core] Last Call: <draft-ietf-core-block-18.txt> (Block-wise transfers in CoAP) to Proposed Standard
2016-02-01 16:56:10
Göran,
It I always more helpful to be on the same page.
See below
-----Original Message-----
From: Göran Selander [mailto:goran(_dot_)selander(_at_)ericsson(_dot_)com]
Sent: Monday, February 01, 2016 1:55 PM
To: Jim Schaad <ietf(_at_)augustcellars(_dot_)com>; 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
Jim,
Yes, apparently we do talk past each other. Inline.
On 2016-02-01 21:28, "Jim Schaad" <ietf(_at_)augustcellars(_dot_)com> wrote:
Göran,
You apparently have missed the main point of what I was saying in my
message.
I see both of these cases as having a single message to be protected:
1. I am sending a small message that does not get fragmented 2. I am
sending a large message that needs to be fragmented into 5 messages
using the Block-wise transfer options.
In both cases I am doing an integrity protection/encryption operation
on a single message that might later be fragmented into multiple pieces.
I don’t understand how your solution protects CoAP metadata like Code,
Content-Format and Uri-Path. I may be wrong but it seems you are only
protecting CoAP payload, which is sufficient for certain use cases, but for
other
use cases we also need to protect metadata. The blockwise draft applies to
both
kind of use cases.
Remember that I am looking at dealing with this as a single message. There is
going to be a solution for using COSE with CoAP that is protecting the headers
in a single message. I am assuming that this is the same solution that needs
to be used for dealing with the fragmented message as well. The set of options
from the fragmented message is built into an external object which is then
authenticated as part of the process of authenticating the base block.
This is where the current BLOCK draft falls apart on its own merits. It does
not discuss what should happen if the set of options is not the same between
all of the blocks. This is a problem if one is using security or not. The
correct set of headers is the set that needs to be protected, but there is no
way to determine what the set of headers is supposed to be.
I do not want to integrity protect each of the 5 block transfer
messages independently because of a number of problems which you have
pointed out about messages getting re-fragmented in transit.
My point of view is that messages should not be re-fragmented in transit.
Why do you believe that this is a problem? I cannot see any problems with it
myself.
Additionally, I do not want to deal with each messages separately
because I do not want to be in a situation where a block could be
changed for a different block from a different stream.
This is not an issue if you integrity protect the appropriate Block option,
which
contains the number of the block and if it is the last.
Re-fragmentation prevents Block options from being possible to integrity
protect between client and server.
That is insufficient to provide the protection. In addition you would need to
be able to protect some value which says that all of these are from a single
fragmented message as well. This means that one would need to ensure that this
value is not reused under some set of constraints. What happens if I received
a block 4 of 5 from server A and a block 4 of 5 from server B. The block
values are going to be correct, but they are from different streams. So
protecting what stream they are from is needed as well as making sure that
there is some value which to protect from different streams from the same
server. (Ok - I just found another thing that I need to make sure that the
BLOCK draft supports correctly.)
This would be the case of sending A1 A2 A3 A4 and receiving A1 A2 B3 A4
where each of the fragments individually verifies, but the entire
stream has been changed. Doing a single integrity operation over the
entire stream of (A1 A2 A3 A4) means that receiving (A1 A2 B3 A4) would
fail to validate because the entire stream of bytes would fail validation.
This is not an issue if you integrity protect the appropriate Block option.
Not that the block option is the same for both A3 and B3.
NUM = 3, M = no, SZX=1K
This means that I treat security identically if the block options are
there or if the block options are not there.
Yes, since you focus on an over-the-top solution you can do that. But the only
over-the-top solution I know of that protects metadata is the one mentioned
below which moves REST out of CoAP.
There are other discussions that need to be dealt with about options
and how they interact with security, but the report of the group
working on this has not yet come up for review. I am just worried about
getting this draft finished.
And I’m worried that this draft voids the candidate solutions for protecting
payload and metadata.
There I cannot help as I have not seen anything yet.
Jim
Göran
jim
-----Original Message-----
From: Göran Selander [mailto:goran(_dot_)selander(_at_)ericsson(_dot_)com]
Sent: Monday, February 01, 2016 12:20 AM
To: Jim Schaad <ietf(_at_)augustcellars(_dot_)com>;
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
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
|
|