Re: [core] Eric Rescorla's Discuss on draft-ietf-core-object-security-09: (with DISCUSS and COMMENT)

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

From: Eric Rescorla <[e-mail]<mailto:[e-mail]>>
Date: Thursday 8 March 2018 at 16:06
To: Göran Selander <[e-mail]<mailto:[e-mail]>>
Cc: The IESG <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Carsten Bormann <[e-mail]<mailto:[e-mail]>>, Jaime Jiménez <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: Eric Rescorla's Discuss on draft-ietf-core-object-security-09: (with DISCUSS and COMMENT)



On Thu, Mar 8, 2018 at 6:59 AM, Göran Selander <[e-mail]<mailto:[e-mail]>> wrote:
Another recurring comment is the impact of a proxy changing certain CoAP
message fields like e.g. Message ID, Token or Uri-Host. Since CoAP defines
legitimate proxy operations, these message fields cannot be integrity
protected end-to-end. Current security solutions either does not allow
proxy operations or leave all message fields unprotected in the proxy. We
will try to make this more clear.

The question is what the security impact of these is.

Yes, and we will try to address this. But it is a general property of CoAP when proxies are used.



A third thing in Eric’s review is the construction of the nonce where the
ID is included. The reason for this is to handle endpoints switching roles
(CoAP client <-> CoAP server)  which is supported by CoAP, and in
particular
group communications with one sender and multiple recipients

I don't see how that is relevant, given that you already have key separation
for the sender key, what separate information is there in the nonce?

The sender key is used both in the role of client making a request (with own partial IV) and in the role of server responding to a request (with the other endpoint’s partial IV).

Göran


-Ekr


. While the
latter is the topic of a separate draft
(draft-tiloca-core-multicast-oscoap) and the properties in that setting is
out of scope of this draft, we will add more explanation to the security
design and the unicast security properties in general to this draft.


More later.

Göran




On 2018-03-08 03:58, "Eric Rescorla" <[e-mail]<mailto:[e-mail]>> wrote:

>Eric Rescorla has entered the following ballot position for
>draft-ietf-core-object-security-09: Discuss
>
>When responding, please keep the subject line intact and reply to all
>email addresses included in the To and CC lines. (Feel free to cut this
>introductory paragraph, however.)
>
>
>Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>for more information about IESG DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-core-object-security/
>
>
>
>----------------------------------------------------------------------
>DISCUSS:
>----------------------------------------------------------------------
>
>https://mozphab-ietf.devsvcdev.mozaws.net/D3075
>
>DISCUSS
>My overall concern with this document is that I am unable to evaluate
>the security properties of the system. I have described a number of
>issues below, but the basic problem is that this sort of partial
>protection is extremely hard to reason about and the security
>considerations do not do an adequate job of evaluating the impact of
>proxies modifying these values. I am similarly concerned about the
>HTTP mapping and link section which seems extremely sketchy and has
>essentially no security analysis, and yet potentially have a lot
>of landmines.
>
>At minimum, this document needs to walk through the implications
>of modifications by the proxy to every unprotected field in
>the pure CoAP context as well as the HTTP context (if you want
>to retain that binding).
>
>   are given in Appendix A.  OSCORE does not depend on underlying
>   layers, and can be used anywhere where CoAP or HTTP can be used,
>   including non-IP transports (e.g., [I-D.bormann-6lo-coap-802-15-ie]).
>
>IMPORTANT: This document claims to be applicable to protocols other
>than COAP, in particular HTTP. Has this been reviewed by the HTTP
>working group? Martin Thomson's review suggests that this is out of
>step with HTTP practice.
>
>   IDs MUST be long uniformly random distributed byte strings such that
>   the probability of collisions is negligible.
>
>IMPORTANT: I don't understand how this paragraph and the previous
>paragraph interact. You say that the maximum length is 7 octets in the
>previous paragraph, which I don't think qualifies as "long".
>
>                     |   1 | If-Match        | x |   |
>                     |   3 | Uri-Host        |   | x |
>                     |   4 | ETag            | x |   |
>IMPORTANT: Why do you think that it's not important to have integrity
>protection for Uri-Host and Uri-port?
>
>   Outer option message fields (Class U or I) are used to support proxy
>   operations.
>IMPORTANT: This seems problematic because the proxy cannot verify class I
>fields.
>
>   layer only, and not the Messaging Layer (Section 2 of [RFC7252]), so
>   fields such as Type and Message ID are not protected with OSCORE.
>
>IMPORTANT: This seems extremely hard to reason about. What are the
>implications of the proxy being able to change these?
>
>   o  request_piv: contains the value of the 'Partial IV' in the COSE
>      object of the request (see Section 5).
>
>IMPORTANT: I think what I am getting here is that the request_piv is
>used to verify that the request and response match. However, I do not
>see this explicitly stated anywhere, and it's not clear to me how the
>client is supposed to recover the request_piv and the text is pretty
>unclear here? Is the external_aad carried somewhere in the message? Am
>I supposed to reconstruct it from the message id?
>
>   For responses, the message binding guarantees that a response is not
>   older than its request.  For responses without Observe, this gives
>
>IMPORTANT: I am not sure that this is true. What happens of the
>counterparty lies? What is your threat model?
>
>   An extension of OSCORE may also be used to protect group
>   communication for CoAP [I-D.tiloca-core-multicast-oscoap].  The use
>   of OSCORE does not affect the URI scheme and OSCORE can therefore be
>   used with any URI scheme defined for CoAP or HTTP.  The application
>   decides the conditions for which OSCORE is required.
>
>This is pretty surprising to just drop in here. Multicast has totally
>different
>security properties from non-multicast.
>
>
>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>
>
>   but is also able to eavesdrop on, or manipulate any part of the
>   message payload and metadata, in transit between the endpoints.  The
>   proxy can also inject, delete, or reorder packets since they are no
>Nit: you want
>"eavesdrop on, or manipulate any part of, the message payload and
>metadata in
>transit"
>
>I.e., move the second comma
>
>   the endpoints, and those are therefore processed as defined in
>   [RFC7252].  Additionally, since the message formats for CoAP over
>   unreliable transport [RFC7252] and for CoAP over reliable transport
>Nit: "OSCORE protects neither .... nor...."
>
>      Salt.  Length is determined by the AEAD Algorithm.  Its value is
>>      immutable once the security context is established.
>Nit: you might just say above or below this list that all the values are
>immutable,
>
>   different operations.  One mechanism enabling this is specified in
>   [I-D.ietf-core-echo-request-tag].
>Is this a security condition?
>
>      of [RFC7252], where the delta is the difference to the previously
>      included class I option.
>Is the delta here the previously included Class I option or the previously
>included instance of the same option, as it appears to say in S 3.1.
>
>         compressed COSE object.  The values n = 6 and n = 7 are
>         reserved.
>How can Partial IV not be present? it's the sequence number. Is the
>answer that
>it is the 0 value?
>
>   response.  The server therefore needs to store the kid and Partial IV
>   of the request until all responses have been sent.
>It was my understanding that the kid was needed to look up the key. Why
>are kid
>substitution attacks an issue?
>
>   The maximum Sender Sequence Number is algorithm dependent (see
>   Section 11), and no greater than 2^40 - 1.  If the Sender Sequence
>   Number exceeds the maximum, the endpoint MUST NOT process any more
>If you take my suggestion about removing senderID from the nonce you will
>be
>able to relax this.
>
>   After boot, an endpoint MAY reject to use existing security contexts
>   from before it booted and MAY establish a new security context with
>Nit: this is ungrammatical
>
>       included in the message.  If the AEAD nonce from the request was
>       used, the Partial IV MUST NOT be included in the message.
>IMPORTANT: You are now violating the invariant of using the same nonce
>twice.
>That's fine in this case, because you have per-sender keys but it
>demonstrates
>that it is unnecessary to encode the sender_id in the nonce field.
>
>   Security level here means that an attacker can recover one of the m
>   keys with complexity 2^(k + n) / m.  Protection against such attacks
>   can be provided by increasing the size of the keys or the entropy of
>This paragraph is extremely hard to follow but I am not persuaded that it
>is
>correct. Do you have a citation for the claim that you can add the key
>entropy
>and the nonce entropy like this.
>
>   style of padding means that all values need to be padded.  Similar
>   arguments apply to other message fields such as resource names.
>The PKCS#7 padding scheme at minimum has potential timing channels
>
>   The server verifies that the Partial IV has not been received before.
>   The client verifies that the response is bound to the request.
>How does the client verify this
>
>       Partial IV (in network byte order) with zeroes to exactly nonce
>       length - 6 bytes,
>
>IMPORTANT: I don't understand the reason for this construction. You
>already require that the key be derived via HKDF from the |master key|
>and |sender ID| therefore, it is not necessarily to separately encode
>the sender ID in the nonce. This would ordinarily not be a large
>issue, but as it requires very extreme restrictions on the sender ID
>(and essentially precludes random sender IDs) I believe it is worth
>considering changing, but it's ultimately a WG decision, hence not
>in my discuss.
>
>