Identity Modules for CoAP
draft-urien-core-identity-module-coap-02
|
| Document |
Type |
|
Active Internet-Draft (individual)
|
|
Last updated |
|
2017-06-23
|
|
Stream |
|
(None)
|
|
Intended RFC status |
|
(None)
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
Stream state |
|
(No stream defined) |
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
| IESG |
IESG state |
|
I-D Exists
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
CORE Working Group P. Urien
Internet Draft Telecom ParisTech
Intended status: Experimental
June 22 2017
Expires: December 2017
Identity Modules for CoAP
draft-urien-core-identity-module-coap-02.txt
Abstract
This document defines identity modules based on Secure Elements
processing DTLS/TLS stacks for CoAP devices. The expected benefits
of these secure microcontrollers are the following :
- Secure storage of pre-share keys or private keys
- Trusted simple or mutual authentication between CoAP devices and
CoAP clients.
- The device identity is enforced by a non cloneable chip.
- Trusted cryptographic support.
- Low power consumption for DTLS/TLS processing.
Requirements Language
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.
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 December 2017.
.
Urien Expires June 2017 [Page 1]
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Urien Expires December 2017 [page 2]
Identity Modules for CoAP June 2017
Table of Contents
Abstract........................................................... 1
Requirements Language.............................................. 1
Status of this Memo................................................ 1
Copyright Notice................................................... 2
1 Overview......................................................... 4
2 What is a Secure Element......................................... 4
3 Identity Module for CoAP......................................... 6
4 DTLS/TLS profile for CoAP security modules....................... 6
5 IANA Considerations.............................................. 6
6 References....................................................... 7
6.1 Normative References........................................ 7
6.2 Informative References...................................... 7
7 Authors' Addresses............................................... 7
Urien Expires December 2017 [Page 3]
Identity Modules for CoAP June 2017
1 Overview
The CoAP [CoAP] protocol MAY be secured by the DTLS protocol [DTLS]
over an UDP/IP stack; the TLS support [TLS] is also under definition
[CoAP-TLS] over a TCP/IP stack.
According to [CoAP] four security modes are available, NoSec,
PreSharedKey, RawPublicKey, and Certificate. When DTLS is used with
the PreShareKey or Certificate modes there is a need to store
secrets such as symmetric or asymmetric keys, which authenticate the
CoAP device.
In that case a Secure Element (SE) MAY be used in order to fully run
the DTLS or TLS protocol. According to the data throughput or other
security considerations the DTLS/TLS session MAY be exported from
the secure element after the exchange of the finished messages.
Show full document text