[Dtls-iot] Current dtls-iot charter text

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.

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