One document matched: draft-moskowitz-dots-identities-00.xml
<?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>
| PAFTECH AB 2003-2026 | 2026-04-23 14:25:50 |