INTERNET-DRAFT R. Housley
Intended Status: Informational Vigil Securiy
Expires: January 12, 2014 S. Turner
IECA
July 11, 2013
sacm: Asset Identifier
draft-handt-sacm-asset-identifiers-00
Abstract
This document examines the asset identifiers available for sacm and
it proposes that OIDs (Object Identifiers) be selected as the asset
identifier format.
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."
Copyright and License Notice
Copyright (c) 2013 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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
Housley & Turner Expires January 12, 2014 [Page 1]
INTERNET-DRAFT sacm: Asset Identi* July 11, 2013
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
1. Introduction
The meaning of the terms identity, identification, and identifier are
often conflated. This document uses and proposes that sacm use the
terms as defined in [RFC4949], where system entity is replace by
asset:
o Asset identity is "the collective aspect of a set of attribute
values (i.e., a set of characteristics) by which [an asset] is
recognizable or known."
o Asset identification is an "act or process that presents an
identifier to a system so that the system can recognize [an
asset] and distinguish it from other [assets]."
o An asset identifier is a "data object -- often, a printable, non-
blank character string -- that definitively represents a specific
identity of [an asset], distinguishing that identity from all
others."
You've got an identity, we've got an identity, we've all got an
identity. Even assets have at least one identity. For the purpose
of this document, an asset is any computing based hardware and the
software, including operating system, that runs on the hardware.
Examples of computing devices include laptops, tablets, servers,
routers, and telephones but as more and more devices are computerized
this could expand to the break room's toaster [Arkko].
Obviously, assets exist therefore they have an identity and because
they exist (and they cost money to build or buy) enterprises will
manage them. It cost money to buy the asset so there is little doubt
they should be tracked to make sure at minimum the asset does not
find itself disappeared. More to the point, enterprises do not wish
their assets to misbehave. When the toaster starts acting like a
flame thrower, it is a very bad day in the break room.
Identifiers are an easy way to sum up the asset's identity that
uniquely identifies it from other assets of the same type. If
there's two toasters in the break room and only one is misbehaving,
Housley & Turner Expires January 12, 2014 [Page 2]
INTERNET-DRAFT sacm: Asset Identi* July 11, 2013
then it would be good to know which one is misbehaving; it's even
more important to know which asset is misbehaving if there are ninety
thousand IP-based sensors in a building and one is acting up.
The identifier is also import because asset identifiers enable
authenticated identities that in turn serve as basis for security
services such as peer entity authentication.
This document examines the proposes that OIDs (Object Identifiers) be
used as the asset identifier in sacm (a proposed wg at the time this
was submitted).
2. Identifiers
Identifiers are a dime a dozen. Some make sense and some do not.
This section will examine some options, but first it propose some
requirements.
For asset identification to work, application developers, os
(operating system) vendors, and hardware manufacturers need to be the
ones assigning identifiers. Interacting with a 3rd party to obtain
an identifier would add unacceptable complexity.
Asset identifiers need not include all of the identity's attribute
values in the identifier. In the same way an X.509 certificate often
only includes a country name, organization, and common name but not
hair color, height and weight.
Asset identifiers need not have any inherent semantic meaning that's
the job for metadata.
2.1. Identifier Format Options
2.1.1. CPE
Common Platform Enumeration (CPE) "is a structured naming scheme for
information technology systems, software, and packages" and it is a
"method of describing and identifying classes of applications,
operating systems, and hardware devices present among an enterprise's
computing assets." It is a product of US NIST (National Institute of
Standards and Technology) Computer Security Division, Information
Technology Laboratory, sponsored by the US DHS's (Department of
Homeland Security's) National Cyber Security Division. All
intellectual property has been transferred to NIST [CPE-IPR].
CPE is a four part document set [CPE]. CPE's specifications define
the naming scheme (the format and binding of names) and matching
rules for the names. Also defined is a dictionary (aka repository or
Housley & Turner Expires January 12, 2014 [Page 3]
INTERNET-DRAFT sacm: Asset Identi* July 11, 2013
directory) that holds the names and metadata about the names that can
be accessed for lookups and searches presumably to ensure there's no
duplication amongst the names. Finally, an application language is
defined for applicability statements (aka logical expressions) using
WFNs (Well-Formed Names) "to tag checklists, policies, guidance, and
other documents with information about the product(s) to which the
documents apply."
In terms of asset identifiers, the naming document applies as well as
the requirements in the directory document for which of the 7 WFN
name attributes are required. The remaining documents, the name
matching, the application language, and the rest of the directory
document, are not germane to the asset identifier topic.
A WFN (Well-Formed Name), as defined in the CPE naming document, is
"a logical construct only" and "is not intended to be a data format,
encoding, or any other kind of machine-readable representation for
machine interchange and processing." The URI (Uniform Resource
Identifiers) [RFC3986] and formatted string bindings are the machine-
readable representation for machine interchange and processing. A
WFN has 7 naming attributes (whose purposes are pretty self-
explanatory so this document does not copy the definitions but
instead leaves it to the motivated reader to read NIST's
specifications): part, vendor, product, version, update, edition,
language, sw_edition, target_sw, target_hw, other. Part
(application, operating system, hardware), vendor, product, and
version must be present, as specified in the directory document.
A major issue with a WFN as the asset identifier is it's scope. CPE
provides identifiers for platforms, including both hardware and
software, but not to the level necessary to act as the asset
identifier because it lacks the ability to disambiguate between
hardware of software of the same type.
Another major issue with CPE is process by which one is obtained; an
application needs to be submitted to NVD (National Vulnerability
Database), which is run by the USG (United States Government). This
simple fact likely renders CPE, as it is currently specified and
operated, as unsatisfactory as the basis for sacm because there will
be some non-US entity unwilling or unable to submit an application.
3.1.2.2. SWID
Software Identifier (SWID), documented in ISO/IEC 19770-2:2009, is as
its name implies an identifier for software. SWIDs can be assigned
by software developers or by organizations that purchased software
without a SWID.
Housley & Turner Expires January 12, 2014 [Page 4]
INTERNET-DRAFT sacm: Asset Identi* July 11, 2013
Complaints about SWID include:
o The standards is not free. In terms of IETF process, this is not
show stopper. The standard must be publicly available and it even
it costs some.
o SWIDs aren't free. This is not entirely clear because there
appeared to be a way for opensource software to receive a tag.
Note that Software Entitlement (SWEN) Tags, documented in ISO/IEC
19770-3, are likely a non-starter in the IETF because of DRM
issues.
The reason SWIDs obviously can't be the identifier is that
3.1.2.3. Protocol Identifiers
Protocol identifiers encompass identifiers such as MAC (Media
Access Control), IPv4 [RFC791], IPv6 [RFC2460], as well as IPv6's
CGAs (Cryptographically Generated Addresses)
[RFC3972][RFC4581][RFC4982] and UUIDs (Universal Unique
Identifiers) [RFC4122]. None of these are appropriate for the
asset identifier for sacm because of their scope.
3.1.2.6. OIDs
OIDs are abstract and can actually represent anything. OIDs are
cheap, and there are ways to get them for free. OIDs can be
obtained from the IANA PEN (Private Enterprise Number) Registry
[IANA-PEN] or from the ITU's UUID OID page [I-UUID].
OIDs are also already used by management protocols SNMP and for
identifying hardware modules for firmware distribution [RFC4108].
4. Recommendations
Select OIDs as the asset identifier format.
5. Security Considerations
Identifiers that include inherent semantic meaning may divulge
information about that asset if the identifier is not protected at
rest and in transit.
6. IANA Considerations
Housley & Turner Expires January 12, 2014 [Page 5]
INTERNET-DRAFT sacm: Asset Identi* July 11, 2013
There are no IANA considerations present in this document.
If OIDs are chosen as the asset identifier, then entities wishing
to use OIDs may obtain them using the procedures
7. References
7.1 Normative References
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI
36, RFC 4949, August 2007.
7.2 Informative References
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to
Protect Firmware Packages", RFC 4108, August 2005.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, July
2005.
[RFC4581] Bagnulo, M. and J. Arkko, "Cryptographically Generated
Addresses (CGA) Extension Field Format", RFC 4581, October
2006.
[RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash
Algorithms in Cryptographically Generated Addresses
(CGAs)", RFC 4982, July 2007.
[CPE] https://nvd.nist.gov/cpe.cfm
https://csrc.nist.gov/publications/nistir/ir7695/
NISTIR-7695-CPE-Naming.pdf
Housley & Turner Expires January 12, 2014 [Page 6]
INTERNET-DRAFT sacm: Asset Identi* July 11, 2013
https://csrc.nist.gov/publications/nistir/ir7696/
NISTIR-7696-CPE-Matching.pdf
https://csrc.nist.gov/publications/nistir/ir7697/
NISTIR-7697-CPE-Dictionary.pdf
https://csrc.nist.gov/publications/nistir/ir7698/
NISTIR-7698-CPE-Language.pdf
[CPE-IPR] https://cpe.mitre.org/index.html
[IANA-PEN] http://pen.iana.org/pen/PenApplication.page
[I-UUID] http://www.itu.int/ITU-T/asn1/uuid.html#registration
[Arkko] http://online.wsj.com/article/
SB10001424052702303544604576434013394780764.html
Authors' Addresses
Russ Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
USA
Email: : housley@vigilsec.com
Sean Turner
IECA, Inc.
3057 Nutley Street, Suite 106
Fairfax, VA 22031
USA
Email: turners@ieca.com
Housley & Turner Expires January 12, 2014 [Page 7]