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

[Hannes Tschofenig <[e-mail]>]

Hi Corinna,

thanks for the response.

My suggestion would be to produce a write-up that is of generic use
(independent from your specific implementation and your EU funded project).

However, given the charter discussions and the BOF I have my doubts
whether the work would meet many of the requirements outlined in
https://tools.ietf.org/html/draft-seitz-ace-usecases-00.

Ciao
Hannes

On 03/02/2014 04:29 PM, Dr. Corinna Schmitt wrote:
> 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
> 
> 
> 
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace
>