Subject: [core] Review of draft-hartke-core-e2e-security-reqs-01

From: Jim Schaad <[email-masked]>
Date: Tue, 2 Aug 2016 15:00:40 -0700

Before anything else, let me re-iterate what I said at the F2F meeting.
This document is so much clearer and easier to read than was the -00 version
that it does not even appear to be the same document.   I want to really
thank you for the work you did in re-writing it.

That being said, I still do have some comments on draft that I would like to
you consider.

Jim

1.  Note that the title of the COSE document has changed you should pick
that up.

2. Section 2.1.1 - Should "client receives a response" include 

    * (Threat ?) The proxy returns a stale or outdated response based on
data it previously obtained from the origin server or some fourth party.

               I'm thinking of both out of date caches and poisoned caches.
Note that these are valid from a security point of view, but not 'fresh'

3.  Section 2.1.1.3 - based on a brief look at mattsson-core-coap-actuators,
it appears to have some solutions to the Withholding attack as well as the
Delaying attack.  This should probably be noted.

4.  Section 2.1.1.5 - It is not clear to me that there is a requirement that
all messages be protected from eavesdropping.  It might just be the way
things are stated here, but there is a difference between the fact that the
solution must provide a method to deal with this and the fact that integrity
protection might be sufficient in some cases.  This would also influence the
analysis below in some cases.

5.  Section 2.1.1.5 - You need to have a better statement of what it means
to provide forward secrecy.  This requirement would appear to potentially
rule out the use of the same session content encryption key for multiple
messages.  I do not believe that is true, but given that we are looking a
message based security some people might think this is the case.  I would
expand this statement to define the conditions under which PFS must be
provided.

6. Section 2.1.2 - Do you consider a proxy re-ordering requests to be a
threat?

7.  Section 2.1.2.1 - Next to last para.  I am not sure that 'involve' is
the correct word in this sentence.  Perhaps you meant 'include'

8.  Section 3 - when I look at figure 10, I keep feeling that it is not a
complete picture of what you need to be looking at 

                   Security Assn         Security Assn

               +-----------------+     +---------------+

               |                 |     |               |

           ____________        __________         ___________

           |            |      |          |       |           |

           |            |----->|          |<------|           |

           | Subscriber |      |  Broker  |       | Publisher |

           |            |<-----|          |------>|           |

           |____________|      |__________|       |___________|

                 :                                      :

                 '--------------------------------------'

                           Security Association

There needs to be a discussion of all of the different potential security
associations in this diagram.  Some of these can be reduced to simple
client-server associations, but some of the implications of this diagram are
potentially used for the entirety of the picture.

Examples of things that can be looked at:

a)      The broker is the one that will do enforcement of access control.
If this is not true then all subscription requests would really need to be
passed onto the publisher to ensure that the subscriber is to have access.
And we now have  new thread of the broker granting access to a subscription
stream when it should not.

b)     The broker may validate that messages from the publisher are in fact
from the publisher, but be unable to look at the content of the message.

c)      The broker may need to have some details of the SA between the
subscriber and the publisher.   For example, what happens if the key used to
encrypt/protect the message gets updated or if the publisher is generating
the same stream but using two different group keys.  In the first, is this
an issue for the client or for the broker.  In the second case there are
effectively two different streams with the same name that need to be
identified by the broker and the correct responses sent to the client.

These are examples of what I meant in the F2F when I said that you have a
semi-trusted broker.  It is trusted with information about the subscription
stream and allowed to enforce it.  But it is not allowed to have access to
the actual content of the stream.

9.  Threats in section 3 also include 

  * out of order delivery of items.   

  * Issues about a broker either granting or denying access to a stream.

  * Subscriber does not receive a response because the broker pre-maturely
unsubscribes the subscriber

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 3 Aug 2016 17:22:53 +0200

Hi Jim,

thanks a lot for your review. Comments inline below.

Klaus

> 1.  Note that the title of the COSE document has changed you should pick

Fixed.

> Note that these are valid from a security point of view, but not 'fresh'

This is a part of (Threat 1:) The proxy spoofs a response.

In the mitigation section (2.1.1.1.) we define that a response is
valid from a security point of view only if it is fresh.

(We use the term "authentic" instead of "valid" though, because
"valid" is already used in the context of cache validation.)

I've expanded the text with your suggestion:

      *  (Threat 1:) The proxy spoofs a response.  For example, the
         proxy could return a stale or outdated response based on data
         it previously obtained from the server or some fourth party, or
         could craft an illicit response itself.

> Delaying attack.  This should probably be noted.

I've opened an issue on GitHub for this:

https://github.com/ektrah/coap-object-security/issues/5

> analysis below in some cases.

Currently the text is written with the assumption that it is a
requirement that all messages are protected from eavesdropping.

However, as Carsten mentioned at the F2F meeting, there may indeed be
use cases where it's desirable that the proxy can eavesdrop on the
messages.

We will clarify this in the draft.

https://github.com/ektrah/coap-object-security/issues/6

> expand this statement to define the conditions under which PFS must be

https://github.com/ektrah/coap-object-security/issues/7

> 6. Section 2.1.2 - Do you consider a proxy re-ordering requests to be a

No. If a client wants to ensure that a request is processed after
another request, it needs to wait for the response to the first
request before it makes the second request.

> the correct word in this sentence.  Perhaps you meant 'include'

Fixed.

> [...]
> [...]

https://github.com/ektrah/coap-object-security/issues/8

> unsubscribes the subscriber

https://github.com/ektrah/coap-object-security/issues/9

---

From: Jim Schaad <[email-masked]>
Date: Wed, 3 Aug 2016 09:44:21 -0700

> -----Original Message-----
> From: Klaus Hartke [mailto:[email-masked]]
> Sent: Wednesday, August 03, 2016 8:23 AM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]; [email-masked] WG
> <[email-masked]>
> Subject: Re: [core] Review of draft-hartke-core-e2e-security-reqs-01
> 
> Hi Jim,
> 
> >     * (Threat ?) The proxy returns a stale or outdated response based
> > on data it previously obtained from the origin server or some fourth party.
> >
> In the mitigation section (2.1.1.1.) we define that a response is valid from a
> security point of view only if it is fresh.
> 
> (We use the term "authentic" instead of "valid" though, because "valid" is
> already used in the context of cache validation.)
> 

My problem with this is that I view a spoof as different.  To me a spoof implies the attempt to create a new message that will pass muster as oppose to doing something like a replay.  It would probably be better to use a different term.  I'll try and remember to ponder on this.

Jim