Re: [sacm] FW: New Version Notification for draft-montville-sacm-asset-identification-00.txt

[Sean Turner <[e-mail]>]

Hi all (these aren't directed just at Adam),

I've got some comments/questions that are I guess pretty basic but also 
some questions about how the model works/fits with the information 
collected about assets that's been previously specified (or is currently 
being specified elsewhere) in the IETF.  In no particular order:

1) CPE: I guess it's an open question as to whether we should go with 
CPE', SWID, or do we need both because SWID is just software and CPE 
also includes hardware?

a) My initial concern was that open source folks would have to pay to 
get a SWID, but it looks like tagvault.org has free memberships.  I'd 
like to get that confirmed though.

b) I used CPE' purposely because I think we'd need an international 
multistakeholder organization to maintain the registries because like it 
or not not everybody is going to be willing or be able to use a USG site 
to register their software/hardware.  The registry could be set up as 
expert required and a pool of volunteer experts would review the 
requests.  I'm just saying...

2) Possibly related cross area work: There's some work that's being done 
in other areas, but I asked around and there isn't one model that pulls 
it all together.  But, there are data models being developed by vendors 
in other areas and I think we owe it ourselves to have a look at them 
and see what if anything is missing.  It's nice if we as security 
practitioners say we want to know 1..n pieces of data about an asset, 
but if that asset isn't going to give that data up we're not going to be 
getting anywhere.

a) NETMOD (https://datatracker.ietf.org/wg/netmod/): NETMOD is a wg in 
the Operations and Management area that's working on data models for 
system management (draft-ietf-netmod-system-mgmt), ip management 
(draft-ietf-netmod-ip-cfg), routing management 
(draft-ietf-netmod-routing-cfg), and interfaces 
(draft-ietf-netmod-interfaces-cfg).  If this proposed WG thinks it's 
going to also provide a data model for some of these same things - the 
models better be aligned.  And yeah I know NETMOD uses YANG, but they've 
got data node figures and that means you don't have to read the YANG ;)

b) SCIM (https://datatracker.ietf.org/wg/scim/): SCIM is a wg in the 
Applications area that's working on cross-domain identity management. 
Seems like if we're going to be using user identity data that we're 
aligned and maybe even use their schema.

c) GEOPRIV (https://datatracker.ietf.org/wg/geopriv/): GEOPRIV is a wg 
in Real-time Applications and Infrastructure Area that produced RFCs on 
both civic and geospatial data which we and NETMOD ought to be using. 
For civic addresses, the GEOPRIV WG produced the Civic Location Format 
for Presence Information Data Format Location Object (PIDF-LO) 
(RFC5139), which builds on DHCPv4/v6 Option for Civic Addresses 
Configuration Information (RFC4766) and is extended by RFC 6848*, 
there's a whole lot more in those RFCs for civic locations.**  For 
geospatial (or geodetic) coordinates, there's DHCPv4/v6 Options for 
Coordinate-Based Location Configuration Information (RFC6225) and 
there's got to be some XML schema for it somewhere.

* Because you may need to know the pole # to which your router is attached.

** Because you may need to know the cubicle # where your router is. 
Note: the format for civic and postal information differs from country 
to country and RFC 4776 captures some of that.

3) s5.3:  Maybe do the data model like this to save some trees:

  +-- Asset
    +-- Person
    +-- Organization
    +-- IT Asset
      +-- System
      +-- Software
      +-- Database
      +-- Network
      +-- Service
      +-- Data
      +-- Computing Device
      +-- Circuit
      +-- Website

4) Global Ids: I'm curious why there's not one identifier to rule them 
all?  I get that assets can have more than one identifier depending on 
the management domain they're in (like I've got an SSN, DL, and Employee 
#), but doesn't the enterprise need one way to unique identify an asset? 
  If we're looking for one might I suggest Universally Unique IDentifier 
(UUID) URN Namespace (RFC 4122), but there might be others out there.

5) Circuit/ai:circuit: I'm having visions of circuit-switched networks 
;) Is this describing the physical connections between two entities?

6) ai:computing-device:  Whole lotta questions here:

a) distinguished-name/fqdn/hostname: If I were to do this, I'd have an 
element name that had subelements of the three here and the other names 
used in the document.

b) connections: Drilling down in the subelements: I'd add references for 
the IPv4/v6, MAC, and URI formats and maybe even subnet (RFC922 maybe)*. 
Do we need to know about other types of connections usb, firewire, 
thunderbolt, etc. Finally, hasn't somebody already done the IPv4/v6/MAC 
addresses in XML with the proper constraints?

* Something like: The syntax for IPv4 addresses described in this 
document MUST conform to [RFC791].  The syntax for IPv6 addresses 
described in this document MUST conform to [RFC3513].  The syntax for 
MAC addresses described in this document MUST conform to [802].  The 
syntax for the URIs described in this document MUST conform to 
[RFC3986]. etc.

c) Additional info: After clicking on about my mac, don't you want to 
know a little more like bios/firmware version, memory, storage capacity, 
processor speed, cache size, etc.?  Or do you think the information 
listed there is enough to uniquely identify the computing-device?

d) For hostname you could informatively refer to  RFC 1178 for choosing 
good hostnames.

7) ai:network: ip-net-range is there a reason you can't have more than 
one block of addresses?  Right now it's just one or none.  Don't we want 
to know what other networks it connects to (wait that's done later never 
mind)?

8) ai:organization: also a couple here:

a) There's got to be XML for email and telephone numbers with the proper 
constraints from W3C?  mailto URI [RFC6068] and tel URI [RFC3966]?

b) Why only website?  What about my orgs twitter feed? :)

c) Should stuff like DUNS # be listed here or is that synthetic-id?

9) ai:person: a couple here too:

a) email-address/telephone-number: see earlier comments.  And, do we 
need an element for jabber id?

b) Way back in the day PKIX produced RFC 3739, Qualified Certificates 
Profile, which describes "a certificate whose primary purpose is to 
identify a person with a high level of assurance, where the certificate 
meets some qualification requirements defined by an applicable legal 
framework," ... blah, blah EU Directive.  Basically, it stuff you'd put 
in a certificate to better identify the subject instead of being stuck 
with only the RDNs specified in RFC 5280.  Stuff like placeOfBirth, 
gender, countryOfCitizenship, and countryOfResidence and not to be 
outdone it also allows for biometric data.  Some of these you might want 
to use to identify a person and I'm not sure they're in SCIM or 
inetOrgPerson.

10) ai:service: I think for the port # and port name you should be 
pointing to the port registry:
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml
I think you might also need to include protocol because not all services 
available on a port are available on all protocols (tcp, udp,sctp, dccp).

11) ai-system/ai-website: Where's parent defined?  Isn't it asset?

12) Energy/Power: I was surprised to not see any elements addressing 
energy/power.  I'm thinking this data would be collected and if the 
temperature of my router is really, really hot I'd love to know because 
it might be one fire ;)

That's it for now.

spt

On 9/23/12 2:49 PM, Adam Montville wrote:
> All:
>
> I'm pleased to announce that I have transformed the NIST IR 7693 into an
> RFC format and submitted it for our consideration (see post notification
> e-mail below).  Please note that this transformation is just that ­ a
> transformation.  I have taken liberties where necessary (mainly for
> formatting purposes), but the major points, content, and style of the
> original document remain intact.  There are sure to be issues with the
> document as posted.  For example, it is unclear to me what can and cannot
> be normatively referenced with respect to this transformation.  There are
> also several areas for IANA considerations beyond registering the asset
> identification namespace (extensions  to asset types and relationships,
> for example).
>
> I look forward to working these, and other, issues on this list.
>
> Finally, a world of thanks goes to John Wunder, Adam Halbardier, and David
> Waltermire for their effort in getting IR 7693 finalized ­ this is really
> their work.
>
> Regards,
>
> Adam
>
>
>
> On 9/23/12 11:39 AM, "[e-mail]" <[e-mail]>
> wrote:
>
>>
>> A new version of I-D, draft-montville-sacm-asset-identification-00.txt
>> has been successfully submitted by Adam W. Montville and posted to the
>> IETF repository.
>>
>> Filename:	 draft-montville-sacm-asset-identification
>> Revision:	 00
>> Title:		 Asset Identification
>> Creation date:	 2012-09-23
>> WG ID:		 Individual Submission
>> Number of pages: 73
>> URL:
>> http://www.ietf.org/internet-drafts/draft-montville-sacm-asset-identificat
>> ion-00.txt
>> Status:
>> http://datatracker.ietf.org/doc/draft-montville-sacm-asset-identification
>> Htmlized:
>> http://tools.ietf.org/html/draft-montville-sacm-asset-identification-00
>>
>>
>> Abstract:
>>    Asset identification plays an important role in an organization's
>>    ability to quickly correlate different sets of information about
>>    assets.  This document provides the necessary constructs to uniquely
>>    identify assets based on known identifiers and/or known information
>>    about the assets.  This document describes the purpose of asset
>>    identification, a data model for identifying assets, methods for
>>    identifying assets, and guidance on how to use asset identification.
>>    It also identifies a number of known use cases for asset
>>    identification.
>>
>>
>>
>>
>>
>> The IETF Secretariat
>>
>>
>>
>
>
>
>
> _______________________________________________
> sacm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm
>