﻿<?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-dots-identities-00.txt" ipr="trust200902">

<front>
<title abbrev="DOTS Identities">Strong Identities for DOTS Agents</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>
        <country>USA</country>
      </postal>
      <email>rgm@labs.htt-consult.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>
    <author fullname="Daniel Migault" initials="D." surname="Migault">
      <organization> Ericsson </organization>
      <address>
        <postal>
          <street> 8400 boulevard Decarie</street>
          <city> Montreal</city>
           <region>QC</region>
         <code> H4P 2N2 </code>
          <country>Canada</country>
        </postal>
        <phone> +1 514-452-2160 </phone>
        <email> daniel.migault@ericsson.com </email>
      </address>
    </author>
	<author fullname="Andrew Mortensen" initials="A." surname="Mortensen">
	<organization>Arbor Networks, Inc.</organization>
	<address>
	<postal>
		<street>2727 S. State St</street>
		<city>Ann Arbor, MI  48104</city>
		<country>United States</country>
	</postal>
	<email>amortensen@arbor.net</email>
	</address>
	</author>
<date year="2016" />
   <area>Internet</area>
   <workgroup>DOTS</workgroup>
    <keyword>RFC</keyword>
     <keyword>Request for Comments</keyword>
     <keyword>I-D</keyword>
     <keyword>Internet-Draft</keyword>
     <keyword>DOTS</keyword>
<abstract>
<t>
	DOTS communications are machine-to-machine oriented communications.  
	In addition DOTS agents are expected to end up in a large number of 
	entities. As a result, in addition to secure, the naming scheme to 
	identify all DOTS agents must be scalable.  For these reasons this 
	document recommends the use of cryptographic identifiers or strong 
	Identities as opposed to human readable identifiers for example.
</t>
<t>
	This document proposes two forms of strong Identities for the 
	registration and operation of DOTS Agents.  One is <xref 
	target="Std-802.1AR-2009">802.1AR LDevID</xref> X.509 certificates. 
	The other is raw public keys as in <xref 
	target="RFC7401">HIP</xref> or TLS/DTLS <xref target="RFC7250">Raw 
	Public Keys</xref>.
</t>
</abstract>
</front>
<middle>
<section title="Introduction"> 
<t>
	DOTS communications are machine-to-machine oriented communications. 
	In addition DOTS agents are expected to end up in a large number of 
	entities. As a result, in addition to secure, the naming scheme to 
	identify all DOTS agents must be scalable.  For these reasons the 
	document recommend the use of cryptographic identifiers or strong 
	Identities as opposed to human readable identifiers for example.
</t>
<t>
	Human readable identifiers are very helpful to represent a resource 
	for human. A typical example is the use of First Name and Last Name 
	which is easier for human beings to remember  than a phone number. 
	The same occurs for web sites where FQDNs are easier to remember 
	than the IPv6 addresses. However the human readable representation 
	also comes with some issues. 
</t>
<t>
	First human readable identifiers have very little entropy which 
	means that when the number of identifiers grow, collision are 
	likely to happen. The likelihood of identifier collision may be 
	limited at the expense of management complexity whose complexity 
	grows with the number of identifiers. Second, human readable 
	identifiers are only meaningful when used by humans who are only 
	able to handle a limited numbers of identifiers. Third the 
	identifier needs to be securely bound to additional element such as 
	security elements - a public key - or routing elements - an IP 
	address - in order to enable a communication.
</t>
<t>
	As a result, human readable identifiers do not scale to meet the 
	need of DOTs identifiers and the management overhead complexity to 
	make identifiers human readable becomes meaningless in a automated 
	machine to machine environment. A DOTS is intended for machine to 
	machine -like  communication, there is no reason for using human 
	readable identifiers. DOTS recommends the use of cryptographic 
	identifiers to avoid an additional and unnecessary cryptographic 
	binding between the identifier and the security material.
</t>
<t>
	This document describes two forms of strong Identities for the 
	registration and operation of DOTS Agents.
</t>
<section title="X.509 LDevID">
<t>
	The first is the X.509 LDevID defined in <xref 
	target="Std-802.1AR-2009">802.1AR</xref>.  The methodology proposed 
	herein expects the DOTS mitigation provider to provide a PKI that 
	will issue LDevID certificates to its customers.  This provides a 
	strong "domain of trust" to the identities of its customers.  Inter 
	provider trust can be established through any of the multi-PKI 
	trust models in use today.
</t> 
<t>
	Customer LDevID registration may be based on an "Owner 
	Certificate", allocated to the device during a NETCONF zerotouch 
	registration <xref target="I-D.ietf-netconf-zerotouch"/>.  Or the 
	IDevID could be used directly in some registration process.
</t>
</section>
<section title="Raw Public Key">
<t>
	The second form of Identity is a Raw Public Key.
</t>
<t>
	One type of Raw Public Key is a <xref target="RFC7401">HIP</xref> 
	Host Identity (HI).  The customer may use <xref 
	target="RFC8005">HIP DNS Extension</xref> to assert its HI to the 
	DOTS mitigation provider and then use HIP to prove ownership of the 
	HI.
</t>
<t>
	Although nothing prevents HI/HIT to be assigned by the provider, 
	there is currently no mechanisms defined for such provisioning. 
	This might be defined in future work, however, the current use of 
	HI/HIT is that these identifiers are generated by the owner or the 
	agent.
</t>
<t>
	Another type of Raw Public Key is defined in <xref 
	target="RFC7250"/>.  The customer would use the methods defined in 
	<xref target="RFC6698">DANE</xref> validate a TLS Raw Public Key.
</t>
</section>
</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="Definitions">
	<t>
		<list style="hanging">
		<t hangText="DOTS Agents:">
			Per <xref target="I-D.ietf-dots-requirements" />, any 
			DOTS-aware software module capable of participating in a 
			DOTS signaling session.
		</t>
		<t hangText="Host Identity (HI):">
			The term "HI" is defined in <xref target="RFC7401"/> as 
			"the public key of the signature algorithm that represents 
			the identity of the host."  In HIP, a host proves its 
			identity by creating a signature with the private key 
			belonging to its HI.
		</t>
		<t hangText="Initial Secure Device Identifier (IDevID):">
			The term "IDevID" is defined in <xref 
			target="Std-802.1AR-2009"/> as "the Secure Device 
			Identifier (DevID) installed on the device by the 
			manufacturer".  By example, an IDevID certificate, signed 
			by the manufacturer may encode a manufacturer assigned 
			unique identifier (e.g., serial number) and a public key 
			matching a private key held within a TPM chip embedded 
			within the device.
		</t>
		<t hangText="Locally Significant Secure Device Identifier (LDevID):">
			The term "LDevID" is defined in <xref 
			target="Std-802.1AR-2009"/> as "A Secure Device Identifier 
			credential that is unique in the local administrative 
			domain in which the device is used.".  By example, an 
			LDevID certificate, signed by the device owner may encode 
			an owner assigned unique identifier (e.g., installation 
			location) and a public key matching a private key held 
			within a TPM chip embedded within the device.
		</t>
		<t hangText="Owner Certificate:">
			The term "owner certificate" is defined in <xref 
			target="I-D.ietf-netconf-zerotouch"/> as used in this 
			document to represent an X.509 certificate, signed by the 
			device's manufacturer or delegate, that binds an owner 
			identity to the owner's private key, which the owner can 
			subsequently use to sign artifacts.
		</t>
		<t hangText="TLS Raw Public Key:">
			The term "Raw Public Key" is defined in <xref 
			target="RFC7250"/>. So a "TLS Raw Public Key" as used in 
			this document to represent this subset of an X.509 
			certificate used in the manner specified in RFC7250.
		</t>
		</list>
	</t>
	</section>
</section>
<section anchor="prob-space" title="Problem Space">
<section title="Trusted Identities">
<t>
	DOTS is meant to be deployed within the context of a business 
	arrangement between a customer and a DDoS mitigation provider. This 
	relationship is long-lived over a persistent session.  This 
	relationship and the data communications can best be managed with 
	trusted identities.
</t>
<t>
	Further, the customer's DDoS mitigation provider may need to enlist 
	the assistance of a peer provider.  A strong trusted identity link 
	from the requesting provider back to the attacked customer would 
	benefit the mitigation process.
</t>
</section>
<section title="Managing the scope of Trust">
<t>
	The web's PKI model is fraught with trust leakage challenges.  Why 
	trust a specific certificate just because some CA within the list 
	of CAs that must be trusted has signed the certificate?  This leads 
	to independent vetting of each client certificate or applying some 
	rules as to which CA is accepted for what business arrangement and 
	then still maintaining a list of accepted client certificates is 
	needed.  This leads to a basic question of what is an X.509 
	certificate providing to the business agreement that would not be 
	needed to be found out independent from the certificate?
</t>
</section>
</section>
<section title="Effectively Managing Identity Trust">
<section title="The IEEE 802.1AR Device Identity Certificate Model">
<t>
	IEEE <xref target="Std-802.1AR-2009">802.1AR</xref> defines two 
	important types of X.509 certificates.  The IDevID is installed in 
	the device in permanent, secure storage (e.g. a TPM) and is NEVER 
	replaced.  This certificate is signed by the manufacturer's CA. 
	Typically, its subjectName contains the device's serial number and 
	other information that uniquely identifies the device.
</t>
<t>
	The IDevID is not appropriate to use as an Identifier for any 
	action other than provisioning another Identifier that is more 
	flexible for general use.  This limitation is based, in part, on 
	the permanency of IDevIDs and the potential for a large number of 
	CAs 'owning' those IDevIDs.
</t>
<t>
	The second, more regularly usable, type of certificate is the 
	LDevID.  This Locally Significant Secure Device Identifier is 
	expected to be signed by a PKI appropriate to its use.  For 
	example, the DDoS mitigation provider can maintain its PKI for the 
	signing and validating the device's LDevID certificate.  The 
	methodology for an IDevID to leverage the creation of an LDevID is 
	left to IETF protocols. Originally, this meant using PKIX protocols 
	like <xref target="RFC4210">CMP</xref>.  Recent work with <xref 
	target="I-D.ietf-netconf-zerotouch"/> can lead to a trusted lDevID 
	request based on the Owner Certificate.
</t>
</section>
<section title="The Raw Public Key Model">
<t>
	With Raw Public Keys, the trust establishment is left to the 
	provider.  Authentication based on a Raw Public Key assumes the 
	peer already has the corresponding identifier. Authentication based 
	on raw keys has been integrated by many protocol such as IKEv2, 
	HIP, and TLS. However, unless the identifier is known by the peer, 
	such protocol end with an unauthenticated communication. 
	Provisioning of the identifier, is usually out of scope of these 
	protocol. The Identifier may be provided out of band, using leap of 
	faith mechanisms. Eventually DNSSEC can also be used to bind the 
	identifier to raw key.
</t>
<t>
	There are some recent developments, like <xref 
	target="I-D.moskowitz-hierarchical-hip">Hierarchical HITs</xref> 
	that provide an trusted infrastructure for Raw Public Keys.
</t>
</section>
</section>

<section anchor="IANA" title="IANA Considerations">
<t>
	TBD
</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"?>
	<reference anchor="Std-802.1AR-2009" target="http://standards.ieee.org/findstds/standard/802.1AR-2009.html">
	<front>
		<title>IEEE Standard for Local and metropolitan area networks - Secure Device Identity</title>
		<author fullname="WG802.1 - Higher Layer LAN Protocols Working Group">
		<organization>IEEE SA-Standards Board</organization>
		</author>
		<date month="December" year="2009"/>
	</front>
	</reference>
</references>
<references title="Informative References">
	<?rfc include="reference.RFC.4210.xml"?>
	<?rfc include="reference.RFC.6698.xml"?>
	<?rfc include="reference.RFC.7250.xml"?>
	<?rfc include="reference.RFC.7401.xml"?>
	<?rfc include="reference.RFC.8005.xml"?>
	<?rfc include="reference.I-D.ietf-dots-requirements.xml"?>
	<?rfc include="reference.I-D.ietf-netconf-zerotouch.xml"?>
	<?rfc include="reference.I-D.moskowitz-hierarchical-hip.xml"?>
</references>
</back>
</rfc>
