Internet DRAFT - draft-moskowitz-dots-identities

draft-moskowitz-dots-identities







DOTS                                                        R. Moskowitz
Internet-Draft                                                    L. Xia
Intended status: Standards Track                                  Huawei
Expires: May 3, 2017                                          D. Migault
                                                                Ericsson
                                                            A. Mortensen
                                                    Arbor Networks, Inc.
                                                        October 30, 2016


                   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.








Moskowitz, et al.          Expires May 3, 2017                  [Page 1]

Internet-Draft               DOTS Identities                October 2016


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

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



Moskowitz, et al.          Expires May 3, 2017                  [Page 2]

Internet-Draft               DOTS Identities                October 2016


   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



Moskowitz, et al.          Expires May 3, 2017                  [Page 3]

Internet-Draft               DOTS Identities                October 2016


   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.




Moskowitz, et al.          Expires May 3, 2017                  [Page 4]

Internet-Draft               DOTS Identities                October 2016


   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.



Moskowitz, et al.          Expires May 3, 2017                  [Page 5]

Internet-Draft               DOTS Identities                October 2016


   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







Moskowitz, et al.          Expires May 3, 2017                  [Page 6]

Internet-Draft               DOTS Identities                October 2016


8.  References

8.1.  Normative References

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

   [Std-802.1AR-2009]
              IEEE SA-Standards Board, "IEEE Standard for Local and
              metropolitan area networks - Secure Device Identity",
              December 2009, <http://standards.ieee.org/findstds/
              standard/802.1AR-2009.html>.

8.2.  Informative References

   [I-D.ietf-dots-requirements]
              Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed
              Denial of Service (DDoS) Open Threat Signaling
              Requirements", draft-ietf-dots-requirements-02 (work in
              progress), July 2016.

   [I-D.ietf-netconf-zerotouch]
              Watsen, K. and M. Abrahamsson, "Zero Touch Provisioning
              for NETCONF or RESTCONF based Management", draft-ietf-
              netconf-zerotouch-09 (work in progress), July 2016.

   [I-D.moskowitz-hierarchical-hip]
              Moskowitz, R. and X. Xu, "Hierarchical HITs for HIPv2",
              draft-moskowitz-hierarchical-hip-02 (work in progress),
              October 2016.

   [RFC4210]  Adams, C., Farrell, S., Kause, T., and T. Mononen,
              "Internet X.509 Public Key Infrastructure Certificate
              Management Protocol (CMP)", RFC 4210,
              DOI 10.17487/RFC4210, September 2005,
              <http://www.rfc-editor.org/info/rfc4210>.

   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
              2012, <http://www.rfc-editor.org/info/rfc6698>.








Moskowitz, et al.          Expires May 3, 2017                  [Page 7]

Internet-Draft               DOTS Identities                October 2016


   [RFC7250]  Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
              Weiler, S., and T. Kivinen, "Using Raw Public Keys in
              Transport Layer Security (TLS) and Datagram Transport
              Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
              June 2014, <http://www.rfc-editor.org/info/rfc7250>.

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

   [RFC8005]  Laganier, J., "Host Identity Protocol (HIP) Domain Name
              System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005,
              October 2016, <http://www.rfc-editor.org/info/rfc8005>.

Authors' Addresses

   Robert Moskowitz
   Huawei
   Oak Park, MI  48237
   USA

   Email: rgm@labs.htt-consult.com


   Liang Xia
   Huawei
   No. 101, Software Avenue, Yuhuatai District
   Nanjing
   China

   Email: Frank.xialiang@huawei.com


   Daniel Migault
   Ericsson
   8400 boulevard Decarie
   Montreal, QC  H4P 2N2
   Canada

   Phone: +1 514-452-2160
   Email: daniel.migault@ericsson.com









Moskowitz, et al.          Expires May 3, 2017                  [Page 8]

Internet-Draft               DOTS Identities                October 2016


   Andrew Mortensen
   Arbor Networks, Inc.
   2727 S. State St
   Ann Arbor, MI  48104
   United States

   Email: amortensen@arbor.net












































Moskowitz, et al.          Expires May 3, 2017                  [Page 9]