Internet DRAFT - draft-handt-sacm-asset-identifiers

draft-handt-sacm-asset-identifiers



 



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]