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

[Jim Schaad <[e-mail]>]

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