idnits 2.17.1 draft-handt-sacm-asset-identifiers-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 11, 2013) is 3941 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Housley 3 Intended Status: Informational Vigil Securiy 4 Expires: January 12, 2014 S. Turner 5 IECA 6 July 11, 2013 8 sacm: Asset Identifier 9 draft-handt-sacm-asset-identifiers-00 11 Abstract 13 This document examines the asset identifiers available for sacm and 14 it proposes that OIDs (Object Identifiers) be selected as the asset 15 identifier format. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 Copyright and License Notice 34 Copyright (c) 2013 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 This document may contain material from IETF Documents or IETF 48 Contributions published or made publicly available before November 49 10, 2008. The person(s) controlling the copyright in some of this 50 material may not have granted the IETF Trust the right to allow 51 modifications of such material outside the IETF Standards Process. 52 Without obtaining an adequate license from the person(s) controlling 53 the copyright in such materials, this document may not be modified 54 outside the IETF Standards Process, and derivative works of it may 55 not be created outside the IETF Standards Process, except to format 56 it for publication as an RFC or to translate it into languages other 57 than English. 59 1. Introduction 61 The meaning of the terms identity, identification, and identifier are 62 often conflated. This document uses and proposes that sacm use the 63 terms as defined in [RFC4949], where system entity is replace by 64 asset: 66 o Asset identity is "the collective aspect of a set of attribute 67 values (i.e., a set of characteristics) by which [an asset] is 68 recognizable or known." 70 o Asset identification is an "act or process that presents an 71 identifier to a system so that the system can recognize [an 72 asset] and distinguish it from other [assets]." 74 o An asset identifier is a "data object -- often, a printable, non- 75 blank character string -- that definitively represents a specific 76 identity of [an asset], distinguishing that identity from all 77 others." 79 You've got an identity, we've got an identity, we've all got an 80 identity. Even assets have at least one identity. For the purpose 81 of this document, an asset is any computing based hardware and the 82 software, including operating system, that runs on the hardware. 83 Examples of computing devices include laptops, tablets, servers, 84 routers, and telephones but as more and more devices are computerized 85 this could expand to the break room's toaster [Arkko]. 87 Obviously, assets exist therefore they have an identity and because 88 they exist (and they cost money to build or buy) enterprises will 89 manage them. It cost money to buy the asset so there is little doubt 90 they should be tracked to make sure at minimum the asset does not 91 find itself disappeared. More to the point, enterprises do not wish 92 their assets to misbehave. When the toaster starts acting like a 93 flame thrower, it is a very bad day in the break room. 95 Identifiers are an easy way to sum up the asset's identity that 96 uniquely identifies it from other assets of the same type. If 97 there's two toasters in the break room and only one is misbehaving, 98 then it would be good to know which one is misbehaving; it's even 99 more important to know which asset is misbehaving if there are ninety 100 thousand IP-based sensors in a building and one is acting up. 102 The identifier is also import because asset identifiers enable 103 authenticated identities that in turn serve as basis for security 104 services such as peer entity authentication. 106 This document examines the proposes that OIDs (Object Identifiers) be 107 used as the asset identifier in sacm (a proposed wg at the time this 108 was submitted). 110 2. Identifiers 112 Identifiers are a dime a dozen. Some make sense and some do not. 113 This section will examine some options, but first it propose some 114 requirements. 116 For asset identification to work, application developers, os 117 (operating system) vendors, and hardware manufacturers need to be the 118 ones assigning identifiers. Interacting with a 3rd party to obtain 119 an identifier would add unacceptable complexity. 121 Asset identifiers need not include all of the identity's attribute 122 values in the identifier. In the same way an X.509 certificate often 123 only includes a country name, organization, and common name but not 124 hair color, height and weight. 126 Asset identifiers need not have any inherent semantic meaning that's 127 the job for metadata. 129 2.1. Identifier Format Options 131 2.1.1. CPE 133 Common Platform Enumeration (CPE) "is a structured naming scheme for 134 information technology systems, software, and packages" and it is a 135 "method of describing and identifying classes of applications, 136 operating systems, and hardware devices present among an enterprise's 137 computing assets." It is a product of US NIST (National Institute of 138 Standards and Technology) Computer Security Division, Information 139 Technology Laboratory, sponsored by the US DHS's (Department of 140 Homeland Security's) National Cyber Security Division. All 141 intellectual property has been transferred to NIST [CPE-IPR]. 143 CPE is a four part document set [CPE]. CPE's specifications define 144 the naming scheme (the format and binding of names) and matching 145 rules for the names. Also defined is a dictionary (aka repository or 146 directory) that holds the names and metadata about the names that can 147 be accessed for lookups and searches presumably to ensure there's no 148 duplication amongst the names. Finally, an application language is 149 defined for applicability statements (aka logical expressions) using 150 WFNs (Well-Formed Names) "to tag checklists, policies, guidance, and 151 other documents with information about the product(s) to which the 152 documents apply." 154 In terms of asset identifiers, the naming document applies as well as 155 the requirements in the directory document for which of the 7 WFN 156 name attributes are required. The remaining documents, the name 157 matching, the application language, and the rest of the directory 158 document, are not germane to the asset identifier topic. 160 A WFN (Well-Formed Name), as defined in the CPE naming document, is 161 "a logical construct only" and "is not intended to be a data format, 162 encoding, or any other kind of machine-readable representation for 163 machine interchange and processing." The URI (Uniform Resource 164 Identifiers) [RFC3986] and formatted string bindings are the machine- 165 readable representation for machine interchange and processing. A 166 WFN has 7 naming attributes (whose purposes are pretty self- 167 explanatory so this document does not copy the definitions but 168 instead leaves it to the motivated reader to read NIST's 169 specifications): part, vendor, product, version, update, edition, 170 language, sw_edition, target_sw, target_hw, other. Part 171 (application, operating system, hardware), vendor, product, and 172 version must be present, as specified in the directory document. 174 A major issue with a WFN as the asset identifier is it's scope. CPE 175 provides identifiers for platforms, including both hardware and 176 software, but not to the level necessary to act as the asset 177 identifier because it lacks the ability to disambiguate between 178 hardware of software of the same type. 180 Another major issue with CPE is process by which one is obtained; an 181 application needs to be submitted to NVD (National Vulnerability 182 Database), which is run by the USG (United States Government). This 183 simple fact likely renders CPE, as it is currently specified and 184 operated, as unsatisfactory as the basis for sacm because there will 185 be some non-US entity unwilling or unable to submit an application. 187 3.1.2.2. SWID 189 Software Identifier (SWID), documented in ISO/IEC 19770-2:2009, is as 190 its name implies an identifier for software. SWIDs can be assigned 191 by software developers or by organizations that purchased software 192 without a SWID. 194 Complaints about SWID include: 196 o The standards is not free. In terms of IETF process, this is not 197 show stopper. The standard must be publicly available and it even 198 it costs some. 200 o SWIDs aren't free. This is not entirely clear because there 201 appeared to be a way for opensource software to receive a tag. 203 Note that Software Entitlement (SWEN) Tags, documented in ISO/IEC 204 19770-3, are likely a non-starter in the IETF because of DRM 205 issues. 207 The reason SWIDs obviously can't be the identifier is that 209 3.1.2.3. Protocol Identifiers 211 Protocol identifiers encompass identifiers such as MAC (Media 212 Access Control), IPv4 [RFC791], IPv6 [RFC2460], as well as IPv6's 213 CGAs (Cryptographically Generated Addresses) 214 [RFC3972][RFC4581][RFC4982] and UUIDs (Universal Unique 215 Identifiers) [RFC4122]. None of these are appropriate for the 216 asset identifier for sacm because of their scope. 218 3.1.2.6. OIDs 220 OIDs are abstract and can actually represent anything. OIDs are 221 cheap, and there are ways to get them for free. OIDs can be 222 obtained from the IANA PEN (Private Enterprise Number) Registry 223 [IANA-PEN] or from the ITU's UUID OID page [I-UUID]. 225 OIDs are also already used by management protocols SNMP and for 226 identifying hardware modules for firmware distribution [RFC4108]. 228 4. Recommendations 230 Select OIDs as the asset identifier format. 232 5. Security Considerations 234 Identifiers that include inherent semantic meaning may divulge 235 information about that asset if the identifier is not protected at 236 rest and in transit. 238 6. IANA Considerations 239 There are no IANA considerations present in this document. 241 If OIDs are chosen as the asset identifier, then entities wishing 242 to use OIDs may obtain them using the procedures 244 7. References 246 7.1 Normative References 248 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 249 36, RFC 4949, August 2007. 251 7.2 Informative References 253 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 254 1981. 256 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 257 (IPv6) Specification", RFC 2460, December 1998. 259 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 260 RFC 3972, March 2005. 262 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 263 Resource Identifier (URI): Generic Syntax", STD 66, 264 RFC 3986, January 2005. 266 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 267 Protect Firmware Packages", RFC 4108, August 2005. 269 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 270 Unique IDentifier (UUID) URN Namespace", RFC 4122, July 271 2005. 273 [RFC4581] Bagnulo, M. and J. Arkko, "Cryptographically Generated 274 Addresses (CGA) Extension Field Format", RFC 4581, October 275 2006. 277 [RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash 278 Algorithms in Cryptographically Generated Addresses 279 (CGAs)", RFC 4982, July 2007. 281 [CPE] https://nvd.nist.gov/cpe.cfm 282 https://csrc.nist.gov/publications/nistir/ir7695/ 283 NISTIR-7695-CPE-Naming.pdf 284 https://csrc.nist.gov/publications/nistir/ir7696/ 285 NISTIR-7696-CPE-Matching.pdf 287 https://csrc.nist.gov/publications/nistir/ir7697/ 288 NISTIR-7697-CPE-Dictionary.pdf 290 https://csrc.nist.gov/publications/nistir/ir7698/ 291 NISTIR-7698-CPE-Language.pdf 293 [CPE-IPR] https://cpe.mitre.org/index.html 295 [IANA-PEN] http://pen.iana.org/pen/PenApplication.page 297 [I-UUID] http://www.itu.int/ITU-T/asn1/uuid.html#registration 299 [Arkko] http://online.wsj.com/article/ 300 SB10001424052702303544604576434013394780764.html 302 Authors' Addresses 304 Russ Housley 305 Vigil Security, LLC 306 918 Spring Knoll Drive 307 Herndon, VA 20170 308 USA 310 Email: : housley@vigilsec.com 312 Sean Turner 313 IECA, Inc. 314 3057 Nutley Street, Suite 106 315 Fairfax, VA 22031 316 USA 318 Email: turners@ieca.com