idnits 2.17.1 draft-moskowitz-dots-identities-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7250], [RFC7401]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 30, 2016) is 2735 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-22) exists of draft-ietf-dots-requirements-02 == Outdated reference: A later version (-29) exists of draft-ietf-netconf-zerotouch-09 == Outdated reference: A later version (-06) exists of draft-moskowitz-hierarchical-hip-02 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS R. Moskowitz 3 Internet-Draft L. Xia 4 Intended status: Standards Track Huawei 5 Expires: May 3, 2017 D. Migault 6 Ericsson 7 A. Mortensen 8 Arbor Networks, Inc. 9 October 30, 2016 11 Strong Identities for DOTS Agents 12 draft-moskowitz-dots-identities-00.txt 14 Abstract 16 DOTS communications are machine-to-machine oriented communications. 17 In addition DOTS agents are expected to end up in a large number of 18 entities. As a result, in addition to secure, the naming scheme to 19 identify all DOTS agents must be scalable. For these reasons this 20 document recommends the use of cryptographic identifiers or strong 21 Identities as opposed to human readable identifiers for example. 23 This document proposes two forms of strong Identities for the 24 registration and operation of DOTS Agents. One is 802.1AR LDevID 25 [Std-802.1AR-2009] X.509 certificates. The other is raw public keys 26 as in HIP [RFC7401] or TLS/DTLS Raw Public Keys [RFC7250]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 3, 2017. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. X.509 LDevID . . . . . . . . . . . . . . . . . . . . . . 3 64 1.2. Raw Public Key . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 66 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 4 67 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Trusted Identities . . . . . . . . . . . . . . . . . . . 5 70 3.2. Managing the scope of Trust . . . . . . . . . . . . . . . 5 71 4. Effectively Managing Identity Trust . . . . . . . . . . . . . 5 72 4.1. The IEEE 802.1AR Device Identity Certificate Model . . . 5 73 4.2. The Raw Public Key Model . . . . . . . . . . . . . . . . 6 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 76 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 79 8.2. Informative References . . . . . . . . . . . . . . . . . 7 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 82 1. Introduction 84 DOTS communications are machine-to-machine oriented communications. 85 In addition DOTS agents are expected to end up in a large number of 86 entities. As a result, in addition to secure, the naming scheme to 87 identify all DOTS agents must be scalable. For these reasons the 88 document recommend the use of cryptographic identifiers or strong 89 Identities as opposed to human readable identifiers for example. 91 Human readable identifiers are very helpful to represent a resource 92 for human. A typical example is the use of First Name and Last Name 93 which is easier for human beings to remember than a phone number. 94 The same occurs for web sites where FQDNs are easier to remember than 95 the IPv6 addresses. However the human readable representation also 96 comes with some issues. 98 First human readable identifiers have very little entropy which means 99 that when the number of identifiers grow, collision are likely to 100 happen. The likelihood of identifier collision may be limited at the 101 expense of management complexity whose complexity grows with the 102 number of identifiers. Second, human readable identifiers are only 103 meaningful when used by humans who are only able to handle a limited 104 numbers of identifiers. Third the identifier needs to be securely 105 bound to additional element such as security elements - a public key 106 - or routing elements - an IP address - in order to enable a 107 communication. 109 As a result, human readable identifiers do not scale to meet the need 110 of DOTs identifiers and the management overhead complexity to make 111 identifiers human readable becomes meaningless in a automated machine 112 to machine environment. A DOTS is intended for machine to machine 113 -like communication, there is no reason for using human readable 114 identifiers. DOTS recommends the use of cryptographic identifiers to 115 avoid an additional and unnecessary cryptographic binding between the 116 identifier and the security material. 118 This document describes two forms of strong Identities for the 119 registration and operation of DOTS Agents. 121 1.1. X.509 LDevID 123 The first is the X.509 LDevID defined in 802.1AR [Std-802.1AR-2009]. 124 The methodology proposed herein expects the DOTS mitigation provider 125 to provide a PKI that will issue LDevID certificates to its 126 customers. This provides a strong "domain of trust" to the 127 identities of its customers. Inter provider trust can be established 128 through any of the multi-PKI trust models in use today. 130 Customer LDevID registration may be based on an "Owner Certificate", 131 allocated to the device during a NETCONF zerotouch registration 132 [I-D.ietf-netconf-zerotouch]. Or the IDevID could be used directly 133 in some registration process. 135 1.2. Raw Public Key 137 The second form of Identity is a Raw Public Key. 139 One type of Raw Public Key is a HIP [RFC7401] Host Identity (HI). 140 The customer may use HIP DNS Extension [RFC8005] to assert its HI to 141 the DOTS mitigation provider and then use HIP to prove ownership of 142 the HI. 144 Although nothing prevents HI/HIT to be assigned by the provider, 145 there is currently no mechanisms defined for such provisioning. This 146 might be defined in future work, however, the current use of HI/HIT 147 is that these identifiers are generated by the owner or the agent. 149 Another type of Raw Public Key is defined in [RFC7250]. The customer 150 would use the methods defined in DANE [RFC6698] validate a TLS Raw 151 Public Key. 153 2. Terms and Definitions 155 2.1. Requirements Terminology 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in RFC 2119 [RFC2119]. 161 2.2. Definitions 163 DOTS Agents: Per [I-D.ietf-dots-requirements], any DOTS-aware 164 software module capable of participating in a DOTS signaling 165 session. 167 Host Identity (HI): The term "HI" is defined in [RFC7401] as "the 168 public key of the signature algorithm that represents the identity 169 of the host." In HIP, a host proves its identity by creating a 170 signature with the private key belonging to its HI. 172 Initial Secure Device Identifier (IDevID): The term "IDevID" is 173 defined in [Std-802.1AR-2009] as "the Secure Device Identifier 174 (DevID) installed on the device by the manufacturer". By example, 175 an IDevID certificate, signed by the manufacturer may encode a 176 manufacturer assigned unique identifier (e.g., serial number) and 177 a public key matching a private key held within a TPM chip 178 embedded within the device. 180 Locally Significant Secure Device Identifier (LDevID): The term 181 "LDevID" is defined in [Std-802.1AR-2009] as "A Secure Device 182 Identifier credential that is unique in the local administrative 183 domain in which the device is used.". By example, an LDevID 184 certificate, signed by the device owner may encode an owner 185 assigned unique identifier (e.g., installation location) and a 186 public key matching a private key held within a TPM chip embedded 187 within the device. 189 Owner Certificate: The term "owner certificate" is defined in 190 [I-D.ietf-netconf-zerotouch] as used in this document to represent 191 an X.509 certificate, signed by the device's manufacturer or 192 delegate, that binds an owner identity to the owner's private key, 193 which the owner can subsequently use to sign artifacts. 195 TLS Raw Public Key: The term "Raw Public Key" is defined in 196 [RFC7250]. So a "TLS Raw Public Key" as used in this document to 197 represent this subset of an X.509 certificate used in the manner 198 specified in RFC7250. 200 3. Problem Space 202 3.1. Trusted Identities 204 DOTS is meant to be deployed within the context of a business 205 arrangement between a customer and a DDoS mitigation provider. This 206 relationship is long-lived over a persistent session. This 207 relationship and the data communications can best be managed with 208 trusted identities. 210 Further, the customer's DDoS mitigation provider may need to enlist 211 the assistance of a peer provider. A strong trusted identity link 212 from the requesting provider back to the attacked customer would 213 benefit the mitigation process. 215 3.2. Managing the scope of Trust 217 The web's PKI model is fraught with trust leakage challenges. Why 218 trust a specific certificate just because some CA within the list of 219 CAs that must be trusted has signed the certificate? This leads to 220 independent vetting of each client certificate or applying some rules 221 as to which CA is accepted for what business arrangement and then 222 still maintaining a list of accepted client certificates is needed. 223 This leads to a basic question of what is an X.509 certificate 224 providing to the business agreement that would not be needed to be 225 found out independent from the certificate? 227 4. Effectively Managing Identity Trust 229 4.1. The IEEE 802.1AR Device Identity Certificate Model 231 IEEE 802.1AR [Std-802.1AR-2009] defines two important types of X.509 232 certificates. The IDevID is installed in the device in permanent, 233 secure storage (e.g. a TPM) and is NEVER replaced. This certificate 234 is signed by the manufacturer's CA. Typically, its subjectName 235 contains the device's serial number and other information that 236 uniquely identifies the device. 238 The IDevID is not appropriate to use as an Identifier for any action 239 other than provisioning another Identifier that is more flexible for 240 general use. This limitation is based, in part, on the permanency of 241 IDevIDs and the potential for a large number of CAs 'owning' those 242 IDevIDs. 244 The second, more regularly usable, type of certificate is the LDevID. 245 This Locally Significant Secure Device Identifier is expected to be 246 signed by a PKI appropriate to its use. For example, the DDoS 247 mitigation provider can maintain its PKI for the signing and 248 validating the device's LDevID certificate. The methodology for an 249 IDevID to leverage the creation of an LDevID is left to IETF 250 protocols. Originally, this meant using PKIX protocols like CMP 251 [RFC4210]. Recent work with [I-D.ietf-netconf-zerotouch] can lead to 252 a trusted lDevID request based on the Owner Certificate. 254 4.2. The Raw Public Key Model 256 With Raw Public Keys, the trust establishment is left to the 257 provider. Authentication based on a Raw Public Key assumes the peer 258 already has the corresponding identifier. Authentication based on 259 raw keys has been integrated by many protocol such as IKEv2, HIP, and 260 TLS. However, unless the identifier is known by the peer, such 261 protocol end with an unauthenticated communication. Provisioning of 262 the identifier, is usually out of scope of these protocol. The 263 Identifier may be provided out of band, using leap of faith 264 mechanisms. Eventually DNSSEC can also be used to bind the 265 identifier to raw key. 267 There are some recent developments, like Hierarchical HITs 268 [I-D.moskowitz-hierarchical-hip] that provide an trusted 269 infrastructure for Raw Public Keys. 271 5. IANA Considerations 273 TBD 275 6. Security Considerations 277 TBD 279 7. Acknowledgments 281 TBD 283 8. References 285 8.1. Normative References 287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 288 Requirement Levels", BCP 14, RFC 2119, 289 DOI 10.17487/RFC2119, March 1997, 290 . 292 [Std-802.1AR-2009] 293 IEEE SA-Standards Board, "IEEE Standard for Local and 294 metropolitan area networks - Secure Device Identity", 295 December 2009, . 298 8.2. Informative References 300 [I-D.ietf-dots-requirements] 301 Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed 302 Denial of Service (DDoS) Open Threat Signaling 303 Requirements", draft-ietf-dots-requirements-02 (work in 304 progress), July 2016. 306 [I-D.ietf-netconf-zerotouch] 307 Watsen, K. and M. Abrahamsson, "Zero Touch Provisioning 308 for NETCONF or RESTCONF based Management", draft-ietf- 309 netconf-zerotouch-09 (work in progress), July 2016. 311 [I-D.moskowitz-hierarchical-hip] 312 Moskowitz, R. and X. Xu, "Hierarchical HITs for HIPv2", 313 draft-moskowitz-hierarchical-hip-02 (work in progress), 314 October 2016. 316 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 317 "Internet X.509 Public Key Infrastructure Certificate 318 Management Protocol (CMP)", RFC 4210, 319 DOI 10.17487/RFC4210, September 2005, 320 . 322 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 323 of Named Entities (DANE) Transport Layer Security (TLS) 324 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 325 2012, . 327 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 328 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 329 Transport Layer Security (TLS) and Datagram Transport 330 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 331 June 2014, . 333 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 334 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 335 RFC 7401, DOI 10.17487/RFC7401, April 2015, 336 . 338 [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name 339 System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, 340 October 2016, . 342 Authors' Addresses 344 Robert Moskowitz 345 Huawei 346 Oak Park, MI 48237 347 USA 349 Email: rgm@labs.htt-consult.com 351 Liang Xia 352 Huawei 353 No. 101, Software Avenue, Yuhuatai District 354 Nanjing 355 China 357 Email: Frank.xialiang@huawei.com 359 Daniel Migault 360 Ericsson 361 8400 boulevard Decarie 362 Montreal, QC H4P 2N2 363 Canada 365 Phone: +1 514-452-2160 366 Email: daniel.migault@ericsson.com 367 Andrew Mortensen 368 Arbor Networks, Inc. 369 2727 S. State St 370 Ann Arbor, MI 48104 371 United States 373 Email: amortensen@arbor.net