Subject: [Dtls-iot] Making progress on the constrained server topic

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 12 Dec 2014 11:33:05 +0100

Hi all,

as I am preparing another draft update of the profile draft (see
https://github.com/hannestschofenig/tschofenig-ids/blob/master/dice-profile/draft-ietf-dice-profile-07.txt)
I re-read the current write-up and thought about the necessary changes
to support a constrained server implementation, i.e., an IoT device that
runs a constrained server. It turns out that the changes on the surface
are actually fairly small. Here is the list of impacted sections.

Changes required:

 - Use Session Resumption without server-side state (rather than session
resumption) to push state information to clients.
 - Server Name Indication (SNI) since it is less likely to be used on a
constrained server.
 - Random Number Generation because of the reference to
[I-D.mathewson-no-gmtunixtime]. (small change).

No change:

 - Perfect Forward Secrecy
 - Keep-Alive
 - Timeouts
 - Truncated MAC and Encrypt-then-MAC Extension
 - Maximum Fragment Length Negotiation
 - Session Hash
 - Re-Negotiation Attacks
 - Downgrading Attacks
 - Crypto Agility
 - Key Length Recommendations
 - False Start

The challenges do, however, start when it comes to the assumptions
behind made by the current text. As the text is currently written, the
assumption is that there is a very close relationship between the
constrained client and the server (which is sitting somewhere in the
cloud). This is a quite realistic usage model since this is what we are
seeing today with many deployments where the device maker also provides
the corresponding server-side infrastructure.

This gives the vendor a lot of freedom with regard to the use of the
credentials and also to implement a software update mechanism the device
can use to deal with functionality like revocation and trust anchor
provisioning.

There is also no problem with discovery (since we assume that the
information about the server is pre-configured). There is also not
problem with reachability since the client starts the communication
exchange.

Now, as we move to a different design pattern, such as the
device-to-device communication model these assumptions suddenly do not
work anymore. It turns out that the differentiation between constrained
server vs. constrained client isn't all that relevant; what is relevant
is the relationship between the different devices and what information
can (or cannot) realistically assumed to be present.

Of course, there is no documentation of these different design patterns
(other than the brief write-up in
https://tools.ietf.org/html/draft-iab-smart-object-architecture-06).
There is no place I can point people that contains a detailed description.

In general, there will be the following problems to deal with:

 a) Discovery & Reachability

How does the client learn that it has to talk to a specific server?
How do the entity initiating the communication actually reach the other
end (and how does it maintain that connectivity)?

 b) Authentication

What credentials can be used to authenticate the two parties?

 c) Authorization

How are the two parties going to authorize each other? It is not just
about authorizing the client when it accesses a resource but also about
the client ensuring that it indeed talks to a legitimate server?

Does this sound familiar? I am sure it does. This is essentially the ACE
problem statement. In the current client-to-cloud model all these
problems are sort of "solved" by simply assuming that the cloud service
provider also provisions the IoT device. But in a more open model (which
is, quite naturally, important to have) these questions are then solved
either using pairing (in the very limited case, see description in
Section 1 of
http://tools.ietf.org/html/draft-tschofenig-ace-overview-00) or by
introducing this famous third party (which is the authorization server
in the ACE case).

What does this mean for the draft?

I can cheat a little bit by glancing over the hard problems and just
start with the assumption that the client will somehow get the right
credentials, configuration information, access rights, revocation
information, etc. from somewhere. Hence, this is a pure TLS exchange and
I only need to make the modifications stated at the beginning of my
mail. I could reference the ongoing ACE work, which will at least deal
with the authorization questions. Of course, that write-up in the DICE
draft by itself is not be interoperable as a standalone item.

How does that sound?

Ciao
Hannes

---

From: "Rahman, Akbar" <[email-masked]>
Date: Fri, 12 Dec 2014 18:53:47 +0000

Hi Hannes,

>How does the client learn that it has to talk to a specific server?

If we consider CoAP as the application protocol being run between the IoT device and the constrained server then the answer is clear.  Discovery (of resources and/or servers) is done by sending a unicast or multicast CoAP GET to a well-known URI.  Various aspects of this discovery is explained in multiple RFCs/drafts:

1) The CORE Link format document [RFC 6690] which first described the use case, and reserved the URI:
	- Use Case: http://tools.ietf.org/html/rfc6690#section-1.2.1 
	- Reserving the URI: http://tools.ietf.org/html/rfc6690#section-7.1 

2) The CoAP spec [RFC 7252] also provides a nice summary of the operation:
	- http://tools.ietf.org/html/rfc7252#section-7 

3) The CoAP Group Communications spec [RFC 7390] gives a detailed use case on how to multicast discover CoAP servers, and the protocol processing rules:
	- Use Case:  http://tools.ietf.org/html/rfc7390#section-3.3 
	- Protocol processing (see 5th sub-bullet) : http://tools.ietf.org/html/rfc7390#section-2.7 

So, my opinion is that this issue is well solved at least for the CoAP case.  Do you agre?

>How do the entity initiating the communication actually reach the other end (and how does it maintain that connectivity)?

I think Carsten previously gave a good answer to a similar question:

	- http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00474.html 

Best Regards,

Akbar

-----Original Message-----
From: dtls-iot [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Friday, December 12, 2014 5:33 AM
To: [email-masked]
Subject: [Dtls-iot] Making progress on the constrained server topic

Hi all,

as I am preparing another draft update of the profile draft (see
https://github.com/hannestschofenig/tschofenig-ids/blob/master/dice-profile/draft-ietf-dice-profile-07.txt)
I re-read the current write-up and thought about the necessary changes to support a constrained server implementation, i.e., an IoT device that runs a constrained server. It turns out that the changes on the surface are actually fairly small. Here is the list of impacted sections.

Changes required:

 - Use Session Resumption without server-side state (rather than session
resumption) to push state information to clients.
 - Server Name Indication (SNI) since it is less likely to be used on a constrained server.
 - Random Number Generation because of the reference to [I-D.mathewson-no-gmtunixtime]. (small change).

No change:

The challenges do, however, start when it comes to the assumptions behind made by the current text. As the text is currently written, the assumption is that there is a very close relationship between the constrained client and the server (which is sitting somewhere in the cloud). This is a quite realistic usage model since this is what we are seeing today with many deployments where the device maker also provides the corresponding server-side infrastructure.

This gives the vendor a lot of freedom with regard to the use of the credentials and also to implement a software update mechanism the device can use to deal with functionality like revocation and trust anchor provisioning.

There is also no problem with discovery (since we assume that the information about the server is pre-configured). There is also not problem with reachability since the client starts the communication exchange.

Now, as we move to a different design pattern, such as the device-to-device communication model these assumptions suddenly do not work anymore. It turns out that the differentiation between constrained server vs. constrained client isn't all that relevant; what is relevant is the relationship between the different devices and what information can (or cannot) realistically assumed to be present.

Of course, there is no documentation of these different design patterns (other than the brief write-up in https://tools.ietf.org/html/draft-iab-smart-object-architecture-06).
There is no place I can point people that contains a detailed description.

How does the client learn that it has to talk to a specific server?
How do the entity initiating the communication actually reach the other end (and how does it maintain that connectivity)?

 b) Authentication

 c) Authorization

How are the two parties going to authorize each other? It is not just about authorizing the client when it accesses a resource but also about the client ensuring that it indeed talks to a legitimate server?

Does this sound familiar? I am sure it does. This is essentially the ACE problem statement. In the current client-to-cloud model all these problems are sort of "solved" by simply assuming that the cloud service provider also provisions the IoT device. But in a more open model (which is, quite naturally, important to have) these questions are then solved either using pairing (in the very limited case, see description in Section 1 of
http://tools.ietf.org/html/draft-tschofenig-ace-overview-00) or by introducing this famous third party (which is the authorization server in the ACE case).

I can cheat a little bit by glancing over the hard problems and just start with the assumption that the client will somehow get the right credentials, configuration information, access rights, revocation information, etc. from somewhere. Hence, this is a pure TLS exchange and I only need to make the modifications stated at the beginning of my mail. I could reference the ongoing ACE work, which will at least deal with the authorization questions. Of course, that write-up in the DICE draft by itself is not be interoperable as a standalone item.

How does that sound?

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 15 Dec 2014 11:42:17 +0100

Hi Akbar,

thanks for your input and for pointing to relevant documents.

The CoAP mechanisms have been worked out quite well for local discovery.
Of course, there are other discovery techniques out there (such as
http://datatracker.ietf.org/wg/dnssd/charter/) and there is also the
issue of discovering nodes that are not in the local network.

What I could do is to cite these documents as an example of how this
works with CoAP. This provides enough information for the reader to get
the bigger picture and then, for the actual details, look at the
relevant documents. If something else other than CoAP is used then that
reader has to find the relevant information.

What do you think about my suggested approach for dealing with the other
issues since they are all related to each other?

On 12/12/2014 07:53 PM, Rahman, Akbar wrote:
> Hi Hannes,
> 
> 
> Thank you very much for the continued effort on this topic.  As you
> know, I strongly support considering the constrained server case in
> your document.  I would like to give feedback on one of the key
> points from your detailed analysis:
> 
> If we consider CoAP as the application protocol being run between the
> IoT device and the constrained server then the answer is clear.
> Discovery (of resources and/or servers) is done by sending a unicast
> or multicast CoAP GET to a well-known URI.  Various aspects of this
> discovery is explained in multiple RFCs/drafts:
> 
> 1) The CORE Link format document [RFC 6690] which first described the
> use case, and reserved the URI: - Use Case:
> http://tools.ietf.org/html/rfc6690#section-1.2.1 - Reserving the URI:
> http://tools.ietf.org/html/rfc6690#section-7.1
> 
> 2) The CoAP spec [RFC 7252] also provides a nice summary of the
> operation: - http://tools.ietf.org/html/rfc7252#section-7
> 
> 3) The CoAP Group Communications spec [RFC 7390] gives a detailed use
> case on how to multicast discover CoAP servers, and the protocol
> processing rules: - Use Case:
> http://tools.ietf.org/html/rfc7390#section-3.3 - Protocol processing
> (see 5th sub-bullet) : http://tools.ietf.org/html/rfc7390#section-2.7
> 
> 
> 
>> How do the entity initiating the communication actually reach the
>> other end (and how does it maintain that connectivity)?
> 

My reading of his response was that
 * he believes that there are many firewall traversal mechanisms already
that can be re-used, and
 * he does not believe in IPv4 for IoT deployments (and hence there is
no NAT traversal issue).

That's one view.

Ciao
Hannes

> 
> 
> 
> Best Regards,
> 
> 
> Akbar
> 
> 
> 
> -----Original Message----- From: dtls-iot
> [mailto:[email-masked]] On Behalf Of Hannes Tschofenig 
> Sent: Friday, December 12, 2014 5:33 AM To: [email-masked] 
> 
> Changes required:
> 
> - Use Session Resumption without server-side state (rather than
> session resumption) to push state information to clients. - Server
> Name Indication (SNI) since it is less likely to be used on a
> constrained server. - Random Number Generation because of the
> reference to [I-D.mathewson-no-gmtunixtime]. (small change).
> 
> No change:
> 
> - Perfect Forward Secrecy - Keep-Alive - Timeouts - Truncated MAC and
> Encrypt-then-MAC Extension - Maximum Fragment Length Negotiation -
> Session Hash - Re-Negotiation Attacks - Downgrading Attacks - Crypto
> Agility - Key Length Recommendations - False Start
> 
> behind made by the current text. As the text is currently written,
> the assumption is that there is a very close relationship between the
> cloud). This is a quite realistic usage model since this is what we
> are seeing today with many deployments where the device maker also
> provides the corresponding server-side infrastructure.
> 
> credentials and also to implement a software update mechanism the
> device can use to deal with functionality like revocation and trust
> anchor provisioning.
> 
> device-to-device communication model these assumptions suddenly do
> not work anymore. It turns out that the differentiation between
> constrained server vs. constrained client isn't all that relevant;
> what is relevant is the relationship between the different devices
> and what information can (or cannot) realistically assumed to be
> present.
> 
> Of course, there is no documentation of these different design
> patterns (other than the brief write-up in
> How do the entity initiating the communication actually reach the
> other end (and how does it maintain that connectivity)?
> 
> b) Authentication
> 
> about authorizing the client when it accesses a resource but also
> about the client ensuring that it indeed talks to a legitimate
> server?
> 
> Does this sound familiar? I am sure it does. This is essentially the
> ACE problem statement. In the current client-to-cloud model all these
> problems are sort of "solved" by simply assuming that the cloud
> service provider also provisions the IoT device. But in a more open
> model (which is, quite naturally, important to have) these questions
> are then solved either using pairing (in the very limited case, see
> description in Section 1 of 
> introducing this famous third party (which is the authorization
> server in the ACE case).
> 
> information, etc. from somewhere. Hence, this is a pure TLS exchange
> and I only need to make the modifications stated at the beginning of
> my mail. I could reference the ongoing ACE work, which will at least
> deal with the authorization questions. Of course, that write-up in
> the DICE draft by itself is not be interoperable as a standalone
> item.
> 
> How does that sound?
> 
> Ciao Hannes
> 
> 
> 
>

---

From: "Rahman, Akbar" <[email-masked]>
Date: Mon, 15 Dec 2014 18:41:51 +0000

Hi Hannes,

> The CoAP mechanisms have been worked out quite well for local discovery ... 

Please note that CoAP reserves the "All CoAP Nodes" multicast addresses to work beyond just the link-local:  

	- "A server is discovered by a client (knowing or) learning a URI that
	references a resource in the namespace of the server.  Alternatively,
	clients can use multicast CoAP (see Section 8) and the "All CoAP
	Nodes" multicast address to find CoAP servers."
	http://tools.ietf.org/html/rfc7252#section-7.1

	- The different multicast scopes are described in:
	http://tools.ietf.org/html/rfc7252#section-12.8 

	 - (Though I am not trying to trivialize the practical difficulties of setting up the multicast routing to work beyond a link-local.)  

>What I could do is to cite these documents as an example of how this works with CoAP. This provides enough information for the reader to get the bigger picture and then, for the actual details, look at the relevant documents. If something else other than CoAP is used then that reader has to find the relevant information.

Yes, I think this is a very good approach.

> What do you think about my suggested approach for dealing with the other issues since they are all related to each other?

I agree with your suggestion for pointing to the ACE WG for the Authentication and Authorization assumptions.  

> Of course, there is no documentation of these different design patterns (other than the brief write-up in ...

I don't think that this is much of an issue, frankly, because this is the model that everyone who talks about IoT already has in their head.  

Caveats:
	-I am assuming that in your place holder section 4.2 you will also put a new Figure analogous to Figure 1, and that you will describe the non-cloud based paradigm as you have nicely summarized in your original E-mail.   

	- But, if you really think that it is an issue, why don't you simply put a reference to your iab-smart-object-architecture draft as it describes the models nicely?

Best Regards,

Akbar

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Monday, December 15, 2014 5:42 AM
To: Rahman, Akbar; [email-masked]
Subject: Re: [Dtls-iot] Making progress on the constrained server topic

Hi Akbar,

The CoAP mechanisms have been worked out quite well for local discovery.
Of course, there are other discovery techniques out there (such as
http://datatracker.ietf.org/wg/dnssd/charter/) and there is also the issue of discovering nodes that are not in the local network.

What I could do is to cite these documents as an example of how this works with CoAP. This provides enough information for the reader to get the bigger picture and then, for the actual details, look at the relevant documents. If something else other than CoAP is used then that reader has to find the relevant information.

What do you think about my suggested approach for dealing with the other issues since they are all related to each other?

On 12/12/2014 07:53 PM, Rahman, Akbar wrote:
> your document.  I would like to give feedback on one of the key points 
> from your detailed analysis:
> 

That's one view.

Ciao
Hannes