idnits 2.17.1 draft-urien-core-identity-module-coap-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'CoAP' is mentioned on line 88, but not defined == Unused Reference: 'RFC7252' is defined on line 226, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6347 (ref. 'DTLS') (Obsoleted by RFC 9147) == Outdated reference: A later version (-11) exists of draft-ietf-core-coap-tcp-tls-02 == Outdated reference: A later version (-38) exists of draft-urien-eap-smartcard-34 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CORE Working Group P. Urien 3 Internet Draft Telecom ParisTech 4 Intended status: Experimental 6 December 23 2017 7 Expires: June 2018 9 Identity Modules for CoAP 10 draft-urien-core-identity-module-coap-03.txt 12 Abstract 14 This document defines identity modules based on Secure Elements 15 processing DTLS/TLS stacks for CoAP devices. The expected benefits 16 of these secure microcontrollers are the following : 17 - Secure storage of pre-share keys or private keys 18 - Trusted simple or mutual authentication between CoAP devices and 19 CoAP clients. 20 - The device identity is enforced by a non cloneable chip. 21 - Trusted cryptographic support. 22 - Low power consumption for DTLS/TLS processing. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six 41 months and may be updated, replaced, or obsoleted by other documents 42 at any time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on June 2018. 47 . 49 Copyright Notice 51 Copyright (c) 2017 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with 59 respect to this document. Code Components extracted from this 60 document must include Simplified BSD License text as described in 61 Section 4.e of the Trust Legal Provisions and are provided without 62 warranty as described in the Simplified BSD License. 64 Identity Modules for CoAP December 2017 66 Table of Contents 67 Abstract........................................................... 1 68 Requirements Language.............................................. 1 69 Status of this Memo................................................ 1 70 Copyright Notice................................................... 2 71 1 Overview......................................................... 4 72 2 What is a Secure Element......................................... 4 73 3 Identity Module for CoAP......................................... 6 74 4 DTLS/TLS profile for CoAP security modules....................... 6 75 5 IANA Considerations.............................................. 6 76 6 References....................................................... 7 77 6.1 Normative References........................................ 7 78 6.2 Informative References...................................... 7 79 7 Authors' Addresses............................................... 7 80 Identity Modules for CoAP December 2017 82 1 Overview 84 The CoAP [CoAP] protocol MAY be secured by the DTLS protocol [DTLS] 85 over an UDP/IP stack; the TLS support [TLS] is also under definition 86 [CoAP-TLS] over a TCP/IP stack. 88 According to [CoAP] four security modes are available, NoSec, 89 PreSharedKey, RawPublicKey, and Certificate. When DTLS is used with 90 the PreShareKey or Certificate modes there is a need to store 91 secrets such as symmetric or asymmetric keys, which authenticate the 92 CoAP device. 94 In that case a Secure Element (SE) MAY be used in order to fully run 95 the DTLS or TLS protocol. According to the data throughput or other 96 security considerations the DTLS/TLS session MAY be exported from 97 the secure element after the exchange of the finished messages. 99 This class of Secure Element is referred by this draft as an 100 identity module (IdMod). 102 The expected benefits of identity modules are the following : 104 - Secure storage of pre-share keys or private keys 105 - Trusted simple or mutual authentication between the CoAP device 106 and the CoAP client. 107 - The device identity is enforced by a non cloneable identity 108 module. 109 - Trusted cryptographic support. 110 - Low power consumption for DTLS/TLS processing. 112 2 What is a Secure Element 114 A Secure Element (SE) is a tamper resistant microcontroller (see 115 figure 1) equipped with host interfaces such as [ISO7816], SPI 116 (Serial Peripheral Interface) or I2C (Inter Integrated Circuit). 118 The typical area size of these electronic chips is about 5x5 mm2. 119 They comprise CPU (8, 16, 32 bits), ROM (a few hundred KB), non 120 volatile memory (EEPROM, FLASH, a few hundred KB) and RAM (a few ten 121 KB). Security is enforced by multiple hardware and logical 122 countermeasures. 124 According to the [EUROSMART] association height billion of such 125 secure devices were shipped in 2013. Secure elements are widely 126 deployed for electronic payment (EMV cards), telecommunication (SIM 127 modules), identity (electronic passports), ticketing, and access 128 control (PKCS15 cards). 130 Most of secure elements include a Java Virtual Machine (JVM) and 131 therefore are able to execute embedded program written in the 132 JAVACARD language. Because these devices are dedicated to security 133 Identity Modules for CoAP December 2017 135 purposes they support numerous cryptographic resources such as 136 digest functions (MD5, SHA1, SHA2...), symmetric cipher (3xDES, AES) 137 or asymmetric procedures (RSA, ECC). 139 A set of Global Platform [GP] standards control the lifecycle of 140 embedded software, i.e. application downloading, activation and 141 deletion. 143 As an illustration a typical low cost Secure Element has the 144 following characteristics: 146 - JAVACARD operating system; 147 - Compliant with the GP (Global Platform) standards; 148 - 160 KB of ROM; 149 - 72 KB of EEPROM; 150 - 4KB of RAM; 151 - Embedded crypto-processor; 152 - 3xDES, AES, RSA, ECC; 153 - Certification according to Common Criteria (CC) EAL5+ level; 154 - Security Certificates from payment operators. 156 According to the state of art, TLS/DTLS stacks may run in secure 157 elements, for example written as a javacard applications. 159 +-----+ +-----+ +-----+ +---------------------+ 160 ISO <=>| IO | | CPU | | ROM | | Non Volatile Memory | 161 7816 +--+--+ +--+--+ +--+--+ +----------+----------+ 162 | | | | 163 ======+===+=====+=========+================+=+========== 164 | | | 165 +------+------+ +-----+-----+ +-------+-------+ 166 | Security | | Crypto | | Random Number | 167 | Register | | Processor | | Generator | 168 +-------------+ +-----------+ +---------------+ 170 Figure 1. A typical hardware architecture of a Secure Element 171 Identity Modules for CoAP December 2017 173 3 Identity Module for CoAP 175 Open 176 Open | Decrypt(CoAP) 177 | Send-Flight | | Encrypt(CoAP) 178 | | Recv-Flight | | | Close Reset 179 | | | Close | | | | | Process 180 | | | | | | | | | | 181 +-V-V-V-V-+ +--V-V-V-V--+ EAP over +- V----V--+ 182 TCP/ | Socket | DTLS/TLS | DTLS/TLS | ISO7816 | Identity | 183 UDP <=>| Agent | flights | ISO7816 | Messages | Module | 184 IP | | <======> | Agent | <=======> | | 185 +---------+ +-----------+ +----------+ 187 Figure 2. CoAP Identity module framework 189 ISO7816 interface for Secure Elements providing TLS/DTLS stacks are 190 detailed in [DTLS/TLS-SM]. The Identity module MUST support two 191 commands Reset and Process. 193 TLS/DTLS packets are transported by the EAP protocol over ISO7816 194 messages. This mechanism previously detailed by [EAPSC] provides a 195 double segmentation procedure thanks to EAP and ISO7816 facilities. 197 A DTLS/TLS-ISO7816 software agent sends and receives DTLS/TLS 198 flights to/from sockets over EAP/ISO7816 messages to/from the 199 identity module. Conceptually this component interface SHOULD have 200 four procedures Open, Close, Encrypt and Decrypt. 202 A socket software agent extracts and send DTLS/TLS flights from/to 203 UDP/TCP packets. Conceptually this component interface SHOULD have 204 four procedures Open, Close, Recv-Flight, Send-Flight. 206 4 DTLS/TLS profile for CoAP security modules 208 To be done. 210 5 IANA Considerations 212 This draft does not require any action from IANA. 214 Identity Modules for CoAP December 2017 216 6 References 218 6.1 Normative References 220 [TLS] Dierks, T., Rescorla, E., "The Transport Layer Security (TLS) 221 Protocol Version 1.1", RFC 5746, August 2008 223 [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 224 Security Version 1.2", RFC 6347, January 2012. 226 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 227 Application Protocol (CoAP)", RFC 7252, June 2014. 229 [CoAP-TLS] A TCP and TLS Transport for the Constrained Application 230 Protocol (CoAP), draft-ietf-core-coap-tcp-tls-02, April 2016. 232 [ISO7816] ISO 7816, "Cards Identification - Integrated Circuit Cards 233 with Contacts", The International Organization for Standardization 234 (ISO). 236 6.2 Informative References 238 [GP] Global Platform Standards, http://www.globalplatform.org 240 [EUROSMART] The EUROSMART association, http://www.eurosmart.com 242 [DTLS/TLS-SM] Urien, P., "TLS and DTLS Security Modules", draft- 243 urien-uta-tls-dtls-security-module-05.txt, December 2017 245 [EAPSC] Urien, P., "EAP Support in Smartcard", draft-urien-eap- 246 smartcard-34.txt, December 2017 248 7 Authors' Addresses 250 Pascal Urien 251 Telecom ParisTech 252 23 avenue d'Italie 253 75013 Paris Phone: NA 254 France Email: Pascal.Urien@telecom-paristech.fr