Subject: [sacm] Fwd: I-D Action: draft-handt-sacm-asset-identifiers-00.txt

From: Sean Turner <[email-masked]>
Date: Thu, 11 Jul 2013 12:51:33 -0400

More food for thought.

spt

-------- Original Message --------
Subject: I-D Action: draft-handt-sacm-asset-identifiers-00.txt
Date: Thu, 11 Jul 2013 09:50:15 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title           : sacm: Asset Identifier
	Author(s)       : Russ Housley
                           Sean Turner
	Filename        : draft-handt-sacm-asset-identifiers-00.txt
	Pages           : 7
	Date            : 2013-07-11

Abstract:
    This document examines the asset identifiers available for sacm and
    it proposes that OIDs (Object Identifiers) be selected as the asset
    identifier format.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-handt-sacm-asset-identifiers

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-handt-sacm-asset-identifiers-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Adam Montville <[email-masked]>
Date: Thu, 25 Jul 2013 17:04:01 +0000

Being the transcriber of NISTS Asset Identification standard to an I-D format (now expired), I have some questions about this proposal.  First, however, I like the way this reads and flows and I enjoyed reading it, much like I enjoyed reading the alternate architecture document.

It seems that draft-handt-sacm-asset-identifiers-00 is squarely focused on instance-level identity, identification, and identifiers.  I believe, that we have several levels of "identification" requirements.  We do want instance-level identification, and I believe OIDs, as proposed, could be a good solution.  I believe we also want class-level identification, for which we have been considering CPE.

For example, I may have several OIDs, one for each of a Windows Server 2008 instance, RHEL 6 instance, Windows Server 2012 instance, and Solaris 9 instance.  Now, I want to find all the assets in the "Windows" class, which would be the set of two OIDs representing the WS2008 and WS2012 instances.  We could leave it up to implementers to provide this type of functionality, but would it not be useful to have some standardized way to represent that class?

An honest question: How would this proposal handle class-level identification?  Or, do we collectively believe there is no such need?

Adam  

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sean Turner
> Sent: Thursday, July 11, 2013 9:51 AM
> To: [email-masked]
> Subject: [sacm] Fwd: I-D Action: draft-handt-sacm-asset-identifiers-00.txt
> 
> More food for thought.
> 
> spt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
> 
> ...

This message and attachments may contain confidential information.  If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited.  Please notify the sender immediately and permanently delete the message and any attachments.

---

From: Adam Montville <[email-masked]>
Date: Thu, 25 Jul 2013 17:36:56 +0000

I may have answered my own question actually digging into it.  So, if I'm understanding this right, it seems like we'd be seeing arcs that would have OIDs that are named, which would have some node that acts as a class of the instances found below...  Maybe I'm still wrong.  More digging.

> Adam Montville
> Sent: Thursday, July 25, 2013 10:04 AM
> To: Sean Turner; [email-masked]
> Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-asset-identifiers-
> 00.txt
> 
> Being the transcriber of NISTS Asset Identification standard to an I-D format
> (now expired), I have some questions about this proposal.  First, however, I
> like the way this reads and flows and I enjoyed reading it, much like I enjoyed
> reading the alternate architecture document.
> 
> It seems that draft-handt-sacm-asset-identifiers-00 is squarely focused on
> instance-level identity, identification, and identifiers.  I believe, that we have
> several levels of "identification" requirements.  We do want instance-level
> identification, and I believe OIDs, as proposed, could be a good solution.  I
> believe we also want class-level identification, for which we have been
> considering CPE.
> 
> For example, I may have several OIDs, one for each of a Windows Server
> 2008 instance, RHEL 6 instance, Windows Server 2012 instance, and Solaris 9
> instance.  Now, I want to find all the assets in the "Windows" class, which
> would be the set of two OIDs representing the WS2008 and WS2012
> instances.  We could leave it up to implementers to provide this type of
> functionality, but would it not be useful to have some standardized way to
> represent that class?
> 
> An honest question: How would this proposal handle class-level
> identification?  Or, do we collectively believe there is no such need?
> 
> Adam
> 
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Sean Turner
> > Subject: [sacm] Fwd: I-D Action:
> > draft-handt-sacm-asset-identifiers-00.txt
> >
> > More food for thought.
> >
> > spt
> >
> > Internet-Draft directories: http://www.ietf.org/shadow.html or
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> >
> This message and attachments may contain confidential information.  If it
> appears that this message was sent to you by mistake, any retention,
> dissemination, distribution or copying of this message and attachments is
> strictly prohibited.  Please notify the sender immediately and permanently
> delete the message and any attachments.

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 25 Jul 2013 13:52:08 -0400

On 7/25/2013 1:04 PM, Adam Montville wrote:
> An honest question: How would this propsal handle class-level identification?  Or, do we collectively believe there is no such need?

There is definitely a need for a class-level ID.  In fact, from a SACM 
perspective, I'd say it's more important than an instance-level ID.

--gun

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 26 Jul 2013 07:25:58 +0000

OIDs are basically a tree structure. One can design the tree so that OIDs belonging to the same class are grouped under the same node. 

Would this be sufficient? 

Regards,

Dan

> Sent: Thursday, July 25, 2013 8:37 PM
> I may have answered my own question actually digging into it.  So, if
> I'm understanding this right, it seems like we'd be seeing arcs that
> would have OIDs that are named, which would have some node that acts as
> a class of the instances found below...  Maybe I'm still wrong.  More
> digging.
> 
> > Of Adam Montville
> > Being the transcriber of NISTS Asset Identification standard to an I-D
> > format (now expired), I have some questions about this proposal.
> > First, however, I like the way this reads and flows and I enjoyed
> > reading it, much like I enjoyed reading the alternate architecture
> document.
> >
> > It seems that draft-handt-sacm-asset-identifiers-00 is squarely
> > focused on instance-level identity, identification, and identifiers.
> > I believe, that we have several levels of "identification"
> > requirements.  We do want instance-level identification, and I believe
> > OIDs, as proposed, could be a good solution.  I believe we also want
> > class-level identification, for which we have been considering CPE.
> >
> > 2008 instance, RHEL 6 instance, Windows Server 2012 instance, and
> > Solaris 9 instance.  Now, I want to find all the assets in the
> > "Windows" class, which would be the set of two OIDs representing the
> > WS2008 and WS2012 instances.  We could leave it up to implementers to
> > provide this type of functionality, but would it not be useful to have
> > some standardized way to represent that class?
> >
> > This message and attachments may contain confidential information.  If
> > it appears that this message was sent to you by mistake, any
> > retention, dissemination, distribution or copying of this message and
> > attachments is strictly prohibited.  Please notify the sender
> > immediately and permanently delete the message and any attachments.
> This message and attachments may contain confidential information.  If
> it appears that this message was sent to you by mistake, any retention,
> dissemination, distribution or copying of this message and attachments
> is strictly prohibited.  Please notify the sender immediately and
> permanently delete the message and any attachments.

---

From: Sean Turner <[email-masked]>
Date: Fri, 26 Jul 2013 12:17:12 +0200

Dan beat me to it.  It's a tree structure that may or may not have 
meaning at each "node".  It depends on what we're looking for.

spt

---

From: "Baker, Jon" <[email-masked]>
Date: Mon, 29 Jul 2013 11:59:55 +0000

Quick comment on the draft. I found the following text in the CPE section:

"  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."

CPE 2.3 allows for multiple CPE dictionaries to be maintained. NIST operates the Official CPE dictionary at this time, but we certainly envisioned vendors operating their own CPE dictionaries. For CPE, there are outstanding questions of how best to manage cpe names.

To be clear, CPE should not be considered an Asset Identifier. It was not designed for that purpose.

Thanks,

Jon

============================================
Jonathan O. Baker
G022 - IA Industry Collaboration
The MITRE Corporation
Email: [email-masked]

>Sent: Friday, July 26, 2013 6:17 AM
>To: Adam Montville
>Cc: Romascanu, Dan (Dan); [email-masked]
>Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-asset-identifiers-00.txt
>
>> OIDs are basically a tree structure. One can design the tree so that OIDs
>belonging to the same class are grouped under the same node.
>>
>Of