SSE BOF R. Moskowitz
Internet-Draft Huawei
Intended status: Standards Track S. Hares
Expires: January 4, 2018 Hickory Hill Consulting
L. Xia
Huawei
July 3, 2017
Secure Session Layer Services KMP via HIP
draft-moskowitz-ssls-iot-00
Abstract
This memo addresses the need for secure, end-to-end communications
from IoT devices to collectors, where the IoT devices many be too
resource constrained for typical IETF solutions or may be deployed
over non-IP networks (e.g. CAN FD, IEEE 802.15.6, serial SCADA).
For such deployments, the Secure Session Layer Service [draft-hares-
ssls-00] the needed, and sufficient features to ensure successful and
safe communications.
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 January 4, 2018.
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
Moskowitz, et al. Expires January 4, 2018 [Page 1]
Internet-Draft SSLS kmp via HIP July 2017
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
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3
2.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
3. Minimal feature set . . . . . . . . . . . . . . . . . . . . . 3
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
7.1. Normative References . . . . . . . . . . . . . . . . . . 4
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
The IETF has a plethora of security solutions targeted at IoT. Yet
all too many IoT products are deployed with no or improperly
configured security. In particular resource constrained IoT devices
and non-IP IoT networks have not been well served in the IETF.
This effort focuses on a minimal-to-have set of security features and
related communications functions for these special, yet rather common
collection of IoT devices. This effort need not be restricted to
these special cases; it will work for any IoT device on any network.
The goal is that all are serviced and protected.
A IoT device can be resource constrained by its CPU, memory, and/or
power. Any one of these could result in non-applicablity of common
secure communications tools. All three together occurs in many
devices. The IoT network can be constrained by bandwidth, MTU, and/
or high packet loss. An additional set of constraints can be legal;
in terms of mandated end-to-end privacy (e.g. HIPPA).
All this points to a need for a constrained solution for constrained
environments.
Moskowitz, et al. Expires January 4, 2018 [Page 2]
Internet-Draft SSLS kmp via HIP July 2017
2. Terms and Definitions
2.1. Requirements 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.2. Notations
This section will contain notations
2.3. Definitions
TBD
3. Minimal feature set
Minimal still implies something done. In this case that something
is:
Secure communications envelope: The data on the 'wire' must at least
have a cryptographic integrity check and optionally content
privacy.
Security key management: The keying material for securing the
communications envelope must be fresh and unique.
Unique device Identity: The device must have an Identity that
uniquely identifies it in a trusted manner.
Minimal means the least amount of tools and one for each function,
with perhaps one for many functions. Much of this is standard, but
later will be shown how to minimize its size and performance impact.
ECC for Identity: An Eliptic Curve public key can be the base of the
Identity.
ECC key management: ECC can be 'reused' for the key management
protocol.
Symmetric cryptography for message protection: Four functions are
needed: privacy, integrity, hashing, randomness.
Message management: Three functions are needed: data chunking,
message fragmentation/reassembly, and receipt acknowledgment.
Data compression is an optional fourth function.
Moskowitz, et al. Expires January 4, 2018 [Page 3]
Internet-Draft SSLS kmp via HIP July 2017
ECC has been perceived as still too much. It does set a barrier of
an 8-bit CPU, time and memory. ECDH based on ECC25519 [RFC7748] has
been implemented on 8-bit CPUs, running 9 seconds.
HIP DEX [I-D.ietf-hip-dex] is a minimalist KMP and defined for
application use in [I-D.moskowitz-ssls-hip].
The Secure Session Layer Services (SSLS) [draft-hares-ssls-00]
provides a well defined session layer that can be implemented in any
application to provide any or all of the following:
o data compression
o chunking of data
o secure envelope
o fragmentation and reassembly
4. IANA Considerations
TBD. May be nothing for IANA.
5. Security Considerations
TBD.
6. Acknowledgments
TBD
7. References
7.1. Normative References
[I-D.hares-i2nsf-ssls]
Hares, S. and R. Moskowitz, "Secure Session Layer
Services", draft-hares-i2nsf-ssls-00 (work in progress),
March 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
Moskowitz, et al. Expires January 4, 2018 [Page 4]
Internet-Draft SSLS kmp via HIP July 2017
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015,
<http://www.rfc-editor.org/info/rfc7401>.
[RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the
Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", RFC 7402,
DOI 10.17487/RFC7402, April 2015,
<http://www.rfc-editor.org/info/rfc7402>.
7.2. Informative References
[I-D.ietf-hip-dex]
Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)",
draft-ietf-hip-dex-05 (work in progress), February 2017.
[I-D.moskowitz-ssls-hip]
Moskowitz, R., Xia, L., Faynberg, I., Hares, S., and P.
Giacomin, "Secure Session Layer Services KMP via HIP",
draft-moskowitz-ssls-hip-02 (work in progress), June 2017.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <http://www.rfc-editor.org/info/rfc7748>.
Authors' Addresses
Robert Moskowitz
Huawei
Oak Park, MI 48237
Email: rgm@labs.htt-consult.com
Susan Hares
Hickory Hill Consulting
7453 Hickory Hill
Saline, MI 48176
USA
Email: shares@ndzh.com
Moskowitz, et al. Expires January 4, 2018 [Page 5]
Internet-Draft SSLS kmp via HIP July 2017
Liang Xia
Huawei
No. 101, Software Avenue, Yuhuatai District
Nanjing
China
Email: Frank.xialiang@huawei.com
Moskowitz, et al. Expires January 4, 2018 [Page 6]