﻿<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ 
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
 <?rfc toc="yes" ?>
 <?rfc symrefs="yes" ?>
 <?rfc sortrefs="yes"?> 
 <?rfc compact="yes" ?>
 <?rfc subcompact="no" ?>  
 <?rfc iprnotified="no" ?>
  <?rfc strict="no" ?>

<rfc category="std" docName="draft-moskowitz-ssls-iot-00" ipr="trust200902">
 <front>
<title abbrev="SSLS kmp via HIP">Secure Session Layer Services KMP via HIP</title>
	<author fullname="Robert Moskowitz" initials="R." surname="Moskowitz" >
	<organization>Huawei</organization>
	<address>
	<postal> 
	  <street> </street>
	  <city>Oak Park</city>
	  <region>MI</region>
	  <code>48237</code> 
	</postal>
	<email>rgm@labs.htt-consult.com</email>
	</address>
	</author>
	<author fullname="Susan Hares" initials="S." surname="Hares">
	<organization>Hickory Hill Consulting</organization>
	<address>
	<postal> 
	  <street>7453 Hickory Hill</street>
	  <city>Saline</city>
	  <region>MI</region>
	  <code>48176</code>
	  <country>USA</country>
	</postal>
	<email>shares@ndzh.com</email>
	</address>
	</author>
    <author fullname="Liang Xia" initials="L." surname="Xia">
        <organization>Huawei</organization>
        <address>
        <postal>
        <street>No. 101, Software Avenue, Yuhuatai District</street>
        <city>Nanjing</city>
        <country>China</country>
        </postal>
        <phone></phone>
        <email>Frank.xialiang@huawei.com</email>
        </address>
    </author>
<date year="2017"/>
   <area>Security Area</area>
   <workgroup>SSE BOF</workgroup>
    <keyword>RFC</keyword>
     <keyword>Request for Comments</keyword>
     <keyword>I-D</keyword>
     <keyword>Internet-Draft</keyword>
     <keyword>SSLS</keyword>
     <keyword>HIP</keyword>
     <keyword>SSE</keyword>
     <keyword>IOT</keyword>

<abstract>
<t>
	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.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
	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.
</t>
<t>
	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.
</t>
<t>
	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).
</t>
<t>
	All this points to a need for a constrained solution for 
	constrained environments.
</t>
</section>
<section anchor="terms" title="Terms and Definitions">
<section title="Requirements Terminology">
<t>
		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 <xref target="RFC2119">RFC 2119</xref>.
</t>
</section>
<section title="Notations">
 <t> This section will contain notations </t> 
</section> 
<section title="Definitions">
	<t>
		TBD
	</t>
</section> 
</section> 
<section anchor="minimal" title="Minimal feature set">
<t>
	Minimal still implies something done.  In this case that something is:
<list style="hanging">
	<t hangText="Secure communications envelope:">
		The data on the 'wire' must at least have a cryptographic 
		integrity check and optionally content privacy.
	</t>
	<t hangText="Security key management:">
		The keying material for securing the communications envelope 
		must be fresh and unique.
	</t>
	<t hangText="Unique device Identity:">
		The device must have an Identity that uniquely identifies it in 
		a trusted manner.
	</t>
</list>
</t>
<t>
	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.
<list style="hanging">
	<t hangText="ECC for Identity:">
		An Eliptic Curve public key can be the base of the Identity.
	</t>
	<t hangText="ECC key management:">
		ECC can be 'reused' for the key management protocol.
	</t>
	<t hangText="Symmetric cryptography for message protection:">
		Four functions are needed: privacy, integrity, hashing, randomness.
	</t>
	<t hangText="Message management:">
		Three functions are needed: data chunking, message 
		fragmentation/reassembly, and receipt acknowledgment.  Data 
		compression is an optional fourth function.
	</t>
</list>
</t>
<t>
	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 <xref 
	target="RFC7748"/> has been implemented on 8-bit CPUs, running 9 
	seconds.
</t>
<t>
	HIP DEX <xref target="I-D.ietf-hip-dex" /> is a minimalist KMP and 
	defined for application use in <xref 
	target="I-D.moskowitz-ssls-hip" />.
</t>
<t>
	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:
	<list style="symbols">
		<t>data compression</t>
		<t>chunking of data</t>
		<t>secure envelope</t>
		<t>fragmentation and reassembly</t>
	</list>
</t>
</section> 
<section anchor="IANA" title="IANA Considerations">
<t>
	TBD.  May be nothing for IANA.
</t>
</section>
<section title="Security Considerations">
<t>
	TBD.
</t> 
</section>
<section title="Acknowledgments">
<t>
	TBD
</t>
</section>
  
</middle>
<back>
<references title="Normative References">
	<?rfc include="reference.RFC.2119.xml"?>
	<?rfc include="reference.RFC.7401.xml"?>
	<?rfc include="reference.RFC.7402.xml"?>
	<?rfc include="reference.I-D.hares-i2nsf-ssls.xml"?>
</references>
<references title="Informative References">
	<?rfc include="reference.RFC.7748.xml"?>
	<?rfc include="reference.I-D.ietf-hip-dex.xml"?>
	<?rfc include="reference.I-D.moskowitz-ssls-hip.xml"?>
</references>   
</back>
</rfc>
