Internet DRAFT - draft-schmertmann-dice-codtls
draft-schmertmann-dice-codtls
Network Working Group L. Schmertmann
Internet-Draft K. Hartke
Intended status: Informational C. Bormann, Ed.
Expires: February 16, 2015 Universitaet Bremen TZI
August 15, 2014
CoDTLS: DTLS handshakes over CoAP
draft-schmertmann-dice-codtls-01
Abstract
The Datagram Transport Layer Security protocol, DTLS, is usually
transported over UDP. In Constrained Node Networks, there may be
considerable limitations on the packet delivery rates and on
practically usable packet sizes. Applications often can control the
size and retransmission requirements of their data packets, but the
DTLS handshake is out of scope for such application optimizations.
This specification defines how to perform a DTLS handshake on top of
the CoAP protocol. The resulting DTLS connection may then be used
for instance for transporting CoAP, or as a source of keying
material. The latter case is particularly interesting if the CoAP
exchanges transporting the DTLS handshake messages traverse CoAP
proxies.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 16, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Schmertmann, et al. Expires February 16, 2015 [Page 1]
Internet-Draft CoDTLS August 2014
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Stateless Compression . . . . . . . . . . . . . . . . . . . . 3
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5.1. Media Types ("MIME Type") . . . . . . . . . . . . . . . . 7
5.2. CoAP Content-Formats . . . . . . . . . . . . . . . . . . 9
5.3. Link relation . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
Constrained nodes in constrained node networks [RFC7228] often need
robust security. The Constrained Application Protocol (CoAP),
[RFC7252], has chosen DTLS as the protocol to be used for
communication security between CoAP nodes. DTLS was defined without
special considerations for the capabilities of constrained nodes.
The packets are relatively verbose, and the error control mechanisms
and parameters work best in a typical Ethernet-like environment.
[I-D.hartke-core-codtls] proposes to mitigate these problems by
running the DTLS handshake over CoAP. The present document discusses
such a protocol in more detail, based on an initial implementation
that was tested on MC13224-based constrained nodes (ARM7TDMI, 96 KiB
RAM shared for both code and data filled from serial flash).
Schmertmann, et al. Expires February 16, 2015 [Page 2]
Internet-Draft CoDTLS August 2014
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Stateless Compression
DTLS handshake messages are carried in CoAP bodies exchanged in CoAP
requests and responses, possibly sliced up by the block protocol
[I-D.ietf-core-block]. Each body is of a media type (Content-Format)
that can contain multiple concatenated handshake messages. Along the
lines of a compression scheme also defined in
[I-D.hartke-core-codtls], the DTLS header is compressed as follows:
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch; // New field
uint48 sequence_number; // New field
uint16 length;
opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext;
enum {
change_cipher_spec(20), alert(21), handshake(22),
application_data(23), (255)
} ContentType;
->
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| T | V | E |1 1 0| S | L |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For T = 0, the initial header is followed by an 8-bit field for the
"type". T = 1 compactly encodes the "type" value "alert" (21), T = 2
stands for "handshake" (22), T = 3 for "application_data" (23). (Not
that "change_cipher_spec" is transported in a different way.)
For V = 1, this is followed by a two-byte field for the "version".
For V = 0, version is 254.255 (TLS 1.0), for V = 2 version is 254.253
(TLS 1.2), and V = 3 is reserved.
E encodes the epoch directly (0..4), 5 or 6 specifies that an 8 or
16-bit field followed. The value 7 is only allowed for handshake
Schmertmann, et al. Expires February 16, 2015 [Page 3]
Internet-Draft CoDTLS August 2014
packets following another handshake packet in a CoAP body, it means
the epoch is copied from the previous handshake packet in the same
body.
S encodes the sequence number. For values 1 to 6, the sequence
number is attached in 1 to 6 bytes, respectively. Value 0 means the
sequence number is not sent at all. Value 7 again refers to the
preceding handshake packet in the same body, adding one to the
sequence number used there.
L encodes the length. For values 1 and 2, the length is attached in
1 or 2 bytes. For value 3, the length is the remaining length of the
payload. Value 0 is reserved.
Within a handshake payload, multiple handshake messages are
concatenated, each preceded by a short header:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| T | L |
+-+-+-+-+-+-+-+-+
T defines the handshake type (with two values special-cased: 32 for
change_cipher_spec and 33 for alert). L is the number of bytes that
follow and give the length; 0 stands for length 0, 1 and 2 for 1 or 2
bytes following giving the length, and 3 standing for the rest of the
handshake payload. Note that this format does not address the
fragmentation mechanism provided by DTLS, as the assumption is this
will not be required in DTLS handshakes performed by constrained
nodes.
3. Operation
To offer DTLS over CoAP, a CoAP server provides a resource that
accepts the media types defined in this section, identified by the
content-formats in Section 5.2. The specific URI of the resource is
up to the server. (In the examples, we are assuming it is at the
root of the server, i.e., no Uri-Path options are sent.) The client
learns the URI using the usual discovery processes, e.g., the CoRE
resource directory [I-D.ietf-core-resource-directory].
The client sends the client hello as an application/dtls-hello
payload in a POST request to the DTLS URI of the server. The server
MUST NOT accept Block1 options on requests carrying application/dtls-
hello hello payloads unless it can already verify a cookie from the
first block. (This means that both a cookieless ClientHello request,
and the part of a cookied ClientHello that contains the cookie, need
Schmertmann, et al. Expires February 16, 2015 [Page 4]
Internet-Draft CoDTLS August 2014
to fit into a single UDP packet of an appropriate size. The server
needs to dimension its cookies accordingly.)
Once the client hello is accepted, the server builds state, as
indicated in Location options in the 2.01 created response. The
client switches to PATCHing that state using application/dtls-
handshake messages. Instead of creating a separate resource for
this, the client simply continues sending to the same DTLS resource.
(Alternatively, the server could send back a URI for a new resource
from the first successful POST exchange. This is not implemented in
the current code, but will be required for operation through
proxies.)
Figure 1 shows an example message exchange. The PATCH method is
currently implemented as a POST, awaiting a PATCH method registration
for CoAP.
Schmertmann, et al. Expires February 16, 2015 [Page 5]
Internet-Draft CoDTLS August 2014
Client Server
------ ------
POST /
ClientHello ----->
4.01 Unauthorized
<----- HelloVerifyRequest
POST /
ClientHello ----->
2.01 Created /dCST0E
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<----- ServerHelloDone
PATCH /dCST0E
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished ----->
2.04 Changed
[ChangeCipherSpec]
<----- Finished
Figure 1: Message Flights for Full Handshake
Table 1 shows the implementation size of the current demonstrator
implementation. Assuming that a CoAP library is already available,
around 7.2 KiB are required for the entire CoDTLS implementation.
(Note that the specific CoAP library in use required about 2134 bytes
additional code to implement all the CoAP features required,
including Block1, and some management code.) The implementation can
operate with 2.0 KiB stack size.
Schmertmann, et al. Expires February 16, 2015 [Page 6]
Internet-Draft CoDTLS August 2014
+------------+--------------------------------------+
| Size (KiB) | Function |
+------------+--------------------------------------+
| 2.41 | ECC functions |
| 0.95 | AES modes (CCM + CMAC) |
| 0.80 | Storage management |
| 0.79 | Session management |
| 0.15 | PRF |
| 1.78 | CoAP Resource implementing handshake |
| 0.32 | Parse & Send |
+------------+--------------------------------------+
Table 1: Code sizes in demonstrator implementation
4. Discussion
An alternative approach to the DTLS tunneling described here is to
directly use the TLS handshake [RFC5246], as all prerequisites are
already available in the reliability mechanisms provided by CoAP.
However, this would require the addition of a DoS countermeasure,
which in turn might be a useful component beyond the usage in this
specification. Also, if it is desired to directly use the DTLS
record layer after a CoAP-mediated handshake, the details of the
transition from TLS to DTLS need to be specified.
5. IANA Considerations
This specification defines two new Internet media types [RFC6838]:
o application/dtls-hello
o application/dtls-handshake
This specification also defines the entries in the Content-Format
registry for these new media types.
5.1. Media Types ("MIME Type")
The Internet media type [RFC6838] for a DTLS hello is application/
dtls-hello.
Type name: application
Subtype name: dtls-hello
Required parameters: n/a
Optional parameters: n/a
Schmertmann, et al. Expires February 16, 2015 [Page 7]
Internet-Draft CoDTLS August 2014
Encoding considerations: binary
Security considerations: See Section 6 of this document
Interoperability considerations: n/a
Published specification: This document
Applications that use this media type: Setup of DTLS sessions over
CoAP
Additional information:
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/a
Person & email address to contact for further information:
Carsten Bormann
cabo@tzi.org
Intended usage: COMMON
Restrictions on usage: none
Author:
Carsten Bormann <cabo@tzi.org>
Change controller:
The IESG <iesg@ietf.org>
The Internet media type [RFC6838] for a DTLS handshake message is
application/dtls-handshake.
Type name: application
Subtype name: dtls-hello
Required parameters: n/a
Optional parameters: n/a
Encoding considerations: binary
Security considerations: See Section 6 of this document
Interoperability considerations: n/a
Published specification: This document
Schmertmann, et al. Expires February 16, 2015 [Page 8]
Internet-Draft CoDTLS August 2014
Applications that use this media type: Setup of DTLS sessions over
CoAP
Additional information:
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/a
Person & email address to contact for further information:
Carsten Bormann
cabo@tzi.org
Intended usage: COMMON
Restrictions on usage: none
Author:
Carsten Bormann <cabo@tzi.org>
Change controller:
The IESG <iesg@ietf.org>
5.2. CoAP Content-Formats
Media Type: application/dtls-hello
Encoding: -
Id: TBD1
Reference: [RFC-THIS-SPEC]
Media Type: application/dtls-handshake
Encoding: -
Id: TBD2
Reference: [RFC-THIS-SPEC]
5.3. Link relation
TBD: There needs to be a way to find DTLS resources on a server,
e.g., in a resource directory. This is usually done by defining an
appropriate link relation.
Schmertmann, et al. Expires February 16, 2015 [Page 9]
Internet-Draft CoDTLS August 2014
6. Security Considerations
The security considerations of [RFC6347] and [RFC7252] apply.
In its main part, this specification provides a way to carry around
DTLS packets. Under the Internet Threat Model, those packets already
traverse unsecured networks, so any attack that could be used to
subvert DTLS packets sent over CoAP could already be used to subvert
the DTLS packets when sent over traditional transports. Obviously
implementers still need to implement the DTLS state machine fully.
In addition, if the CoAP exchanges run over unsecured channels, those
channels will need to be made robust to the usual attacks.
If the option is chosen to derive the Finished MACs from the CoAP
representation, much more substantial security analysis is required,
and this section will need to discuss its security considerations.
7. Acknowledgements
Olaf Bergmann is a co-author of the base specification this
implementation has been derived from.
8. References
8.1. Normative References
[I-D.ietf-core-block]
Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP",
draft-ietf-core-block-15 (work in progress), July 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, June 2014.
8.2. Informative References
[I-D.hartke-core-codtls]
Hartke, K. and O. Bergmann, "Datagram Transport Layer
Security in Constrained Environments", draft-hartke-core-
codtls-02 (work in progress), July 2012.
Schmertmann, et al. Expires February 16, 2015 [Page 10]
Internet-Draft CoDTLS August 2014
[I-D.ietf-core-resource-directory]
Shelby, Z., Bormann, C., and S. Krco, "CoRE Resource
Directory", draft-ietf-core-resource-directory-01 (work in
progress), December 2013.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, RFC
6838, January 2013.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, May 2014.
Authors' Addresses
Lars Schmertmann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Email: lars@tzi.de
Klaus Hartke
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63905
Email: hartke@tzi.org
Carsten Bormann (editor)
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org
Schmertmann, et al. Expires February 16, 2015 [Page 11]
