idnits 2.17.1 draft-moskowitz-ssls-iot-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 3, 2017) is 2488 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.hares-i2nsf-ssls' is defined on line 177, but no explicit reference was found in the text == Unused Reference: 'RFC7401' is defined on line 187, but no explicit reference was found in the text == Unused Reference: 'RFC7402' is defined on line 192, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-hares-i2nsf-ssls-00 == Outdated reference: A later version (-24) exists of draft-ietf-hip-dex-05 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SSE BOF R. Moskowitz 3 Internet-Draft Huawei 4 Intended status: Standards Track S. Hares 5 Expires: January 4, 2018 Hickory Hill Consulting 6 L. Xia 7 Huawei 8 July 3, 2017 10 Secure Session Layer Services KMP via HIP 11 draft-moskowitz-ssls-iot-00 13 Abstract 15 This memo addresses the need for secure, end-to-end communications 16 from IoT devices to collectors, where the IoT devices many be too 17 resource constrained for typical IETF solutions or may be deployed 18 over non-IP networks (e.g. CAN FD, IEEE 802.15.6, serial SCADA). 19 For such deployments, the Secure Session Layer Service [draft-hares- 20 ssls-00] the needed, and sufficient features to ensure successful and 21 safe communications. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 4, 2018. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 60 2.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Minimal feature set . . . . . . . . . . . . . . . . . . . . . 3 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 65 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 68 7.2. Informative References . . . . . . . . . . . . . . . . . 5 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 71 1. Introduction 73 The IETF has a plethora of security solutions targeted at IoT. Yet 74 all too many IoT products are deployed with no or improperly 75 configured security. In particular resource constrained IoT devices 76 and non-IP IoT networks have not been well served in the IETF. 78 This effort focuses on a minimal-to-have set of security features and 79 related communications functions for these special, yet rather common 80 collection of IoT devices. This effort need not be restricted to 81 these special cases; it will work for any IoT device on any network. 82 The goal is that all are serviced and protected. 84 A IoT device can be resource constrained by its CPU, memory, and/or 85 power. Any one of these could result in non-applicablity of common 86 secure communications tools. All three together occurs in many 87 devices. The IoT network can be constrained by bandwidth, MTU, and/ 88 or high packet loss. An additional set of constraints can be legal; 89 in terms of mandated end-to-end privacy (e.g. HIPPA). 91 All this points to a need for a constrained solution for constrained 92 environments. 94 2. Terms and Definitions 96 2.1. Requirements Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 2.2. Notations 104 This section will contain notations 106 2.3. Definitions 108 TBD 110 3. Minimal feature set 112 Minimal still implies something done. In this case that something 113 is: 115 Secure communications envelope: The data on the 'wire' must at least 116 have a cryptographic integrity check and optionally content 117 privacy. 119 Security key management: The keying material for securing the 120 communications envelope must be fresh and unique. 122 Unique device Identity: The device must have an Identity that 123 uniquely identifies it in a trusted manner. 125 Minimal means the least amount of tools and one for each function, 126 with perhaps one for many functions. Much of this is standard, but 127 later will be shown how to minimize its size and performance impact. 129 ECC for Identity: An Eliptic Curve public key can be the base of the 130 Identity. 132 ECC key management: ECC can be 'reused' for the key management 133 protocol. 135 Symmetric cryptography for message protection: Four functions are 136 needed: privacy, integrity, hashing, randomness. 138 Message management: Three functions are needed: data chunking, 139 message fragmentation/reassembly, and receipt acknowledgment. 140 Data compression is an optional fourth function. 142 ECC has been perceived as still too much. It does set a barrier of 143 an 8-bit CPU, time and memory. ECDH based on ECC25519 [RFC7748] has 144 been implemented on 8-bit CPUs, running 9 seconds. 146 HIP DEX [I-D.ietf-hip-dex] is a minimalist KMP and defined for 147 application use in [I-D.moskowitz-ssls-hip]. 149 The Secure Session Layer Services (SSLS) [draft-hares-ssls-00] 150 provides a well defined session layer that can be implemented in any 151 application to provide any or all of the following: 153 o data compression 155 o chunking of data 157 o secure envelope 159 o fragmentation and reassembly 161 4. IANA Considerations 163 TBD. May be nothing for IANA. 165 5. Security Considerations 167 TBD. 169 6. Acknowledgments 171 TBD 173 7. References 175 7.1. Normative References 177 [I-D.hares-i2nsf-ssls] 178 Hares, S. and R. Moskowitz, "Secure Session Layer 179 Services", draft-hares-i2nsf-ssls-00 (work in progress), 180 March 2016. 182 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 183 Requirement Levels", BCP 14, RFC 2119, 184 DOI 10.17487/RFC2119, March 1997, 185 . 187 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 188 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 189 RFC 7401, DOI 10.17487/RFC7401, April 2015, 190 . 192 [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the 193 Encapsulating Security Payload (ESP) Transport Format with 194 the Host Identity Protocol (HIP)", RFC 7402, 195 DOI 10.17487/RFC7402, April 2015, 196 . 198 7.2. Informative References 200 [I-D.ietf-hip-dex] 201 Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", 202 draft-ietf-hip-dex-05 (work in progress), February 2017. 204 [I-D.moskowitz-ssls-hip] 205 Moskowitz, R., Xia, L., Faynberg, I., Hares, S., and P. 206 Giacomin, "Secure Session Layer Services KMP via HIP", 207 draft-moskowitz-ssls-hip-02 (work in progress), June 2017. 209 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 210 for Security", RFC 7748, DOI 10.17487/RFC7748, January 211 2016, . 213 Authors' Addresses 215 Robert Moskowitz 216 Huawei 217 Oak Park, MI 48237 219 Email: rgm@labs.htt-consult.com 221 Susan Hares 222 Hickory Hill Consulting 223 7453 Hickory Hill 224 Saline, MI 48176 225 USA 227 Email: shares@ndzh.com 228 Liang Xia 229 Huawei 230 No. 101, Software Avenue, Yuhuatai District 231 Nanjing 232 China 234 Email: Frank.xialiang@huawei.com