Subject: [Dtls-iot] Unconstrained DTLS servers

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 25 Nov 2014 08:09:21 +0100

Hi Akbar, Hi Matthias,
Hi all,

You both raised an issue that I would like to respond to separately:

“The document still implies that all IoT devices will be DTLS clients
and that DTLS servers will be unconstrained, somewhere in the cloud.
While I understand that this is one of the current use cases (from the
OMA LWM2M Client Registration Interface), this implication undermines
the idea and benefits of CoAP. The IoT devices are meant to be the
origin/resource servers, as their sensors and actuators provide the
information about the physical world.”

You are completely correct that this is the assumption I made for the
document and I did it intentionally after consulting with the working
group earlier this year.

It is an issue of scoping.

I originally tried to cover both cases, namely a situation where the
client is constrained and the server side isn't as well as the situation
where the server side is constrained but the client isn't.

Of course, both are completely valid and reasonable use cases. There was
only one problem. The case where the server was constrained essentially
fell into the category that ACE is trying to solve. So, I had a missing
piece there with regard to the authentication and the authorization story.

For this reason I recommended to the working group to deal with the
constrained server case later when results from the ACE WG are available
since the issue is more than just the use of DTLS in that scenario.

I hope that this makes more sense and it might be worthwhile to actually
explain the scoping in the document itself and to make an informative
reference to the work in the ACE working group.

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 25 Nov 2014 08:13:19 +0100

> piece there with regard to the authentication and the authorization story.

Can you elaborate on that?  I see nothing in ACE that focuses it to constrainedness of only the server or only the client.  Conversely, I see nothing in DTLS that requires ACE to set up a connection to a constrained server (the PSK mechanism provides any decoupling between the two that might be needed).

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 25 Nov 2014 08:24:18 +0100

Hi Carsten,

On 11/25/2014 08:13 AM, Carsten Bormann wrote:
> Can you elaborate on that?  I see nothing in ACE that focuses it to constrainedness of only the server or only the client.

I didn't intent to provide a complete description of ACE. The point was
more that the ACE work isn't finished and a description in the DTLS
profile draft would have a dependency on it.

Do you agree with that part?

>  Conversely, I see nothing in DTLS that requires ACE to set up a connection to a constrained server (the PSK mechanism provides any decoupling between the two that might be needed).
We are still at the level of use cases in ACE and many of the solution
related aspects are still under discussion.

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 25 Nov 2014 08:31:21 +0100

> On 25 Nov 2014, at 08:24, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi Carsten,
> 
> I didn't intent to provide a complete description of ACE.

I still don’t get why that would be needed.

> The point was
> more that the ACE work isn't finished

Obviously.

> and a description in the DTLS

I need help understanding why that is needed in the first place.

> related aspects are still under discussion.

Is your assumption that the usage of DTLS will significantly change from the way defined in RFC 7252, as a result of the ACE work?
If yes, I’d like to know more about that.
If no, again I see only very loose coupling that would not stop us from profiling the constrained server case.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 25 Nov 2014 09:19:26 +0100

Hi Carsten,

thanks for the quick feedback.

> I still don’t get why that would be needed.

In ACE we have use cases that consider different types of constrained
devices. One important use case is the unconstrained client accessing a
constrained server. This use case is all over the map in the use case
document. The other use cases, constrained client talking to a
constrained server and constrained client to unconstrained server, are
also hinted at. The story is a bit weaker there.

(That is my reading of the use case document.)

> I need help understanding why that is needed in the first place.

In order to provide a description that is interoperable one will have to
explain what the client presents to the server to deal with
authorization. Just looking at the different solutions there are cases
where the client provides a certificate at the DTLS layer, a shared
secret at the at the DTLS layer but there are also solutions being
presented that move this functionality to the application layer. In
other cases, there may be no DTLS at all and only application layer
security objects (as presented at the last IETF meeting). We also don't
know whether we will have one solution only or more than one. Maybe we
will have one solution that provides all types of credentials; maybe not.

> Is your assumption that the usage of DTLS will significantly change from the way defined in RFC 7252, as a result of the ACE work?

RFC 7252 does not really provide enough details for these scenarios to
build an interoperable solution. Hence, I wouldn't call it "change RFC
7252" but rather fill in the gaps.

> If no, again I see only very loose coupling that would not stop us from profiling the constrained server case.

I fear that the resulting specification will suffer from a lack
interoperability. If we make good progress in ACE over the next 6 months
than a solution description will hopefully explain how the client to
resource server communication looks like.

Ciao
Hannes

---

From: Zach Shelby <[email-masked]>
Date: Tue, 25 Nov 2014 00:31:08 -0800

Hi,

Hannes is correct here, we as a working group did decide to scope this profile on a simple client-server based configuration. The profile draft was written according to that assumption.

It is also a good point that without ACE, there are some missing holes here in our specifications for constrained DTLS servers. We certainly could publish a peer-to-peer DTLS profile after the ACE work is done.

Zach

On Nov 25, 2014, at 9:09 AM, Hannes Tschofenig <[email-masked]> wrote:

> <signature.asc>_______________________________________________
> dtls-iot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtls-iot

Zach Shelby
Director of Technical Marketing
ARM Internet of Things BU
www.arm.com
US: +1 (408) 203-9434
Finland: +358 407796297
Skype: zdshelby
LinkedIn: fi.linkedin.com/in/zachshelby/

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 25 Nov 2014 09:37:28 +0100

> authorization.

I still fail to see why this is somehow easy with a constrained client and hard with a constrained server.

> Just looking at the different solutions there are cases
> presented that move this functionality to the application layer.

The DTLS profile would not cover the application layer approach, obviously.

> In
> security objects (as presented at the last IETF meeting).

Again, that is not something that the DTLS profile needs to worry about.

> We also don't

Hmm, how is a single interoperable solution a prerequisite to having a DTLS profile?
The document as is clearly is open to many different interoperable solutions for the constrained client case, and the same should be true for the constrained server.

There is some hidden assumption in this argumentation that we still need to uncover.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 25 Nov 2014 10:26:57 +0100

Hi Carsten,

On 11/25/2014 09:37 AM, Carsten Bormann wrote:
>> 
>> In order to provide a description that is interoperable one will
>> have to explain what the client presents to the server to deal
>> with authorization.
> 
> I still fail to see why this is somehow easy with a constrained
> client and hard with a constrained server.

The issue is not so much related to the constrained nature but more
about the communication pattern. The current DTLS profile draft talks
about an IoT device talking to a cloud infrastructure and also that the
credentials needed for DTLS are pre-provisioned using ways that are in
widespread use today (which are mostly configured into the
firmware/hardware).

The scenario where a constrained IoT device talks to another constrained
IoT device in the local network in a sort-of peer-to-peer style is a
less mature design pattern.

Note that I am not saying that we shouldn't write this down. I am just
saying that I rather prefer this document to get published with this
scope rather than expanding the scope at this point in time.

> 
>> Just looking at the different solutions there are cases where the
>> client provides a certificate at the DTLS layer, a shared secret at
>> the at the DTLS layer but there are also solutions being presented
>> that move this functionality to the application layer.
> 

And maybe the ACE work will lead to conclusion that the use of DTLS
between constrained clients and servers isn't a good idea.

> 
>> In other cases, there may be no DTLS at all and only application
>> layer security objects (as presented at the last IETF meeting).
> 

But we don't know yet what we will come up with in the end.

You are essentially saying that we should standardize part of the story
of ACE in DICE already before we even finalized the use cases.

Why are we doing the use cases when we already know what the solution is
going to be anyway?

> 
>> We also don't know whether we will have one solution only or more
>> than one. Maybe we will have one solution that provides all types
>> of credentials; maybe not.
>> 
>>>>> Conversely, I see nothing in DTLS that requires ACE to set up
>>>>> a connection to a constrained server (the PSK mechanism
>>>>> provides any decoupling between the two that might be
>>>>> needed).
>>>> We are still at the level of use cases in ACE and many of the
>>>> solution related aspects are still under discussion.
>>> 
>>> Is your assumption that the usage of DTLS will significantly
>>> change from the way defined in RFC 7252, as a result of the ACE
>>> work?
>> 
>> RFC 7252 does not really provide enough details for these scenarios
>> to build an interoperable solution. Hence, I wouldn't call it
>> "change RFC 7252" but rather fill in the gaps.
> 
> Hmm, how is a single interoperable solution a prerequisite to having
> a DTLS profile? The document as is clearly is open to many different
> interoperable solutions for the constrained client case, and the same
> should be true for the constrained server.
> 

Wouldn't it be nice if we had fewer solutions than more? Don't you think
that will improve interoperability?

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 25 Nov 2014 13:53:58 +0100

I am responding to my own mail because I am still looking for the use
cases for the case where a client (constrained or unconstrained) talks
to a constrained server.

Clearly, the cloud infrastructure can hardly be called "constrained" in
our terminology. So, we can rule out that use case.

From
http://tschofenig.priv.at/ace/interim2014/Design-Patterns_HannesTschofenig.pdf
I guess we would really be talking about a device-to-device scenario.
This might be the situation where you have IoT devices in a local
network waiting for each other to be discovered.
(I am excluding the case where the devices are only one link layer hop
away from each other.)

In a true peer-to-peer scenario there wouldn't be an authorization
server and hence the security model might be more trust on first use or
maybe some form of out-of-band validation. A PSK mode wouldn't make a
lot of sense (since the PSK is too long for a user to enter) but an
SRP-alike concept does (as used in the Apple Homekit and Nest-alike
devices). As shown already in Zigbee IP (and later in Thread) the
problem is not only to connect to the other server but also to get the
network attachment procedure executed in the first place (which might
make use of some TLS/DTLS exchange).

For a scenario where there is a trusted third party the story is quite
different, namely with a CA-based model (such as with a hardware
manufacturer provided certificate) the third party is the CA and DTLS
could be executed nicely when authentication is the main concern and all
devices are provisioned with the same trust anchors.

For a more Kerberos/OAuth model there are more options in terms of
credentials. PSK, and raw public keys would work fine. Certificates are
most likely an overkill since the tokens/tickets already contain most of
the relevant information.

So, what environment have you had in mind?

Ciao
Hannes

---

From: "Rahman, Akbar" <[email-masked]>
Date: Tue, 25 Nov 2014 17:04:09 +0000

Hi Hannes,

>I am responding to my own mail because I am still looking for the use cases for the case where a client (constrained or unconstrained) talks to a constrained server.

Maybe we are just using different frames of reference here.

- In CoAP, the sender of the CoAP Request message is always the Client and the receiver of the Request message is always the Server (see http://tools.ietf.org/html/rfc7252#section-5 ).

- So let's simply take the case of a small (constrained) sensor that only measures temperature.   In this case the sensor will act as a constrained server as soon as it is polled (GET) for its current temperature

Does that help clarify things a bit?

Best Regards,

Akbar

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Tuesday, November 25, 2014 7:54 AM
To: [email-masked]; Rahman, Akbar
Cc: [email-masked]
Subject: Re: Unconstrained DTLS servers

I am responding to my own mail because I am still looking for the use cases for the case where a client (constrained or unconstrained) talks to a constrained server.

Clearly, the cloud infrastructure can hardly be called "constrained" in our terminology. So, we can rule out that use case.

From
http://tschofenig.priv.at/ace/interim2014/Design-Patterns_HannesTschofenig.pdf
I guess we would really be talking about a device-to-device scenario.
This might be the situation where you have IoT devices in a local network waiting for each other to be discovered.
(I am excluding the case where the devices are only one link layer hop away from each other.)

In a true peer-to-peer scenario there wouldn't be an authorization server and hence the security model might be more trust on first use or maybe some form of out-of-band validation. A PSK mode wouldn't make a lot of sense (since the PSK is too long for a user to enter) but an SRP-alike concept does (as used in the Apple Homekit and Nest-alike devices). As shown already in Zigbee IP (and later in Thread) the problem is not only to connect to the other server but also to get the network attachment procedure executed in the first place (which might make use of some TLS/DTLS exchange).

For a scenario where there is a trusted third party the story is quite different, namely with a CA-based model (such as with a hardware manufacturer provided certificate) the third party is the CA and DTLS could be executed nicely when authentication is the main concern and all devices are provisioned with the same trust anchors.

For a more Kerberos/OAuth model there are more options in terms of credentials. PSK, and raw public keys would work fine. Certificates are most likely an overkill since the tokens/tickets already contain most of the relevant information.

Ciao
Hannes

On 11/25/2014 08:09 AM, Hannes Tschofenig wrote:
> client is constrained and the server side isn't as well as the 
> situation where the server side is constrained but the client isn't.
> 
> Of course, both are completely valid and reasonable use cases. There 
> was only one problem. The case where the server was constrained 
> essentially fell into the category that ACE is trying to solve. So, I 
> had a missing piece there with regard to the authentication and the authorization story.
> 
> constrained server case later when results from the ACE WG are 
> available since the issue is more than just the use of DTLS in that scenario.
> 
> I hope that this makes more sense and it might be worthwhile to 
> actually explain the scoping in the document itself and to make an 
> informative reference to the work in the ACE working group.
> 
> Ciao
> Hannes
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 26 Nov 2014 09:01:34 +0100

Hi Akbar,

thanks for your quick response.

A remark below.

On 11/25/2014 06:04 PM, Rahman, Akbar wrote:
> Hi Hannes,
> 
> 
>> I am responding to my own mail because I am still looking for the
>> use cases for the case where a client (constrained or
>> unconstrained) talks to a constrained server.
> 
> - In CoAP, the sender of the CoAP Request message is always the
> Client and the receiver of the Request message is always the Server
> (see http://tools.ietf.org/html/rfc7252#section-5 ).
> 
> - So let's simply take the case of a small (constrained) sensor that
> only measures temperature.   In this case the sensor will act as a
> constrained server as soon as it is polled (GET) for its current
> temperature

Of course, this is not the envisioned interaction when DTLS is used
because in this setup the sensor would suddenly become the DTLS server
and the roles would be reversed.

Despite the changed roles there are likely other problems, such as how
does the cloud server even know which sensor to talk to, how would the
request go through a firewall, what happens if NAT bindings expire and
the requests get dropped on the floor, etc.

Since you raised this issue it might be worthwhile to discuss it in the
draft as well.

Ciao
Hannes

> -----Original Message----- From: Hannes Tschofenig
> [mailto:[email-masked]] Sent: Tuesday, November 25, 2014
> 7:54 AM To: [email-masked]; Rahman, Akbar Cc:
> [email-masked] Subject: Re: Unconstrained DTLS servers
> 
> cases for the case where a client (constrained or unconstrained)
> talks to a constrained server.
> 
> Clearly, the cloud infrastructure can hardly be called "constrained"
> in our terminology. So, we can rule out that use case.
> 
> From 
> network waiting for each other to be discovered. (I am excluding the
> case where the devices are only one link layer hop away from each
> other.)
> 
> server and hence the security model might be more trust on first use
> or maybe some form of out-of-band validation. A PSK mode wouldn't
> make a lot of sense (since the PSK is too long for a user to enter)
> but an SRP-alike concept does (as used in the Apple Homekit and
> Nest-alike devices). As shown already in Zigbee IP (and later in
> Thread) the problem is not only to connect to the other server but
> also to get the network attachment procedure executed in the first
> place (which might make use of some TLS/DTLS exchange).
> 
> For a scenario where there is a trusted third party the story is
> quite different, namely with a CA-based model (such as with a
> hardware manufacturer provided certificate) the third party is the CA
> and DTLS could be executed nicely when authentication is the main
> concern and all devices are provisioned with the same trust anchors.
> 
> credentials. PSK, and raw public keys would work fine. Certificates
> are most likely an overkill since the tokens/tickets already contain
> most of the relevant information.
> 
> Ciao Hannes
>> Hi Akbar, Hi Matthias, Hi all,
>> 
>> “The document still implies that all IoT devices will be DTLS
>> clients and that DTLS servers will be unconstrained, somewhere in
>> the cloud. While I understand that this is one of the current use
>> cases (from the OMA LWM2M Client Registration Interface), this
>> implication undermines the idea and benefits of CoAP. The IoT
>> devices are meant to be the origin/resource servers, as their
>> sensors and actuators provide the information about the physical
>> world.”
>> 
>> You are completely correct that this is the assumption I made for
>> the document and I did it intentionally after consulting with the
>> working group earlier this year.
>> 
>> I originally tried to cover both cases, namely a situation where
>> the client is constrained and the server side isn't as well as the
>> Of course, both are completely valid and reasonable use cases.
>> There was only one problem. The case where the server was
>> constrained essentially fell into the category that ACE is trying
>> to solve. So, I had a missing piece there with regard to the
>> authentication and the authorization story.
>> 
>> Ciao Hannes
> _______________________________________________ dtls-iot mailing
> list [email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 26 Nov 2014 09:31:30 +0100

> Of course, this is not the envisioned interaction when DTLS is used

I think it would be useful to address CoAP-based interactions in this draft.

> and the roles would be reversed.

I’m not sure what that means.

A sensor has a resource that is being served to its clients.
I’m not seeing a role reversal here, unless it is somehow hardwired that “servers” must be big gear.  (The classical PKI-based certificate usage may favor this view, but we are not bound to that usage.)

Of course, the question who is CoAP server does not predetermine who is DTLS server.
A CoAP server might very well be asked by a management mechanism (preconfigured or dynamic) to open a DTLS connection to one or more of its clients.

> does the cloud server even know which sensor to talk to,

That is what the resource directory is there for.

> how would the
> request go through a firewall,

We haven’t built specific mechanisms for firewall traversal into CoAP, because people seemed to think there were enough ways to do this.  If the firewall traversal is conditioned on which side opens the DTLS connection, then I think you have much, much bigger problems.

> what happens if NAT bindings expire

(IPv6 deployments don’t have this problem.  For IPv4:)
UDP NAT binding expiry is independent of who opens a DTLS connection on top of that UDP five-tuple.
Of course, getting the NAT binding in the first place is an argument for initiating traffic from the inside of a NAT, but this, again, has little bearing on who has the DTLS client role.

> Since you raised this issue it might be worthwhile to discuss it in the

That is useful if the draft doesn’t just stick to pre-conceived notions of what those roles are in the IPv4/HTTP web.

Grüße, Carsten

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Wed, 26 Nov 2014 12:51:59 +0000

Dear Hannes

1) Scope of the DICE Profile

Focusing on the constrained DTLS client case is fine with me. However, this must then also be made explicit in the document and probably even in the title. Currently the draft somewhat promotes the constrained DTLS client talking to the cloud as the only valid IoT scenario. This is simply false. We can aim for one profile to deal with the IPv4 and NAT traversal problems for the cloud scenario and add more profiles later. For me, the IoT is something different, though, where we do not have such isolated silos. In my view, applications converge, and hence we will find all the scenarios in a single deployment (e.g., local control and processing with storage in the cloud). Thus, it would make sense to have a single DICE profile.

With the current version of the draft, I do not even see a problem as single profile, except that it promotes the "preprogrammed client pushes data to the cloud" scenario. I do not even see how we would need interoperability in this scenario, since all devices are pre-paired with a service by the manufacturer and can run the same proprietary software stack.

2) Scenario for constrained DTLS servers

The constrained DTLS server directly follows the work in CoRE. Here the device-to-device, but also something like smartphone-to-device scenario applies. A profile should be compatible with both, a constrained and an unconstrained device contacting a constrained DTLS server (to interact with the CoAP server). The resource discovery mechanisms would be worthless if devices or services cannot initiate the interaction with IoT devices. Like in the current DTLS client profile, the question about network attachment and distribution of the keying material should be out of scope. The latter is already covered by ACE, for instance.

Concrete use cases are:

a) A new constrained device joins the home network (network attachment procedure out-of-scope) and provides its services as CoAP server, e.g., temperature and humidity sensing. The new device can be discovered through multicast or a local resource directory where it registered. A thermostat with opportunistic sensing support discovers the new device and observes the sensor readings through a request to the device. For this, the new device must act as DTLS server.

b) A user uses a smartphone to bind a lightswitch to specific lightbulbs. Since such bindings cannot be pre-programmed at the manufacturer, a CoAP client (the lightswitch sending (multicast) requests to lightbulbs) also hosts a CoAP server to provide the configuration interface. The constrained lightswitch must again act as DTLS server to accept requests from the unconstrained smartphone.

The network attachment and the big authorization question are out-of-scope for a DICE profile.

Ciao
Matthias