Re: [Ace] draft-schmitt-two-way-authentication-for-iot-02

["Dr. Corinna Schmitt" <[e-mail]>]

Dear Hannes,
> Hi Corinna, Hi Burkhard,
>
> thanks for your document. I have read through it and I ran into a few
> questions. Your response would help me to better understand the proposed
> idea.
Thanks for reading the draft and make comments to it to improve it. Some 
comments can be answered right away.
> 1) Why do you assume IEEE 802.15.4? Currently it seems that the 15.4
> radio will mostly be used in specialized industry segments only. Is
> there anything in the document that would make the idea less suitable
> for other radio technologies, for example BTLE?
Potentially the proposed solution can work on every stack you like. So 
you can do an implementation independently of IEEE 802.15.4.
We put IEEE 802.15.4 there, because our used stack (BLIP) uses it.
> 2) The assumed network stack does not show 6lowpan. Was this intentional?
Same as above. You can use the stack you want. So also 6lowpan can be 
used. It depends n you what you require and what you want to support.
> 3) You show RPL in the stack and I was wondering whether you assume it
> being mandatory to implement for your assumed architecture? It does not
> seem to show up elsewhere in the document. It appears to be irrelevant
> for your design.
RPL was just mentioned due to our other publications. Currently our plan 
is to change to RPL (CoAP) in the future.
> 4) Subscriber identity: You write --
> "
>     The identity of a default subscriber is usually preconfigured on a
>     publisher before it is deployed.
> "
>
> Could you explain more what you assume is pre-configured and where it is
> preconfigured?
Here pre-configures means that our devices are equipped with the 
certification during compiling and programming them before deployment.
This is due to the application scenario we support at the moment. Before 
deploying the device you have to run to steps: First creation of 
certificate, and second compiling code and play it on the device.
> I would also suggest to avoid the term subscriber since it has two other
> meanings that might confuse:
>   a) The term subscriber is often used in context of telecommunication as
> the user who has a contract with a telecommunication operator.
>   b) The second use is in context of protocols that use asynchronous
> communication (like XMPP).
>
> I believe your notion of subscriber does not relate to those two
> existing uses. I guess you are more using the term subscriber to refer
> to a device that wants some data from a sensor. Is this correct?
Thanks for the hint. Yes you are right. The subscriber should be a 
device that wants data from the sensor.
Usually this is one outside of the WSN. Do you have a suggestion for new 
name?
> 5) Roles in your architecture.
>
> It seems that you assume that the IoT devices are publishers and that
> there are subscribers who talk to these publishers. In some other cases
> I have seen architectures where the IoT devices (sensors) upload the
> data to some servers without having to act as servers themselves. In
> your architecture it feels like the sensor nodes implement the
> server-side functionality
That was not our intention.
Our network has push characteristics up to the server. Data publishing 
runs over server, because it has more resources and, therefore, can 
handle requests better. It is the gate to the world.
Pull is only performed if you require data (measurements) at a time that 
is not pre-defined.
> In Section 4.2.2 you write that you recommend an OpenSSL implementation
> on the server side but the server-side would be the IoT device. While it
> would be inappropriate to recommend a specific implementation in an IETF
> draft/RFC it also raises the questions about the expectations on the
> server-side.
Thanks for the hint.
We use OpenSSL on the server but not within the WSN. OpenSSL is used 
especially for managing rights, requests, and certificates.
> 6. Certificate content
>
> In Section 4.2.2 you describe the content of a certificate and you
> indicate that the commonName is set to "localhost". It seems to be
> useless to include this in the certificate since a CA would not be able
> to verify this identity information nor would any party verifying it be
> able to use it in a meaningful way.
Localhost in our case is a special IP address (here: sink). You are 
right, we should rename it and make clear that it is an IP address. So 
you can set is like you want.
> It also seems to be in violation of what you write in Section 5.2 where
> you state that "every publisher in the network MUST have an unique
> identity.".
>
> You also indicated more complete information for inclusion in the
> certificate but it is not clear to me what purpose it serves. Could you
> explain?
Will do it asap.
> 7. Privacy
>
> In Section 5 you indicate some privacy related aspects and you hint to "
> access regulations based on legal and regulative implications". Could
> you briefly explain what those requirements are?
This part we put in due to the deployment and project relations we are 
running at the moment.
Here it means that not every device can be able to access the data, for 
example, due to legal issues in the region (EU, CH, US rights).
This has to be stored central in the network and it has to be checked 
before giving access and creating the corresponding access ticket.
Here we refer to the following publications:

Radhika Garg, Corinna Schmitt, Burkhard Stiller: /Investigating 
Regulative Implications for User-generated Content and a Design 
Proposal/; Degruyter, PIK-Praxis der Informationsverarbeitung und 
Kommunikation, Vol. 36, No. 4, December 2013, ISSN 0930-5157, pp 1--11. 
doi:10.1515/pik-2013-0042 <http://dx.doi.org/10.1515/pik-2013-0042> URL: 
http://www.degruyter.com/view/j/piko.ahead-of-print/pik-2013-0042/pik-2013-0042.xml

Radhika Garg, Christos Tsiaras, Burkhard Stiller, Corinna Schmitt, 
Daniel Dönni: /Deliverable D7.1 - Basics, Requirements, Scenarios, and 
Architecture: In FLAMINGO/; Radhika Garg (Edt.), Zürich, Switzerland, 
October 2013
> 8. Use Cases.
>
> I suggest to omit the use cases from the document since the description
> is too brief to be useful. A small remark: From my work in the emergency
> services environment I had gotten the impression that there are no plans
> to take sensor input directly when initiating alerts. In fact, sensor
> alerts do rarely even get directly to the emergency services authorities
> but are rather pre-processed by an intermediate organization (by
> humans). Maybe you have spoken with other people, who have different
> plans. Where did you got your information from?
This section is based on discussion with our project partners within 
SmartenIT (www.smartenit.eu) and Flamingo ( http://www.fp7-flamingo.eu). 
<http://www.fp7-flamingo.eu>

> 9. Architecture
>
> Figure 3 shows the architecture but it is a bit confusing since it is
> not clear what the boxes and the lines mean. The publisher is a box
> separate from the sensors and from the earlier description I thought
> that the sensors are actually the publishers. Furthermore, the gateway
> was not discussed as a role up to that point in the document. The
> gateway shows up in Section 5.3 and its role confuses me. You write:
>
> "  A sensor node has published its data, which is transmitted in
>     direction to the global sink (cf. Figure 3 where global sink is
>     located in the gateway component).
> "
>
> Does the sensor publish the data at the gateway? From the earlier
> sections I thought that the subscriber talks to the publisher instead.
> Is the gateway the subscriber? Why doesn't the sensor uploads the data
> to some server instead (which is frequently done in today's IoT
> deployments).
Lots of comments.
I will address and clarify them asap.
Furthermore, I will add a legend to the Figure and perhaps modify it 
based on you aforementioned comments.
> Why do you call the entire document "two-way authentication" when the
> the two way authentication is just one small part of the overall
> authentication procedure. In fact the two-way authentication is used
> between the subscriber and the access control server (as shown in Figure
> 4), and between the publisher and the gateway. Furthermore, there has to
> be some authentication between the subscriber and the publisher as well
> (at least I hope so).
>
> What is the purpose of the access ticket? It shows up in Section 5.3 and
> I wonder why there is a need for an access ticket when the two parties
> (subscriber and publisher) already have a certificate. Why cannot you
> use the certificate for authentication with the publisher right away?
>
> Where do you see the access control server being deployed? Is this an
> entity in the local network or something you would have on the Internet?
>
> Why does the publisher have to authenticate to the gateway? From Figure
> 4 it is not clear whether the gateway is just an optional component or
> an integral part of the architecture.
>
> The document does not explain what the access token is and how it is
> exchanged between the subscriber and the publisher.
>
> Btw, the term CA standards for Certification Authority rather than
> Certificate Authority.

Will be addressed soon.
> 10. Hardware requirements.
>
> Hardware requirements typically are not appropriate for IETF documents.
> While you make the argument that an RSA-based public key cryptosystem is
> good enough from a performance point of view the currently mandatory
> ciphersuites used in CoAP are based on ECC (for those that rely on
> asymmetric crypto). While having hardware support for key storage is a
> great idea I was wondering how much your architecture actually relies on
> it. My impression that it would work fine just without a TPM chip. But
> you might have more hardware experience than I have. Could you point me
> to some hardware that you have in mind using?
>
We put this section for completeness and to show that an implementation 
exists.
Concerning sensor nodes and TPM we are using OPAL from CSIRO. Trusting 
Computing becomes relevant nowadays when thinking about securing data. 
Drawback is that if the TPM chip is broken or you change something 
during booting everything is lost. Advantage is that the storage root 
key is stored safely and only derivates are used for your applications.

Hope to answer most important questions or comments now. Others will be 
addressed soon.
You can also talk to me during IETF in London.

Regards,
Corinna