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

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

Dear Kepeng,

thanks for the feedback. Some of them we already applied in the updated 
version: draft-schmitt-ace-twowayauth-for-iot-00 
<https://datatracker.ietf.org/doc/draft-schmitt-ace-twowayauth-for-iot/>
This draft replaces the one you refer to.

> Section 2, Terminology: Currently, our charter and most of the other 
> submitted drafts use "Client", "Resource Server", "Authorization 
> Server". To keep consistency, it is better to use these terminologies 
> to replace "Publisher", "Subscriber" and "Access Control Server".
>
We will change it in one of the next updates when it is clear for us how 
to map it.
>
> Section 3, High Level Design Requirements: the objective of this 
> section is quite similar to the "design considerations" draft. It is 
> better to consolidate this section with the draft.
>
> http://datatracker.ietf.org/doc/draft-seitz-ace-design-considerations/
>
Thanks for the hint.
>
> Section 4, It seems that that most of the design considerations (e.g. 
> assumed network stack, handshake message flows) will also be applied 
> for Class 1 devices. It is better to indicate the common design 
> considerations first, then highlight what more we can achieve by Class 
> 2 devices.
>
We already included this. Deleting our TPM request and argument with 
class 1 and 2 now.
>
> Section 5.1, 5.2 and 6, Use cases and Requirements: Maybe it is better 
> to consolidate these sections with the "Use cases and requirements" draft:
>
> http://datatracker.ietf.org/doc/draft-seitz-ace-usecases/
>
Thanks for the hint. The use-case we have in those sections are coming 
from the draft already. The requirements are based on the things we need.
>
> Section 5.3, Data Access Procedures: it seems that interactions 
> between Gateway and Publisher are out of scope? Because from the 
> flows, the Gateway is not involved in the data access flow any more. 
> Also about the last two steps "Two-way authentication handshake 
> between Subscriber and Publisher" and "Data exchange using DTLS 
> secured channel", in these two steps, is "Access Control Server" 
> involved in the data access flow?
>
We will check it and let you know. Sometimes the Gateway might be involved.
>
> Section 10, Formal Syntax: It is better to put this section as a 
> sub-section of Section 2, to let readers better understand the meaning 
> of the abbreviations.
>
Also a good idea.
>
Thanks and see you in Toronto,
Corinna
>
> *? ??:*Ace [mailto:[e-mail]] *? ? *Corinna Schmitt
> *? ???:*2014?6?30?16:32
> *???:*[e-mail]; Hannes Tschofenig
> *??:*Burkhard Stiller
> *??:*Re: [Ace] draft-schmitt-two-way-authentication-for-iot-02
>
> Dear Hannes,
>
> based on the discussions of the pre-meeting in Stockholm we updated 
> our draft and generalized it. Our old draft 
> "draft-schmitt-two-way-authentication-for-iot" is now replaced by 
> "draft-schmitt-ace-twowayauth-for-iot".
>
> The mentioned projects are only examples where we have the work 
> integrated and where it runs already successful.
> So we believe the draft fits into ACE and also maps the requirements 
> outlined in https://tools.ietf.org/html/draft-seitz-ace-usecases-00.
>
> See you in Toronto at IETF 90,
> Corinna
>
> Am 11.03.14 20:18, schrieb Hannes Tschofenig:
>
>     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>  <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  <http://www.smartenit.eu>) and Flamingo (http://www.fp7-flamingo.eu).
>
>         <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]  <mailto:[e-mail]>
>
>         https://www.ietf.org/mailman/listinfo/ace
>
>           
>
>       
>
>
>
>
>     _______________________________________________
>
>     Ace mailing list
>
>     [e-mail]  <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/ace
>
> -- 
>
>
>
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace


--