Strong Identities for DOTS Agents
draft-moskowitz-dots-identities-00.txt

Abstract

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.

This document proposes two forms of strong Identities for the registration and operation of DOTS Agents. One is 802.1AR LDevID [Std-802.1AR-2009] X.509 certificates. The other is raw public keys as in HIP [RFC7401] or TLS/DTLS Raw Public Keys [RFC7250].

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 May 3, 2017.

Copyright Notice

Copyright (c) 2016 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 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
• 1.1. X.509 LDevID
• 1.2. Raw Public Key
• 2. Terms and Definitions
• 2.1. Requirements Terminology
• 2.2. Definitions
• 3. Problem Space
• 3.1. Trusted Identities
• 3.2. Managing the scope of Trust
• 4. Effectively Managing Identity Trust
• 4.1. The IEEE 802.1AR Device Identity Certificate Model
• 4.2. The Raw Public Key Model
• 5. IANA Considerations
• 6. Security Considerations
• 7. Acknowledgments
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Authors' Addresses

1. Introduction

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.

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.

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.

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.

This document describes two forms of strong Identities for the registration and operation of DOTS Agents.

1.1. X.509 LDevID

The first is the X.509 LDevID defined in 802.1AR [Std-802.1AR-2009]. 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.

Customer LDevID registration may be based on an "Owner Certificate", allocated to the device during a NETCONF zerotouch registration [I-D.ietf-netconf-zerotouch]. Or the IDevID could be used directly in some registration process.

1.2. Raw Public Key

The second form of Identity is a Raw Public Key.

One type of Raw Public Key is a HIP [RFC7401] Host Identity (HI). The customer may use HIP DNS Extension [RFC8005] to assert its HI to the DOTS mitigation provider and then use HIP to prove ownership of the HI.

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.

Another type of Raw Public Key is defined in [RFC7250]. The customer would use the methods defined in DANE [RFC6698] validate a TLS Raw Public Key.

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. Definitions

DOTS Agents:

Per [I-D.ietf-dots-requirements], any DOTS-aware software module capable of participating in a DOTS signaling session.

Host Identity (HI):

The term "HI" is defined in [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.

Initial Secure Device Identifier (IDevID):

The term "IDevID" is defined in [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.

Locally Significant Secure Device Identifier (LDevID):

The term "LDevID" is defined in [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.

Owner Certificate:

The term "owner certificate" is defined in [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.

TLS Raw Public Key:

The term "Raw Public Key" is defined in [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.

3. Problem Space

3.1. Trusted Identities

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.

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.

3.2. Managing the scope of Trust

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?

4. Effectively Managing Identity Trust

4.1. The IEEE 802.1AR Device Identity Certificate Model

IEEE 802.1AR [Std-802.1AR-2009] 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.

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.

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 CMP [RFC4210]. Recent work with [I-D.ietf-netconf-zerotouch] can lead to a trusted lDevID request based on the Owner Certificate.

4.2. The Raw Public Key Model

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.

There are some recent developments, like Hierarchical HITs [I-D.moskowitz-hierarchical-hip] that provide an trusted infrastructure for Raw Public Keys.

5. IANA Considerations

TBD

6. Security Considerations

TBD

7. Acknowledgments

TBD

8. References

8.1. Normative References

8.2. Informative References

Authors' Addresses