Subject: [Dtls-iot] Current dtls-iot charter text - discuss...

From: Stephen Farrell <[email-masked]>
Date: Mon, 03 Jun 2013 22:23:21 +0100

Hi all,

The text below is from [1].

Is it perfect? What'd you change? Please discuss this on the
list between now and the proposed Berlin meeting.

Some I-Ds on relevant topics being published before June 20
would also be useful in deciding whether or not to approve
the BoF slot, but so is charter discussion.

Thanks,
Stephen.

[1]
https://docs.google.com/document/d/1Gw00WXRgjJJQJMv9seVpuXuLtIDYKhHE-7pX4eDo3g8/edit?pli=1#

DTLS for IoT Group

The purpose of this document is to organize interest in a group to
standardize a set of optimizations to DTLS for use with constrained
devices and networks. Possible goals for this activity could be:

A minimal configuration profile of DTLS for IoT
Multicast record layer support for DTLS
Implementation and deployment guidance (-> LWIG)
Optimization of the DTLS handshake and record layer (-> TLS WG after
profiling)
Use of DTLS for security bootstrapping and key management (-> own activity)

Action Points

Write a draft of DTLS implementation and deployment guidance to LWIG.
[Hannes, Sandeep]
Write a straw-man draft (maybe updating the current one) on multicast
record-layer support for DTLS [Sye Loong]
Write a straw-man draft on the TLS over CoAP handshake and profiling
[Sye Loong]
Submit the BOF request for Berlin [Sye Loong, Zach]

Mailing List

https://www.ietf.org/mailman/listinfo/dtls-iot

Existing work

http://www.ietf.org/id/draft-hartke-core-codtls-02.txt
http://www.ietf.org/id/draft-tschofenig-lwig-tls-minimal-02.txt
http://www.ietf.org/id/draft-keoh-lwig-dtls-iot-01.txt
http://www.ietf.org/id/draft-keoh-tls-multicast-security-00.txt
http://www.ietf.org/id/draft-ietf-tls-oob-pubkey-07.txt
http://www.ietf.org/id/draft-jennings-core-transitive-trust-enrollment-01.txt

Draft Charter – DTLS for the Internet of Things (DIoT?)

There is an increased use of wireless control networks in city
infrastructure, environmental monitoring, industrial automation, and
building management systems.  These wireless control networks comprise
many electronic devices, sensors and actuators that are connected to
each other, and in most cases Internet connected, thus creating a trend
towards Internet of Things (IoT). The CoRE working group has defined a
framework for resource-oriented applications intended to run on
Constrained Node Networks (CNN) (see I-D-ietf-lwig-terminology). A CNN
connects devices which are constrained by power, limited amount of code
size and memory in a network with severe limits on throughput. The
Constrained Application Protocol (CoAP) can be used to manipulate
resources on a device in a CNN.

Group communication is an important feature in CNNs as it can be
effectively used to convey messages to a group of devices without
requiring the sender to perform multiple time- and energy-consuming
unicast transmissions, one for each group member.  For example, in a
building control management system, Heating, Ventilation and
Air-Conditioning (HVAC) and lighting devices can be grouped according to
the layout of the building, and control commands can be issued to a
group of devices.  Unsecured group communication for CNNs is enabled by
using CoAP on top of IP-multicast. However, it must be secured as it is
vulnerable to the usual attacks (eavesdropping, tampering, message
forgery, replay, etc).  Datagram Transport Layer Security (DTLS) has
been chosen by CoRE to protect CoAP unicast communications, and it would
be beneficial if the same security protocol, i.e., DTLS can be used to
protect CoAP group communication as well.

The current design of DTLS leads to fragmentation of DTLS handshake
messages over the wireless link, in particular when Raw Public-key and
Certificate modes are used. From the various implementation experiences
reported in the LWIG working group, the complexity of re-transmission
and re-ordering of DTLS handshake messages in CNNs has resulted in a
significantly increased code size and RAM. Additional reliability
mechanisms for transporting DTLS handshake messages are required as they
will ensure that handling of re-ordered messages needs to be done in a
single place in the stack only.

This WG combines expertise from both the IETF Application and Security
areas in order to work out the appropriate security solutions for the
Internet of Things.

The scope of this WG is to define the following:

Document the problems with the DTLS handshake for IoT, and define a
suitable profile of DTLS for an IoT architecture and use case that
minimizes the complexity and overhead of DTLS for constrained devices.

The use of DTLS Record Layer in combination with the (derived) multicast
key to protect the CoAP group communication without source
authentication. The DTLS Record Layer should not be modified/altered.

Goals and Milestones

Oct 2013		WG document for DTLS for IoT profile
Nov 2013          	WG document for secure multicast group communication
in CNNs
Feb 2014		DTLS for IoT profile specification submitted to the IESG
Mar 2014          	Secure Multicast group communication specification
submitted to the IESG

Initial brainstorming

A minimal configuration profile of DTLS

[Klaus: Implementations in a deployment need to agree on cipher suite,
etc. for interop. Maybe it’s possible to define minimal profiles for a
number of typical scenarios?]

[Sandeep: when selecting the minimal profiles for different typical
scenarios it would be nice to select a common underlying cipher (like
AES) to reduce implementation costs, so using AES-CMAC for
authentication and AES-CCM for additional confidentiality

Zach: Common Ciphers are already defined in the CoAP specification. ]

What defines a “profile”?

Maybe what we really need from a profile is to explain the (D)TLS
features actually needed for a set of IoT applications that we commonly
come across. The purpose of this profile would be to limit the number of
options and flexibility in especially the (D)TLS handshake. What are the
features actually needed for use with CoAP?

Applicability
Communication model
Threat model
Security requirements
Class of devices
...
Cipher suites
Extensions
Signature Algorithms
Server Name Indication
Maximum Fragment Length
Supported Elliptic Curves
Supported Point Formats
Application Layer Protocol
Heartbeat
Cached Info
Session Resumption
...
Timer values
...

[Note RS: it would be good to define technical requirements first here.
-security services (authenticated key agreement, authenticated key
transport, entity authentication, secured data transport (unicast,
multicast, broadcast; source authentication, etc.), replay protection,
timeliness, etc. Authorization (identity-based, role based), privacy, etc.
-communication services: in-order delivery,
fragmentation/defragmentation support, etc.
-support for initial provisioning, configuration
-scalability, adaptability towards change of role/trust models, device
replacement, merging and partitioning of networks, flexible
authorization policy management, etc.
- how to deal with typical network aspects, including sleepy nodes,
crappy links, no online availability trusted third party
-how to make sure human involvement is virtually absent
-support for existing/legacy implementation pieces (e.g., AES in
hardware; RNG, etc., device id)
-support for memory-starved devices, with harldy any buffering
capability, etc.

Zach: Well, we have already been through the main requirements when we
chose DTLS as the solution for CoAP in general. Much of this is also
captured in the main CoAP ID. However for the purpose of optimizing
DTLS, I agree we should capture the security requirements in relation to
what we want to achieve. The goal here however is NOT to reconsider
CoAP’s choice of security protocol, model, cipher suites etc. The goal
here is to make the choice we already made more efficient, and to
support multicast.
]
Implementation and deployment guidance

Recommendations on

handshake fragmentation to minimize retransmissions
timer values to avoid spurious retransmissions
when to perform handshake (on device startup, on demand, ...)
when to close connections (when idle, …)
DTLS version negotiation
epochs >= 2
session resumption

Dealing with resource exhaustion (eviction strategy for connections, ...)
Implementation techniques for implementing CoAP over DTLS
...

[Zach: This should be done in LWIG. Someone could already start writing
this document up there?]
Optimization of the DTLS handshake and record layer

DTLS is written as a diff to TLS. The diff changes the transport to an
unreliable datagram-based transport, adds reliability to the handshake
layer and makes a few modifications to the record layer to cater for
message reordering, etc.

DTLS was clearly not designed with constrained devices and lossy
networks in mind. It should be possible to investigate alternate
reliability mechanisms and message formats that are more suitable for
constrained environments but do not touch TLS itself. This means
basically reinventing the “D” in “DTLS”, to a greater or smaller extent.

Ideas floating around:

Transport the handshake messages in CoAP requests and responses, using
draft-ietf-core-block to transport messages that do not fit in a single
datagram.

Transport the DTLS records in CoAP messages. For experimentation, I have
added a tiny (5 bits) fragmentation indication to the CoAP messaging
layer. The result can be used to transport the DTLS messages of a
handshake flight in the same simple lock-step fashion as we already do
in CoAP, instead of transmitting all messages at once and retransmitting
all fragment when a single fragment is lost.

Retransmit all fragments when a single fragment is lost and focus on
reducing the number of fragments to be sent. Retransmitting all
fragments actually performs better(!) than sending one acknowledgement
per fragment in lossy environments in terms of transmission count.

[Note RS: it is not a priori clear that DTLS fits the bill here: first
discuss requirements, instead of reverse engineering those from dreamt
up solution that may be incomplete at best (I am not saying it is, but
it could

Zach: This group is not about re-thinking security from scratch. We
already chose (D)TLS as our security binding for CoAP. Based on
experience using it so far, there is some obvious optimization that can
be done, as well as an important feature missing. ]

Multicast record layer support for DTLS

The current DTLS record layer header can be used to support/protect a
single sender-multiple receivers group communication scenario. The
sequence number field in the record layer header is probably sufficient
to detect replay attacks. This is based on the assumption that
authorized devices in a multicast group are trusted to behave correctly.
The question then is whether this assumption is reasonable and do we
need additional measures to prevent insider attacks?

There was also a question whether source authentication is necessarily
for multicast? In our opinion, this can be an optional feature in that
for some important use cases, e.g., switching off all lights in the
building, source authentication is required. Providing source
authentication with a group key is not feasible, an alternative is to
provide source authentication at the CoAP level using public-key
cryptography?

A single security protocol for IoT

To strive for a single security protocol (e.g., the optimized “D”TLS)
that can provide the required security functionalities such as network
access, key management (distribution of unicast, multicast keys) and
secure group communication such that we can optimize the use of memory
on the constrained devices.

Define the workflow in to perform network access using DTLS
Define ways of distributing and renewing application, network, and
multicast keys over the DTLS secure channel, i.e., using CoAP messages
to encapsulate keying materials.
Define the key derivation methods, re-using the security components in
DTLS, e.g., PRF functions, AES.

---

From: Zach Shelby <[email-masked]>
Date: Tue, 4 Jun 2013 14:57:35 +0100

I know there are several people working on new I-Ds related to this activity, please let us know what you are working on and if any help is needed. 

> http://www.ietf.org/id/draft-jennings-core-transitive-trust-enrollment-01.txt

Regards,
Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: +358 40 7796297
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net

---

From: "Keoh, Sye Loong" <[email-masked]>
Date: Tue, 4 Jun 2013 16:39:45 +0000

We are working on an I-D to discuss the challenges/problems implementers experienced when deploying DTLS for IoT applications, especially the fragmentation issues, and what kind of DTLS profiles can be defined for IoT application.

Meanwhile, we are in the process of updating our Multicast security draft (http://www.ietf.org/id/draft-keoh-tls-multicast-security-00.txt).

Cheers
Sye Loong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zach Shelby
Sent: dinsdag 4 juni 2013 15:58
To: [email-masked]
Subject: Re: [Dtls-iot] Current dtls-iot charter text - discuss...

Regards,
Zach

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Bert Greevenbosch <[email-masked]>
Date: Fri, 7 Jun 2013 01:55:51 +0000

Hi all,

I think the following draft fits in the discussion of DTLS-IOT:
http://datatracker.ietf.org/doc/draft-greevenbosch-tls-ocsp-lite/

This is quite an early approach to tackling the revocation/authentication issue in a scalable way. Section 4 discusses some requirements.

The draft certainly is to be seen as work in progress, but it addresses an issue that requires due attention.

Best regards,
Bert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zach Shelby
Sent: 2013年6月4日 21:58
To: [email-masked]
Subject: Re: [Dtls-iot] Current dtls-iot charter text - discuss...

Regards,
Zach

---

From: "Keoh, Sye Loong" <[email-masked]>
Date: Mon, 10 Jun 2013 14:48:00 +0000

Hi Bert,

Do you know whether the current IoT Deployments, such as Zigbee-IP checks the revocation list? Do you foresee Revocation a potentially serious problem in the future when devices are being replaced, compromised, and when reselling them?

Cheers
Sye Loong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bert Greevenbosch
Sent: vrijdag 7 juni 2013 3:56
To: Zach Shelby; [email-masked]
Subject: Re: [Dtls-iot] Current dtls-iot charter text - discuss...

Hi all,

Best regards,
Bert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zach Shelby
Sent: 2013年6月4日 21:58
To: [email-masked]
Subject: Re: [Dtls-iot] Current dtls-iot charter text - discuss...

Regards,
Zach

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

---

From: Paul Duffy <[email-masked]>
Date: Mon, 10 Jun 2013 18:34:01 +0200

Zigbee IP does not mandate use of CRLs or OCSP for device certificates
(in IEEE 802.1AR-speak ... the UDevID). Supporting these mechanisms for
device certificates on constrained devices and networks, at mass scale,
is highly problematic.

Definitely an area for investigation.

On 6/10/2013 4:48 PM, Keoh, Sye Loong wrote:
> .

---

From: Don Sturek <[email-masked]>
Date: Mon, 10 Jun 2013 10:02:07 -0700

To add onto what Paul wrote......

ZigBee IP supports white lists/ black lists for network admission but we
leave it up to the application as to how these lists are created/managed.
 As Paul noted, OCSP or CRL on device certificates is not a scalable
solution (and in many cases not even desired......)

To back up Paul's suggestion, it would be great to see this as an area of
investigation in dlts-iot (or whatever the name becomes!)

Don

On 6/10/13 9:34 AM, "Paul Duffy" <[email-masked]> wrote:

>> Do you know whether the current IoT Deployments, such as Zigbee-IP
>>checks the revocation list? Do you foresee Revocation a potentially
>>serious problem in the future when devices are being replaced,
>>compromised, and when reselling them?
>>
>> Cheers
>> Sye Loong
>>
>> This is quite an early approach to tackling the
>>revocation/authentication issue in a scalable way. Section 4 discusses
>>some requirements.
>>
>> I know there are several people working on new I-Ds related to this
>>activity, please let us know what you are working on and if any help is
>>needed.
>>
>> The information contained in this message may be confidential and
>>legally protected under applicable law. The message is intended solely
>>for the addressee(s). If you are not the intended recipient, you are
>>hereby notified that any use, forwarding, dissemination, or reproduction
>>of this message is strictly prohibited and may be unlawful. If you are
>>not the intended recipient, please contact the sender by return e-mail
>>and destroy all copies of the original message.
>>

---

From: "Keoh, Sye Loong" <[email-masked]>
Date: Tue, 11 Jun 2013 18:57:49 +0000

Thanks for the Clarification Don and Paul.

Indeed, this is a good area of investigation. However, are we too early to explore revocation issues in this BOF? I had the impression that this BOF/WG aims to investigate the use of DTLS for IoT applications, or at least getting DTLS to run "comfortably" together with CoAP would be the primary goal of this activity and revocation is rather independent of this, isn't it?

BTW, Is there any plan in Zigbee-IP or Zigbee Alliance to investigate Revocation issue?

cheers
Sye Loong
________________________________________
From: [email-masked] [[email-masked]] on behalf of Don Sturek [[email-masked]]
Sent: Monday, June 10, 2013 7:02 PM
To: [email-masked]; [email-masked]
Subject: Re: [Dtls-iot] Current dtls-iot charter text - discuss...

Don

---

From: Zach Shelby <[email-masked]>
Date: Tue, 11 Jun 2013 22:11:18 +0300

Guys,

I think the revocation issue is a good idea for possible future work in this WG once we've completed our first charter on profiling and multicast. 

Regards,
Zach

---

From: Don Sturek <[email-masked]>
Date: Tue, 11 Jun 2013 12:28:36 -0700

Hi Sye Loong,

We (the ZigBee Alliance) are not currently working on revocation issues
since our focus is on network joining.   We don't use revocation on our
identity (device) certificates since these certificates are just for
authentication.

For authorization, we expect additional certificates to be used (provided
by service providers, utilities, etc.).  These certificates need to have
CRL or OCSP, however, these processes are a bit heavyweight for the
devices we are using.

Don

On 6/11/13 11:57 AM, "Keoh, Sye Loong" <[email-masked]> wrote:

>Indeed, this is a good area of investigation. However, are we too early
>to explore revocation issues in this BOF? I had the impression that this
>BOF/WG aims to investigate the use of DTLS for IoT applications, or at
>least getting DTLS to run "comfortably" together with CoAP would be the
>primary goal of this activity and revocation is rather independent of
>this, isn't it?
>
>>>>http://www.ietf.org/id/draft-jennings-core-transitive-trust-enrollment-
>>>>0
>>>>1.txt
>>> Regards,
>>> Zach
>>>
>>> --
>The information contained in this message may be confidential and legally
>protected under applicable law. The message is intended solely for the
>addressee(s). If you are not the intended recipient, you are hereby
>notified that any use, forwarding, dissemination, or reproduction of this
>message is strictly prohibited and may be unlawful. If you are not the
>intended recipient, please contact the sender by return e-mail and
>destroy all copies of the original message.
>

---

From: Bert Greevenbosch <[email-masked]>
Date: Thu, 13 Jun 2013 00:53:44 +0000

Hi Don, Sye Loong, Zach, all,

Indeed CRL and OCSP are far too heavyweight for a constrained environment. Hence my attempt to create a solution that delegates revocation and authorisation checking to a trusted and more capable intermediary.

The proposed OCSP-lite protocol (we still need a better name for this) is the protocol between the constrained device and the intermediary; the intermediary can then perform the more advanced revocation/authorisation checks.

Anyway I think it is too early to discuss the technical solution, after all we are only in the charter drafting phase. But I do think that revocation/authorisation is an essential part in a security system, and should be given due attention in the WG from the beginning.

Best regards,
Bert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Don Sturek
Sent: 2013年6月12日 3:29
To: Keoh, Sye Loong; [email-masked]; [email-masked]
Subject: Re: [Dtls-iot] Current dtls-iot charter text - discuss...

Hi Sye Loong,

Don

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Thu, 13 Jun 2013 07:20:15 +0000

Hi Bert

I agree that revocation is an important and often neglected topic. However before we can discuss revocation, we first need the DTLS protocol to be capable of being used for most IoT devices and networks. The  I-D submitted yesterday, draft-keoh-dtls-profile-iot-00.txt provides input to kick off this discussion. Once we have a IoT profiled DTLS protocol, we surely should think more seriously on revocation. The charter should focus to first fulfill this initial aim to make DTLS suitable for constrained environments otherwise we might end up spending lot of energy designing revocation techniques without any relevant protocol that would work within a constrained domain.

Kind regards
Sandeep

Filename:        draft-keoh-dtls-profile-iot
Revision:        00
Title:           Profiling of DTLS for CoAP-based IoT Applications
Creation date:   2013-06-12
Group:           Individual Submission
Number of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-keoh-dtls-profile-iot-00.txt
Status:          http://datatracker.ietf.org/doc/draft-keoh-dtls-profile-iot
Htmlized:        http://tools.ietf.org/html/draft-keoh-dtls-profile-iot-00

Abstract:
   This document collects various implementation challenges of DTLS on
   embedded systems, and proposes a profile of DTLS for CoAP-based
   Internet of Things (IoT) applications. Specifically, this document
   investigates the application features and functionality of DTLS
   protocol, the fragmentation issue of DTLS Handshake protocol, and the
   complexity of the DTLS Handshake state machine. A RESTful DTLS
   Handshake which relies on CoAP Block-wise Transfer is proposed to
   address the fragmentation issue. The next step is to define a DTLS
   profile for embedded systems.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bert Greevenbosch
Sent: Thursday, June 13, 2013 2:54 AM
To: Don Sturek; Keoh, Sye Loong; [email-masked]; [email-masked]; Zach Shelby
Subject: Re: [Dtls-iot] Current dtls-iot charter text - discuss...

Best regards,
Bert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Don Sturek
Sent: 2013年6月12日 3:29
To: Keoh, Sye Loong; [email-masked]; [email-masked]
Subject: Re: [Dtls-iot] Current dtls-iot charter text - discuss...

Hi Sye Loong,

We (the ZigBee Alliance) are not currently working on revocation issues
since our focus is on network joining.   We don't use revocation on our
identity (device) certificates since these certificates are just for authentication.

For authorization, we expect additional certificates to be used (provided by service providers, utilities, etc.).  These certificates need to have CRL or OCSP, however, these processes are a bit heavyweight for the devices we are using.

Don

On 6/11/13 11:57 AM, "Keoh, Sye Loong" <[email-masked]> wrote:

>to explore revocation issues in this BOF? I had the impression that
>this BOF/WG aims to investigate the use of DTLS for IoT applications,
>or at least getting DTLS to run "comfortably" together with CoAP would
>be the primary goal of this activity and revocation is rather
>independent of this, isn't it?
>
>ZigBee IP supports white lists/ black lists for network admission but
>we leave it up to the application as to how these lists are created/managed.
>To back up Paul's suggestion, it would be great to see this as an area
>of investigation in dlts-iot (or whatever the name becomes!)
>
>Don
>
>
>>(in IEEE 802.1AR-speak ... the UDevID). Supporting these mechanisms
>>for device certificates on constrained devices and networks, at mass
>>scale, is highly problematic.
>>
>>>revocation/authentication issue in a scalable way. Section 4
>>>discusses some requirements.
>>>
>>> The draft certainly is to be seen as work in progress, but it
>>>addresses an issue that requires due attention.
>>>
>>> Best regards,
>>> Bert
>>>
>>>
>>>activity, please let us know what you are working on and if any help
>>>is needed.
>>>
>>>legally protected under applicable law. The message is intended
>>>solely for the addressee(s). If you are not the intended recipient,
>>>you are hereby notified that any use, forwarding, dissemination, or
>>>reproduction of this message is strictly prohibited and may be
>>>unlawful. If you are not the intended recipient, please contact the
>>>sender by return e-mail and destroy all copies of the original message.
>>>
>hereby notified that any use, forwarding, dissemination, or
>reproduction of this message is strictly prohibited and may be
>unlawful. If you are not the intended recipient, please contact the
>sender by return e-mail and destroy all copies of the original message.
>

---

From: Bert Greevenbosch <[email-masked]>
Date: Fri, 14 Jun 2013 00:49:16 +0000

Hi Sandeep,

-=- Quote -=-
-=- /Quote -=-

I think we should not neglect revocation until the first phase is over. It is an important issue, and neglecting it now may cost us dearly in the future. For sound security, authentication and revocation are essential.

Best regards,
Bert

-----Original Message-----
From: Kumar, Sandeep [mailto:[email-masked]] 
Sent: 2013年6月13日 15:20
To: Bert Greevenbosch; Don Sturek; Keoh, Sye Loong; [email-masked]; [email-masked]; Zach Shelby
Subject: RE: [Dtls-iot] Current dtls-iot charter text - discuss...

Hi Bert

Kind regards
Sandeep

Abstract:

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bert Greevenbosch
Sent: Thursday, June 13, 2013 2:54 AM
To: Don Sturek; Keoh, Sye Loong; [email-masked]; [email-masked]; Zach Shelby
Subject: Re: [Dtls-iot] Current dtls-iot charter text - discuss...

Best regards,
Bert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Don Sturek
Sent: 2013年6月12日 3:29
To: Keoh, Sye Loong; [email-masked]; [email-masked]
Subject: Re: [Dtls-iot] Current dtls-iot charter text - discuss...

Hi Sye Loong,

Don

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 14 Jun 2013 21:04:44 +0000

Before devoting much effort to this, a "requirements" document should lay out the use cases for revocation in an IoT environment.  The charter implies that DICE is applicable to hub-and-spoke communications where a constrained device needs to authenticate a controller and vice versa, not mesh communications where one light bulb would need to authenticate another light bulb.  As long as the controller is aware of which devices are no longer trustworthy, it can simply refuse to talk to them without distributing status information about all devices to all devices.

In the multicast scenario there is even less case for revocation - multicast keys are distributed from a single point, which can simply refuse to key any "revoked" devices into the multicast group.

Finally, under what circumstances would an IoT need to be revoked?  People change names, affiliations, roles.  People lose their tokens.  But none of those reasons apply to devices.  If an adversary compromises the key of a device, sensor or actuator, what harm comes to the IoT if the controller but not other devices are aware of the compromise?

Dave

-----Original Message-----
From: Bert Greevenbosch [mailto:[email-masked]] 
Sent: Thursday, June 13, 2013 8:49 PM
To: Kumar, Sandeep; Don Sturek; Keoh, Sye Loong; [email-masked]; [email-masked]; Zach Shelby
Subject: Re: [Dtls-iot] Current dtls-iot charter text - discuss...

Hi Sandeep,

-=- Quote -=-

Best regards,
Bert

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Sat, 15 Jun 2013 09:53:02 +0000

Agree with Dave. We need a better understanding of when and why revocation is required before we design a solution for it. We need to think more broadly in terms of the (secuirty)key lifecycle management in terms of bootstrapping, key-renewal and revocation since solutions will be interdependent on each other. Atleast we should avoid completely different solutions to the lifecycle otherwise they will all together not fit within a constrained device.

Sandeep

________________________________________
From: [email-masked] [[email-masked]] on behalf of Kemp, David P. [[email-masked]]
Sent: Friday, June 14, 2013 11:04 PM
To: [email-masked]
Subject: Re: [Dtls-iot] Current dtls-iot charter text - discuss...

Dave

-----Original Message-----
From: Bert Greevenbosch [mailto:[email-masked]]
Sent: Thursday, June 13, 2013 8:49 PM
To: Kumar, Sandeep; Don Sturek; Keoh, Sye Loong; [email-masked]; [email-masked]; Zach Shelby
Subject: Re: [Dtls-iot] Current dtls-iot charter text - discuss...

Hi Sandeep,

-=- Quote -=-

Best regards,
Bert

---

From: "Keoh, Sye Loong" <[email-masked]>
Date: Sat, 15 Jun 2013 16:44:53 +0000

Agree with Dave and Sandeep too.

In my opinion, the BOF/WG should focus on the immediate security needs, rather than aiming to solve all kinds of security problems in IoT at once.
 
Building on Sandeep's remark, SOLACE mailing list has been created to look at device lifecycle management, and "requirements" on device revocation can first be investigated there.

cheers
Sye Loong
________________________________________
From: [email-masked] [[email-masked]] on behalf of Kumar, Sandeep
Sent: Saturday, June 15, 2013 11:53 AM
To: Kemp, David P.; [email-masked]
Subject: Re: [Dtls-iot] Current dtls-iot charter text - discuss...

Sandeep

Dave

-----Original Message-----
From: Bert Greevenbosch [mailto:[email-masked]]
Sent: Thursday, June 13, 2013 8:49 PM
To: Kumar, Sandeep; Don Sturek; Keoh, Sye Loong; [email-masked]; [email-masked]; Zach Shelby
Subject: Re: [Dtls-iot] Current dtls-iot charter text - discuss...

Hi Sandeep,

-=- Quote -=-

Best regards,
Bert

---

From: Zach Shelby <[email-masked]>
Date: Sat, 15 Jun 2013 21:38:41 +0300

+1 

We should definitely focus on the low-hanging problems with fairly obvious solutions to have a successful BOF and first WG charter. 

Although SOLACE could be the right place to work on revocation issues, I wouldn't have any problems for folks to discuss and write drafts on better understanding those issues in DICE (in particular in relation to DTLS security modes useful in CoAP). But too early to say wether that would be suitable charter work for us in the future. As Dave pointed out well, we need to understand what the actual use cases and problems are. Interestingly enough, the OMA Lightweight M2M standard includes bootstrapping and provisioning features that could be used to solve some of the problem already (at least for its chosen device to cloud use case).  

Zach

---

From: Don Sturek <[email-masked]>
Date: Sat, 15 Jun 2013 09:59:39 -0700

I am curious in the use case cited by Dave Kemp how a controller for a
light bulb would even know to "simply refuse to key any "revoked"
devices...".

I think we should use 802.1ar as a guide and look at this as two issues:
 Authentication and Authorization.

For Authentication, once a device is manufactured, we should probably not
revoke its identity certificate.  There are a bunch of use cases (and
802.1ar and "device identity") that would point to infinite lifetime as a
solution.

The trickier issue is around Authorization.    If I buy a device that
turns out to be a clone, why should my device ever end up being unusable
to me?   I can see that others (service providers, utilties, etc.) might
never want to Authorize it for services they provide but I would like that
device to continue working in my home with my other local devices.

We can certainly ignore this interesting use case in DICE but I do believe
the topic will not go away (and I don't know of another group looking into
it specifically for IoT applications)

Don

On 6/15/13 9:44 AM, "Keoh, Sye Loong" <[email-masked]> wrote:

>In my opinion, the BOF/WG should focus on the immediate security needs,
>rather than aiming to solve all kinds of security problems in IoT at once.
> 
>Building on Sandeep's remark, SOLACE mailing list has been created to
>look at device lifecycle management, and "requirements" on device
>revocation can first be investigated there.
>
>cheers
>Sye Loong
>Agree with Dave. We need a better understanding of when and why
>revocation is required before we design a solution for it. We need to
>think more broadly in terms of the (secuirty)key lifecycle management in
>terms of bootstrapping, key-renewal and revocation since solutions will
>be interdependent on each other. Atleast we should avoid completely
>different solutions to the lifecycle otherwise they will all together not
>fit within a constrained device.
>
>Sandeep
>
>
>Before devoting much effort to this, a "requirements" document should lay
>out the use cases for revocation in an IoT environment.  The charter
>implies that DICE is applicable to hub-and-spoke communications where a
>constrained device needs to authenticate a controller and vice versa, not
>mesh communications where one light bulb would need to authenticate
>another light bulb.  As long as the controller is aware of which devices
>are no longer trustworthy, it can simply refuse to talk to them without
>distributing status information about all devices to all devices.
>
>In the multicast scenario there is even less case for revocation -
>multicast keys are distributed from a single point, which can simply
>refuse to key any "revoked" devices into the multicast group.
>
>Finally, under what circumstances would an IoT need to be revoked?
>People change names, affiliations, roles.  People lose their tokens.  But
>none of those reasons apply to devices.  If an adversary compromises the
>key of a device, sensor or actuator, what harm comes to the IoT if the
>controller but not other devices are aware of the compromise?
>
>Dave
>
>
>I agree that revocation is an important and often neglected topic.
>However before we can discuss revocation, we first need the DTLS protocol
>to be capable of being used for most IoT devices and networks. The  I-D
>submitted yesterday, draft-keoh-dtls-profile-iot-00.txt provides input to
>kick off this discussion. Once we have a IoT profiled DTLS protocol, we
>surely should think more seriously on revocation. The charter should
>focus to first fulfill this initial aim to make DTLS suitable for
>constrained environments otherwise we might end up spending lot of energy
>designing revocation techniques without any relevant protocol that would
>work within a constrained domain.
>-=- /Quote -=-
>
>I think we should not neglect revocation until the first phase is over.
>It is an important issue, and neglecting it now may cost us dearly in the
>future. For sound security, authentication and revocation are essential.
>
>Best regards,
>Bert
>

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 17 Jun 2013 16:56:10 +0000

Good point Don.

Infinite-lifetime manufacturer-provisioned asymmetric private keys are what I had in mind.  By "refuse to key" I meant refuse to negotiate a session key in both the unicast and multicast handshakes, which may or may not involve separation of Authn from Authz.  If the device supports a white list of multiple controllers, it could communicate separately with a utility and a local controller, and separate Authorization is not needed.  If the device supports only a single controller, then the one it trusts must establish session keys if at least one source of commands (utility, home, etc) wishes to talk to the device.

I can understand why a utility might not want to cede control over big loads to a local administrator, and why the local administrator would not want to lose control of the building if internet connectivity were lost.  Authorization in that situation could get interesting.

Dave

-----Original Message-----
From: Don Sturek [mailto:[email-masked]] 
Sent: Saturday, June 15, 2013 1:00 PM
To: Keoh, Sye Loong; Kumar, Sandeep; Kemp, David P.; [email-masked]
Subject: Re: [Dtls-iot] Current dtls-iot charter text - discuss...

I am curious in the use case cited by Dave Kemp how a controller for a light bulb would even know to "simply refuse to key any "revoked"
devices...".

For Authentication, once a device is manufactured, we should probably not revoke its identity certificate.  There are a bunch of use cases (and 802.1ar and "device identity") that would point to infinite lifetime as a solution.

The trickier issue is around Authorization.    If I buy a device that
turns out to be a clone, why should my device ever end up being unusable
to me?   I can see that others (service providers, utilties, etc.) might
never want to Authorize it for services they provide but I would like that device to continue working in my home with my other local devices.

We can certainly ignore this interesting use case in DICE but I do believe the topic will not go away (and I don't know of another group looking into it specifically for IoT applications)

Don

---

From: Rene Struik <[email-masked]>
Date: Mon, 17 Jun 2013 16:40:01 -0400

+1

For initial chartering purposes, I would also suggest to first focus on 
DTLS multicast and trimming off some fat off DTLS for coap usage.

(Of course, this should not stop people considering the full trust 
lifecycle, including provisioning, management of authorizations, and 
support for heterogeneous trust domains.)

Best regards, Rene

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363