idnits 2.17.1 draft-urien-core-identity-module-coap-06.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 -- The document date (June 2019) is 1774 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6347 (ref. 'DTLS') (Obsoleted by RFC 9147) == Outdated reference: A later version (-38) exists of draft-urien-eap-smartcard-37 Summary: 1 error (**), 0 flaws (~~), 2 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 June 2019 7 Expires: December 2019 9 Identity Modules for CoAP 10 draft-urien-core-identity-module-coap-06.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 December 2019. 47 . 49 Copyright Notice 51 Copyright (c) 2019 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 Table of Contents 65 Abstract........................................................... 1 66 Requirements Language.............................................. 1 67 Status of this Memo................................................ 1 68 Copyright Notice................................................... 2 69 1 Overview......................................................... 4 70 2 What is a Secure Element......................................... 4 71 3 Identity Module for CoAP......................................... 6 72 4 DTLS/TLS profile for CoAP security modules....................... 6 73 5 IANA Considerations.............................................. 6 74 6 References....................................................... 7 75 6.1 Normative References........................................ 7 76 6.2 Informative References...................................... 7 77 7 Authors' Addresses............................................... 7 78 1 Overview 80 The CoAP [RFC7252] protocol MAY be secured by the DTLS protocol 81 [DTLS] over an UDP/IP stack; the TLS support [TLS] is defined by 82 [RFC8323] over a TCP/IP stack. 84 According to [RFC7252] four security modes are available, NoSec, 85 PreSharedKey, RawPublicKey, and Certificate. When DTLS is used with 86 the PreShareKey or Certificate modes there is a need to store 87 secrets such as symmetric or asymmetric keys, which authenticate the 88 CoAP device. 90 In that case a Secure Element (SE) MAY be used in order to fully run 91 the DTLS or TLS protocol. According to the data throughput or other 92 security considerations the DTLS/TLS session MAY be exported from 93 the secure element after the exchange of the finished messages. 95 This class of Secure Element is referred by this draft as an 96 identity module (IdMod). 98 The expected benefits of identity modules are the following : 100 - Secure storage of pre-share keys or private keys 101 - Trusted simple or mutual authentication between the CoAP device 102 and the CoAP client. 103 - The device identity is enforced by a non cloneable identity 104 module. 105 - Trusted cryptographic support. 106 - Low power consumption for DTLS/TLS processing. 108 2 What is a Secure Element 110 A Secure Element (SE) is a tamper resistant microcontroller (see 111 figure 1) equipped with host interfaces such as [ISO7816], SPI 112 (Serial Peripheral Interface) or I2C (Inter Integrated Circuit). 114 The typical area size of these electronic chips is about 5x5 mm2. 115 They comprise CPU (8, 16, 32 bits), ROM (a few hundred KB), non 116 volatile memory (EEPROM, FLASH, a few hundred KB) and RAM (a few ten 117 KB). Security is enforced by multiple hardware and logical 118 countermeasures. 120 According to the [EUROSMART] association height billion of such 121 secure devices were shipped in 2013. Secure elements are widely 122 deployed for electronic payment (EMV cards), telecommunication (SIM 123 modules), identity (electronic passports), ticketing, and access 124 control (PKCS15 cards). 126 Most of secure elements include a Java Virtual Machine (JVM) and 127 therefore are able to execute embedded program written in the 128 JAVACARD language. Because these devices are dedicated to security 129 purposes they support numerous cryptographic resources such as 130 digest functions (MD5, SHA1, SHA2...), symmetric cipher (3xDES, AES) 131 or asymmetric procedures (RSA, ECC). 133 A set of Global Platform [GP] standards control the lifecycle of 134 embedded software, i.e. application downloading, activation and 135 deletion. 137 As an illustration a typical low cost Secure Element has the 138 following characteristics: 140 - JAVACARD operating system; 141 - Compliant with the GP (Global Platform) standards; 142 - 160 KB of ROM; 143 - 72 KB of EEPROM; 144 - 4KB of RAM; 145 - Embedded crypto-processor; 146 - 3xDES, AES, RSA, ECC; 147 - Certification according to Common Criteria (CC) EAL5+ level; 148 - Security Certificates from payment operators. 150 According to the state of art, TLS/DTLS stacks may run in secure 151 elements, for example written as a javacard applications. 153 +-----+ +-----+ +-----+ +---------------------+ 154 ISO <=>| IO | | CPU | | ROM | | Non Volatile Memory | 155 7816 +--+--+ +--+--+ +--+--+ +----------+----------+ 156 | | | | 157 ======+===+=====+=========+================+=+========== 158 | | | 159 +------+------+ +-----+-----+ +-------+-------+ 160 | Security | | Crypto | | Random Number | 161 | Register | | Processor | | Generator | 162 +-------------+ +-----------+ +---------------+ 164 Figure 1. A typical hardware architecture of a Secure Element 165 3 Identity Module for CoAP 167 Open 168 Open | Decrypt(CoAP) 169 | Send-Flight | | Encrypt(CoAP) 170 | | Recv-Flight | | | Close Reset 171 | | | Close | | | | | Process 172 | | | | | | | | | | 173 +-V-V-V-V-+ +--V-V-V-V--+ EAP over +- V----V--+ 174 TCP/ | Socket | DTLS/TLS | DTLS/TLS | ISO7816 | Identity | 175 UDP <=>| Agent | flights | ISO7816 | Messages | Module | 176 IP | | <======> | Agent | <=======> | | 177 +---------+ +-----------+ +----------+ 179 Figure 2. CoAP Identity module framework 181 ISO7816 interface for Secure Elements providing TLS/DTLS stacks are 182 detailed in [DTLS/TLS-SM]. The Identity module MUST support two 183 commands Reset and Process. 185 TLS/DTLS packets are transported by the EAP protocol over ISO7816 186 messages. This mechanism previously detailed by [EAPSC] provides a 187 double segmentation procedure thanks to EAP and ISO7816 facilities. 189 A DTLS/TLS-ISO7816 software agent sends and receives DTLS/TLS 190 flights to/from sockets over EAP/ISO7816 messages to/from the 191 identity module. Conceptually this component interface SHOULD have 192 four procedures Open, Close, Encrypt and Decrypt. 194 A socket software agent extracts and send DTLS/TLS flights from/to 195 UDP/TCP packets. Conceptually this component interface SHOULD have 196 four procedures Open, Close, Recv-Flight, Send-Flight. 198 4 DTLS/TLS profile for CoAP security modules 200 To be done. 202 5 IANA Considerations 204 This draft does not require any action from IANA. 206 6 References 208 6.1 Normative References 210 [TLS] Dierks, T., Rescorla, E., "The Transport Layer Security (TLS) 211 Protocol Version 1.1", RFC 5746, August 2008 213 [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 214 Security Version 1.2", RFC 6347, January 2012. 216 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 217 Application Protocol (CoAP)", RFC 7252, June 2014. 219 [RFC8323] CoAP (Constrained Application Protocol) over TCP, TLS, and 220 WebSockets, February 2018. 222 [ISO7816] ISO 7816, "Cards Identification - Integrated Circuit Cards 223 with Contacts", The International Organization for Standardization 224 (ISO). 226 6.2 Informative References 228 [GP] Global Platform Standards, http://www.globalplatform.org 230 [EUROSMART] The EUROSMART association, http://www.eurosmart.com 232 [DTLS/TLS-SM] Urien, P., "TLS and DTLS Security Modules", draft- 233 urien-uta-tls-dtls-security-module-08.txt, June 2019 235 [EAPSC] Urien, P., "EAP Support in Smartcard", draft-urien-eap- 236 smartcard-37.txt, June 2019 238 7 Authors' Addresses 240 Pascal Urien 241 Telecom ParisTech 242 23 avenue d'Italie 243 75013 Paris Phone: NA 244 France Email: Pascal.Urien@telecom-paristech.fr