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

[Likepeng <[e-mail]>]

Hi Corinna,

Please find my personal feedback to your draft:

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”.

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/

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.

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/

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?

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.

Thanks,

Kind Regards
Kepeng (Individual)

发件人: 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

--
[cid:image001.png@01CF99D4.176EFD60]