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

[Hannes Tschofenig <[e-mail]>]

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.

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?

2) The assumed network stack does not show 6lowpan. Was this intentional?

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.

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?

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?

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

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.

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.


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?

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?

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?

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

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.

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?

Ciao
Hannes