Re: [Nea] IETF NEA PA Categories and Attributes [Was Re: Nea Digest, Vol 34, Issue 5]

[Randy Turner <[e-mail]>]

Hi Brian,

After thinking about  the comparison between SNMP and NEA, there are
similarities when it comes to a management entity desiring to know the  
state of
another device on the network, but the similarities pretty much end  
there, so I agree
that SNMP and NEA are not quite the same thing.  They share the common  
property
of potentially having multiple "assessment methods" per your  
terminology.

I would like to characterize one of the differences between NEA and  
SNMP, and that is,
the frequency of state change.

Over the years, SNMP has evolved to better handle dynamic, and  
potentially high frequency,
state changes so that management stations can reflect the most up-to- 
date status possible.

I think the problem that NEA is trying to solve, whereby we're trying  
to assess the "posture" of
a device, is different in that the "frequency" of posture change is  
much lower.

SNMP has evolved to deal with potentially high-frequency state changes  
in the device, wherein I
am of the opinion that "postures" don't change that often, or at least  
that's my expectation.  If the
security posture of a device (a posture that can be remediated) is  
changing at a high frequency,
and you require the services of a posture monitoring/posture  
remediation service to deal with this,
then I would say that there is a much larger site administrative  
problem that needs to be dealt
with. A problem that is probably out of scope for NEA.

And if this "low frequency posture change" assumption is correct, we  
shouldn't be erecting possibly
multiple complex assessment methods that have varying degrees of  
quality or timeliness.  It seems
like we could just "standardize" on an event driven mechanism that  
automatically notifies some
"management entity in the sky" that a posture change has occurred.   
Like SNMP traps/informs, this
technique would scale better as the topology grows very large, but  
requires that posture changes
be an infrequent event so that chatter is minimized. With  
notifications, there's no traffic unless
some posture is changing somewhere.

The notification could indicate "what" changed so as to possibly make  
remediation quicker.

To summarize this email, I guess I'm proposing that a property of a  
"posture" is that it doesn't change
that often; i.e., the frequency of posture change is low. As opposed  
to the types of potentially "high frequency"
status events that exist in certain MIBs that SNMP must manage.


Randy


On Aug 29, 2008, at 3:51 PM, Brian Ford wrote:

> Randy,
>
> Inline.
>
> On 8/29/08 4:13 PM, "Randy Turner" <[e-mail]> wrote:
>
>>
>> Hi Brian,
>>
>> Thanks for the note.
>>
>> I do agree that a management entity may obtain attributes from a
>> device using any number of "assessment methods", but it seems to me
>> that the management entity would only "maintain" one copy of the data
>> set that was obtained (however the attributes were collected).
>>
>> Each time the management entity acquires attributes (whichever
>> assessment method is used), it would just overwrite the previous
>> collected
>> attributes for the particular MAC address.
>
> You can do it that way but Id assert that the solution winds up losing
> access to some really valuable data.  Namely, what changed.  Having
> implemented our flavors a few times for a few different folks I can  
> tell you
> "what changed" becomes important.
>
>>
>> SNMP management stations (in theory) have the same problem - they
>> could issue a "get" for device status information, or optionally,
>> receive
>> a trap with status updates, or more reliably, an "inform" message  
>> with
>> status updates.  Devices could implement their SNMP agents with
>> similar assessment methods as you suggest, including more distributed
>> forms of acquisition such as agent-x.  However, in the management
>> stations implementations I'm aware of, it's not clear to me that keep
>> a separate copy of the data depending upon the "status assessment
>> method"
>> used in the device.
>
> OK.  I agree with your SNMP description.  Using that solution your PDP
> actions are based on state where all the variables that comprise  
> that state
> are hopefully all taken at approximately the same time.  State = a  
> snapshot
> in time.  In my opinion that's what SNMP was designed to do well.
>
> You can look at this (NEA) as being the same problem (as SNMP).  I  
> don't.
> NEA solutions offer the capability to programmatically change how an
> endpoint accesses and transmits data across a network based on  
> information
> received from the endpoint and various devices in the network about  
> the
> endpoint over time.
>
> In my mind SNMP is like solving a computer science "train track"  
> switching
> problem where one student looks out over the trains and the tracks.   
> NEA is
> like solving the same problem in a darkened room with students  
> spread around
> the track.  Some have small lights.  Others can only hear the  
> train.  Still
> others have their fingers on the track.  But there is only one  
> person who
> controls all the switches.
>
>>
>> My interpretation of your text seems to suggest that there are both
>> "qualitative" and "trust" implications that are associated with
>> assessment
>> methods, and that you believe that the management entity should be
>> aware of both of these aspects of the attributes it receives from a
>> device.
>> Is this correct?
>
> Good question.  I'm not sure.  I do think we need to look at  
> multiple data
> sources and multiple snapshots of time (i.e. Not over write the  
> previous
> data).
>
> Think about this.  How do you envision handling the problem where an
> endpoint changes state?  Do you intend to act on that after you  
> discover it
> because you queried the endpoint?  Will your endpoint be capable of
> signaling a state change?  If an endpoint suddenly signals a state  
> change
> would you want the capability of having one action or multiple  
> possible
> actions?
>
>>
>> Let me know if I've misread or misinterpreted your previous text.
> Sure.
>>
>> Thanks again,
>> Randy
> Liberty,
>
> Brian
>>
>>
>>
>> On Aug 29, 2008, at 9:14 AM, Brian Ford wrote:
>>
>>>
>>> Randy,
>>>
>>> I thought that some of the attributes you proposed would be vary
>>> useful if
>>> we could explain the context from which they were derived.  I
>>> defined that
>>> sort of context in my previous message to the list.
>>>
>>> For example: if I'm writing rules for a PDP and I can:
>>>
>>> 1- Assume that I have data from an endpoint, AND
>>> 2- Assume the data was the result of a query to the endpoint AND
>>> 3- the data says that the device can forward bits (i.e. Route)
>>>
>>> That would make for an interesting rule about how I might apply
>>> policy to
>>> that device (which is now a router and not an endpoint).
>>>
>>> It would be perhaps even more interesting if I had probed (scanned)
>>> that
>>> device and the result of the probe says that it something else that
>>> should
>>> not be able to route.
>>>
>>> Liberty,
>>>
>>> Brian
>>>
>>>
>>> On 8/27/08 3:00 PM, "[e-mail]" <[e-mail]>
>>> wrote:
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>>
>>>> Message: 1
>>>> Date: Tue, 26 Aug 2008 14:12:14 -0700
>>>> From: Randy Turner <[e-mail]>
>>>> Subject: Re: [Nea] proposals for attribute categories and  
>>>> attributes,
>>>> etc.
>>>> To: Stephen Hanna <[e-mail]>
>>>> Cc: [e-mail], Paul Sangster <[e-mail]>
>>>> Message-ID: <4A6D7DA5-193A-4FF4- 
>>>> [e-mail]>
>>>> Content-Type: text/plain; charset=US-ASCII; format=flowed;  
>>>> delsp=yes
>>>>
>>>> Hi Steve,
>>>>
>>>> Thanks for the note.
>>>>
>>>> I'll try and address your comments one at a time, using your  
>>>> labels.
>>>>
>>>> Forwarding Enabled
>>>> ----------------------------
>>>> From the perspective of embedded devices, the application set is  
>>>> more
>>>> or less
>>>> "locked down" so you know that, if "something" can forward, you  
>>>> know
>>>> exactly
>>>> the circumstances under which it does forward "bits". If you have  
>>>> an
>>>> architecture
>>>> that allows arbitrary apps to be added, then I agree, you're never
>>>> quite sure what's
>>>> going on.  This situation might call for an attribute that  
>>>> indicates
>>>> whether or not the
>>>> application set can be modified by some entity other than the
>>>> manufacturer. If the
>>>> device can be updated with arbitrary apps, then a forwarding
>>>> attribute
>>>> may not
>>>> make sense. But if the device has a "locked down" application
>>>> environment, and there is
>>>> an attribute that can allow forwarding by the firmware, then maybe
>>>> this would make
>>>> more sense.  I'm open to discussing this further....
>>>>
>>>> Secure Time Enabled
>>>> -----------------------------
>>>> The idea here is that we wanted to make sure that if a device was
>>>> acquiring it's notion
>>>> of time from "some source", that the source be trusted as a secure
>>>> source, and that the
>>>> manner in which the time is acquired cannot be tampered with  
>>>> enroute
>>>> from the source
>>>> to the device.  As you suggest, we wanted to protect the use of
>>>> certificate checking (yes,
>>>> many high-end multifunction peripherals have cert mgmt capability),
>>>> and any other
>>>> functionality that requires accurate time, I had a feeling that the
>>>> use of "secure" might be
>>>> interpreted any number of ways. I think it's more important that if
>>>> it's possible to
>>>> configure a device to use a time acquisition method that is NOT
>>>> secure, or a time source
>>>> that is not "approved" by the site, then this type of attribute  
>>>> would
>>>> be a part of the device
>>>> "posture".  I'll try and come up with another way to indicate this
>>>> basic 2-part requirement.
>>>> I think "time source" might be one attribute (which was part of the
>>>> proposal), and then, if the device
>>>> is capable of being configured with a protocol that does not  
>>>> protect
>>>> the integrity of the
>>>> time acquired from a trusted source, then we need a way to prevent
>>>> this from happening (if
>>>> this is a site requirement).
>>>>
>>>> I'll mull over your suggestion about NOT delaying the base NEA  
>>>> specs,
>>>> and deferring this
>>>> information to another document, but the solution may be so concise
>>>> as
>>>> to essentially produce
>>>> a 1-page draft :)  If we can come up with something concise (in a
>>>> timeframe that doesn't
>>>> delay the NEA schedule) then it would be nice to spec it....if we
>>>> can't then I agree we would
>>>> have to address it in some later spec.
>>>>
>>>> Configuration State
>>>> --------------------------
>>>> You are correct, this type of value may consist of attributes that
>>>> are
>>>> not necessarily, but then again
>>>> they may be security related - only the vendor would know for sure.
>>>> It could be that this hash
>>>> is a hash over security attributes that (for whatever reason)  
>>>> aren't
>>>> standardized or haven't been
>>>> spec'd in any way. This value allows for vendors (or potentially  
>>>> site
>>>> admins) to define their own
>>>> set of posture attributes without having to worry about
>>>> standardization or registries, etc.
>>>>
>>>> You'll hear me say this more than once, but the concern is that  
>>>> we're
>>>> defining a protocol that
>>>> allows administrators to determine if a device configuration is
>>>> conformant to some local security
>>>> policy.  And I'm assuming that, if this WG doesn't do it, that some
>>>> future standards entity will
>>>> define a way to remediate a situation where one or more devices are
>>>> not conformant.
>>>>
>>>> This is a very nice and convenient system that I think would be of
>>>> high value to administrators.
>>>> And even though we've used the word "security" in the charter  
>>>> (and in
>>>> your email), this protocol
>>>> could actually work with any type of device attributes. In the
>>>> future,
>>>> if a site decides to deploy a
>>>> posture monitoring and remediation system that monitors and
>>>> remediates
>>>> the "security" attributes, it
>>>> seems likely that someone might want to use the same infrastructure
>>>> for other types of attributes
>>>> as well.  I know I'm breaching on stuff that's out of scope and  
>>>> not a
>>>> part of the charter, but it seems
>>>> logical that once we have a complete monitoring/remediation system,
>>>> someone's going to ask
>>>> the question about "configuration" management.  At least that's my
>>>> assumption.
>>>>
>>>> In lieu of any other "system" that does monitoring/remediation, the
>>>> "configuration state" attribute
>>>> would allow custom postures to be defined that could consist of
>>>> vendor-
>>>> specific security attributes,
>>>> non-security-related attributes, or a mix, and still use (at least)
>>>> the posture monitoring and reporting
>>>> capabilities that would be possible with our initial NEA work.
>>>>
>>>> PSTN_Fax_Enabled
>>>> ---------------------------------
>>>> Some hardcopy device vendors would consider this a security
>>>> attribute,
>>>> in that the device-local FAX
>>>> capability could allow an unauthorized party access to device
>>>> resources (or to exhaust device
>>>> resources) in some manner.
>>>>
>>>> This would not be what I would call a "Generic" attribute  
>>>> applicable
>>>> to all devices, but instead only
>>>> relegated to hardcopy devices.
>>>>
>>>> Admin_PW_Enabled
>>>> -----------------------------
>>>> I agree about the name of this attribute - we could use something
>>>> like
>>>> "Factory-default-PW-Enabled"
>>>> or some equivalent. Even though I considered this a hardcopy issue,
>>>> it's not something that a
>>>> Linux, Windows, or Mac OS X admin would run into, since those
>>>> installation processes require the
>>>> installer (local or remote) to define root or admin credentials as
>>>> well as their associated passwords.
>>>> However, to your point, it could apply to other types of network
>>>> devices as well. And to reiterate, I
>>>> agree that a different name could be used.
>>>>
>>>>
>>>> SMI Subtrees
>>>> ------------------
>>>> I may have worded it incorrectly, but I think you have summarized  
>>>> the
>>>> concern that we were thinking
>>>> about.
>>>>
>>>> Software Modules
>>>> ------------------------
>>>> Let me go back and review the source of this particular issue. I'll
>>>> get back to you (and the list).
>>>>
>>>>
>>>> Thanks again for the comments!  More are welcome!
>>>>
>>>> Randy
>>>>
>>>>
>>>>
>>>> On Aug 26, 2008, at 11:44 AM, Stephen Hanna wrote:
>>>>
>>>>> Randy,
>>>>>
>>>>> Thanks for sending your comments. I found them quite interesting!
>>>>> I'm sorry that it has taken me a few days to respond. I was on
>>>>> holiday for a few days last week.
>>>>>
>>>>> Let me address your suggestions individually. Note that these
>>>>> are my personal comments and I'm sending them as an individual
>>>>> not as a WG chair. Please consider them in that context.
>>>>>
>>>>> Forwarding Enabled: I like the idea but forwarding can happen
>>>>> at the application layer, which is almost impossible to detect.
>>>>> Of course, this might not be an issue for an embedded device.
>>>>> Maybe three values are called for: Forwarding Enabled (known
>>>>> to be happening), Forwarding Possible (could be happening but
>>>>> not sure), and Forwarding Disabled (strongly believed that
>>>>> no forwarding is happening, as when there's no application
>>>>> software and the operating software does not forward).
>>>>>
>>>>> Secure Time Enabled: Having a good source of time is important
>>>>> for many security protocols (for checking expiration dates on
>>>>> certificates, for example). However, this attribute does raise
>>>>> a question: what is the definition of "secure" here?
>>>>> Is it secure to use an onboard source of time? Probably.
>>>>> What about SNTP or NTP? Probably not, unless you use some
>>>>> form of authentication. Are the authentication techniques
>>>>> described in RFC 1305 (NTPv3) enough? Maybe not, since they
>>>>> are based on DES and MD5. SNTPv4 (RFC 4330) doesn't specify
>>>>> a security algorithm. You could use the system described in
>>>>> draft-ietf-ntp-autokey-04.txt but that's just an Internet Draft.
>>>>> And which algorithms and identity schemes from that spec
>>>>> are being used? Are those still secure? And, as you say,
>>>>> Time Source must also be considered. Using a secure time
>>>>> protocol to fetch time from an untrustworthy time source
>>>>> isn't really secure.
>>>>>
>>>>> Instead of leaving all the decisions to the NEA Client and
>>>>> having the client indicate "Secure Time Enabled" to the
>>>>> NEA Server, it would be more consistent with the rest of
>>>>> NEA if we defined attributes containing the identity of the
>>>>> time source and the parameters used to secure the time source.
>>>>> However, it seems that the specifications that define the
>>>>> algorithms and schemes that would be conveyed in these
>>>>> attributes are still in Internet Draft form. Instead of
>>>>> delaying the NEA specs while the NTP specs are finished,
>>>>> I suggest that the secure time-related attributes go into
>>>>> a separate Internet Draft that could provide the necessary
>>>>> level of detail while avoiding the need for the NEA specs
>>>>> to depend on the NTP specs.
>>>>>
>>>>> Minimum Cipher Suite: Most endpoints have a variety of
>>>>> different ciphersuite selections for different purposes:
>>>>> web browsing, email, VPN, etc. Even within one purpose,
>>>>> who's to say which ciphersuite is the "minimum"? I don't
>>>>> think we should include this as a standard attribute.
>>>>>
>>>>> Configuration State: This seems more like a configuration
>>>>> management tool than a security measure. NEA is not chartered
>>>>> to examine all configuration information, just configuration
>>>>> information that "pertains to an organization's security policy".
>>>>> If, as you suggested, vendors want to define vendor-specific
>>>>> NEA attributes, they can do so by using their own SMI PEN
>>>>> in the PA Message Vendor ID and/or PA-TNC Attribute Vendor
>>>>> ID fields. Then the vendor can write their own Posture
>>>>> Validator to check these attribute values. Alternatively,
>>>>> some people may supply flexible Posture Validators that allow
>>>>> users to check for specific values for vendor-specific attributes.
>>>>>
>>>>> PSTN_Fax_Enabled: Why is this security related? As noted
>>>>> above, NEA is not chartered to manage all configuration
>>>>> just security-related configuration.
>>>>>
>>>>> Admin_PW_Enabled: The sad thing is that this is probably
>>>>> quite useful. People often take a device out of the box
>>>>> and plug it into the network with the factory defaults
>>>>> unchanged, including a default admin password. Maybe this
>>>>> attribute should have a different name, though. The issue
>>>>> isn't really whether an admin password is present but
>>>>> whether there is an admin password that is NOT the default.
>>>>> So how about naming the attribute "Admin_PW_Not_Default"?
>>>>> BTW, this is not specific to hard copy devices. It pertains
>>>>> to many kinds of devices.
>>>>>
>>>>> Your question about SMI subtrees doesn't seem relevant.
>>>>> NEA doesn't use OIDs so subtrees aren't relevant. Maybe
>>>>> you meant to talk about SMI Private Enterprise Numbers
>>>>> (SMI PENs, used as Vendor IDs within the NEA specs).
>>>>> Maybe the question is: If HCD defines some PA-TNC
>>>>> attributes, should you use the IETF SMI PEN (0) or
>>>>> some other one? I think that the answer is that HCD
>>>>> should use its own SMI PEN for values that it defines.
>>>>> Of course, if the values are of broader interest, it
>>>>> would be good for you to submit them as Internet Drafts
>>>>> and have them become RFCs and use the IETF SMI PEN.
>>>>> That way, they could be used and known more widely.
>>>>>
>>>>> Your comments on software modules also confused me. PA-TNC
>>>>> and PB-TNC don't assume that there is a BIOS, OS, and
>>>>> applications. The word "BIOS" doesn't appear anywhere in
>>>>> the PA-TNC spec. In fact, PA-TNC does exactly what you
>>>>> suggested! It defines generic attributes (like Numeric
>>>>> Version) that can be applied to any component on the
>>>>> endpoint by using the appropriate PA Subtype (like Operating
>>>>> System). Some devices won't have all the IETF Standard PA
>>>>> Subtypes (like Anti-Malware). That's fine. Maybe there are
>>>>> additional PA Subtypes that are needed for printers. That
>>>>> would be good to know about.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Steve
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [e-mail] [mailto:[e-mail]] On
>>>>>> Behalf Of Randy Turner
>>>>>> Sent: Sunday, August 17, 2008 7:05 PM
>>>>>> To: Paul Sangster
>>>>>> Cc: [e-mail]
>>>>>> Subject: Re: [Nea] proposals for attribute categories and
>>>>>> attributes, etc.
>>>>>>
>>>>>> Hi Paul,
>>>>>>
>>>>>> Per your request, I'm forwarding along a proposal  we discussed
>>>>>> earlier for attribute categories, and corresponding attributes,  
>>>>>> as
>>>>>> well as
>>>>>> a some proposed model/data-type ideas for the WG to consider.
>>>>>>
>>>>>> NEA list members:
>>>>>> I tried to format this in as simple an ASCII format as possible
>>>>>> (spaces for tabs, etc.). Let me know if there is a problem with
>>>>>> readability in certain
>>>>>> email clients...
>>>>>>
>>>>>>
>>>>>> Thanks!
>>>>>> Randy
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> This proposal introduces new attribute categories and  
>>>>>> corresponding
>>>>>> attributes, and also suggests a new model for
>>>>>> managing software on a particular computing device. The text of
>>>>>> this
>>>>>> proposal originates from evolving requirements
>>>>>> being developed by the Printer Working Group (PWG).
>>>>>>
>>>>>> -------------------------------------
>>>>>> PROPOSED CATEGORIES
>>>>>> -------------------------------------
>>>>>>
>>>>>> ===============
>>>>>> "System" Category
>>>>>> ===============
>>>>>>
>>>>>> The "System" category would serve as a "container" for
>>>>>> attributes that
>>>>>> are used by core operating system services in the device.
>>>>>> One corollary for this type of category is the "system" group
>>>>>> of MIB-2
>>>>>> (RFC 1213).
>>>>>>
>>>>>> The following proposed attribute definitions would exist within  
>>>>>> the
>>>>>> "System" category:
>>>>>>
>>>>>> "Forwarding Enabled" - a single-bit field or boolean value that
>>>>>> indicates
>>>>>>                                          whether the system is
>>>>>> performing any forwarding
>>>>>>                                          of "bits" or any kind of
>>>>>> electronic transmissions between interfaces.
>>>>>>
>>>>>> "Secure Time Enabled" - a single-bit or boolean value that
>>>>>> indicates
>>>>>> if the device
>>>>>>                                            is configured
>>>>>> to acquire
>>>>>> the current time in a secure
>>>>>>                                            manner. If the
>>>>>> device is
>>>>>> using something as simple as
>>>>>>                                            SNTP, then the device
>>>>>> would set this value to "False".
>>>>>>
>>>>>> "Time Source" - A variable length field that indicates the
>>>>>> source from
>>>>>> which
>>>>>>                           the device acquires its' notion of the
>>>>>> current date and time.
>>>>>>                           This could be a URL of an SNTP or NTP
>>>>>> time source, or could
>>>>>>                           be some fixed identifier that indicates
>>>>>> that the time is obtained
>>>>>>                           from an onboard clock/calendar.
>>>>>>
>>>>>> "Minimum Cipher Suite" - A variable length string that
>>>>>> represents one
>>>>>> of the
>>>>>>                                             enumerations
>>>>>> listed in
>>>>>> the IANA "TLS Cipher Suite
>>>>>>                                             Registry".  An
>>>>>> example
>>>>>> value would be:
>>>>>>
>>>>>> "TLS_RSA_WITH_AES_256_CBC_SHA256"
>>>>>>
>>>>>>
>>>>>> "Configuration State" - attribute is a 32 byte field that  
>>>>>> uniquely
>>>>>> identifies the state of
>>>>>>                                        any configuration settings
>>>>>> in the device that are included in
>>>>>>                                        creation of the
>>>>>> attribute. A
>>>>>> change to any configuration
>>>>>>                                       setting that is included in
>>>>>> the creation of the attribute MUST
>>>>>>                                       cause a change in this
>>>>>> attributes value.
>>>>>>                                       The configuration settings
>>>>>> included as part of this attribute
>>>>>>                                       SHOULD be administratively
>>>>>> configurable. The rationale
>>>>>>                                       for this single
>>>>>> attribute is
>>>>>> to allow device vendors to utilize
>>>>>>                                       an industry standard
>>>>>> attribute to reflect an arbitrary device
>>>>>>                                       configuration,
>>>>>> consisting of
>>>>>> whatever device-specific
>>>>>>                                       information the
>>>>>> vendor wishes
>>>>>> to include. If for some
>>>>>>                                       reason, a vendor did
>>>>>> not want
>>>>>> to publish these attributes,
>>>>>>                                       they can still utilize
>>>>>> standards-compliant applications to
>>>>>>                                       detect invalid
>>>>>> configurations
>>>>>> and to potentially remediate
>>>>>>                                        the situation.  The
>>>>>> 32-byte
>>>>>> field was chosen to allow the
>>>>>>                                        attribute value to
>>>>>> be a 256-
>>>>>> bit hash over the arbitrary
>>>>>>                                        configuration. This field
>>>>>> would of course have to be
>>>>>>                                        enlarged to support
>>>>>> SHA-512
>>>>>> or some other hash that
>>>>>>                                        produces a value
>>>>>> larger than
>>>>>> 256 bits.
>>>>>>
>>>>>>
>>>>>>
>>>>>> ===============
>>>>>> "HCD" Category
>>>>>> ===============
>>>>>>
>>>>>> The "HCD" category would serve as a container for attributes
>>>>>> that are
>>>>>> specific to "Hard Copy Devices",
>>>>>> which could be a very low-end printer, or a very high-end multi-
>>>>>> function device (fax, scan, print, etc.).
>>>>>>
>>>>>> "PSTN_Fax_Enabled" - a single-bit or boolean value that indicates
>>>>>> whether or
>>>>>>                                          not the PSTN Fax
>>>>>> interface
>>>>>> is enabled.
>>>>>>
>>>>>> "Admin_PW_Enabled" - a single-bit or boolean value that indicates
>>>>>> whether or
>>>>>>                                           not the factory default
>>>>>> administrator password for the
>>>>>>                                           device has been changed
>>>>>> to a "site-appropriate" value.
>>>>>>
>>>>>>
>>>>>> =======
>>>>>> ISSUES:
>>>>>> =======
>>>>>>
>>>>>> The Printer Working Group is soliciting the opinion of the
>>>>>> NEA working
>>>>>> group as to the appropriate
>>>>>> SMI location for a potential HCD category SMI sub-tree.
>>>>>>
>>>>>> The two alternatives under consideration are
>>>>>>
>>>>>> 1. The HCD SMI sub-tree would reside within the SMI tree
>>>>>> being defined
>>>>>> by the NEA working group for the initial "standardized"  
>>>>>> categories.
>>>>>>
>>>>>> or
>>>>>>
>>>>>> 2. The HCD SMI sub-tree would reside within an existing SMI
>>>>>> tree that
>>>>>> has been IANA-assigned to the Printer Working Group.
>>>>>>
>>>>>> The above attribute proposals also pre-suppose the existence of a
>>>>>> "boolean"
>>>>>> data type for the wire-encoding/information model for the PA
>>>>>> protocol.
>>>>>> The PWG
>>>>>> is also proposing that this type of attribute data type be
>>>>>> supported
>>>>>> in the
>>>>>> information model (and presumably wire encoding).
>>>>>>
>>>>>> --------------------------------------------------
>>>>>> Software "Module" Attribute Proposal
>>>>>> --------------------------------------------------
>>>>>>
>>>>>> The TNC model for trusted software configurations presupposes  
>>>>>> that
>>>>>> all
>>>>>> devices are basically PCs, and that the software
>>>>>> architectural model is
>>>>>> based on a "bios", "operating system", and "application" model.
>>>>>>
>>>>>> Since it is reasonable to assume that a network administrator  
>>>>>> might
>>>>>> want to use a single tool for monitoring network device
>>>>>> configurations
>>>>>> in a topology,
>>>>>> and also assuming that devices other than standard PCs are a part
>>>>>> of
>>>>>> this topology, this proposal suggests that the idea behind  
>>>>>> managing
>>>>>> software
>>>>>> components should be "moved up" a level of abstraction. Using the
>>>>>> right type of abstraction would allow practically any type of
>>>>>> device
>>>>>> to be supported
>>>>>> in the management of software components, whether these
>>>>>> components be
>>>>>> "applications",  an "operating system", or a "bios".
>>>>>>
>>>>>> A software component or "module" instance might be a suitable
>>>>>> level of
>>>>>> abstraction to allow non-PC devices to be managed in the same way
>>>>>> as
>>>>>> PC devices.
>>>>>> The software module abstraction would be a complex data type
>>>>>> that can
>>>>>> be multiply instanced. The complex data type would consist of (at
>>>>>> least) 3 pieces of information:
>>>>>>
>>>>>> - Module Type  (This could be a value indicating OS, Bios, or
>>>>>> application, but might
>>>>>>                           not be required at all for remediation.
>>>>>>
>>>>>> - Module Vendor - The manufacturer of this particular software
>>>>>> module
>>>>>>
>>>>>> - Module Name - The name of the module such as "Mac OS X", or
>>>>>>                               "Windows Vista Ultimate"
>>>>>>
>>>>>> - Module Version - This could either be a version number,
>>>>>> build number,
>>>>>>                                 build date and time, or whatever
>>>>>> the vendor uses to
>>>>>>                                 identify unique versions.
>>>>>>
>>>>>> The "module" idea can be either evolved as is, or used to  
>>>>>> stimulate
>>>>>> discussion for
>>>>>> an appropriate level of abstraction to represent individual,
>>>>>> updateable software
>>>>>> components within a device.
>>>>>>
>>>>>> The rationale behind supporting non-PC devices is not
>>>>>> theoretical, in
>>>>>> that there is a "spectrum" of network-connected devices that  
>>>>>> exist
>>>>>> today.
>>>>>> The spectrum originating with devices that utilize only a single,
>>>>>> monolithic software load module, and end with devices that
>>>>>> could have
>>>>>> tertiary
>>>>>> or that utilize a single, monolithic software load, through  
>>>>>> devices
>>>>>> that support a tertiary structure (like PCs), to devices that
>>>>>> utilize a quarternary or even larger number of unique software
>>>>>> components.
>>>>>>
>>>>>> Using the "module" paradigm would allow all of these  
>>>>>> architectural
>>>>>> permutations
>>>>>> to exist simultaneously, and be managed (and remedied) using
>>>>>> similar
>>>>>> methods.
>>>>>>
>>>>>> This is just a first stab at an abstraction that might encompass
>>>>>> all
>>>>>> classes of
>>>>>> devices that wish to utilize the NEA protocols. It is likely that
>>>>>> other information
>>>>>> may be required of this attribute model.
>>>>>>
>>>>>> An example of a monolithic device module would consist of a  
>>>>>> single-
>>>>>> instance
>>>>>> of the module data type:
>>>>>> (Type="System",Vendor="HP", Name="HP Laserjet
>>>>>> System",Version="5J2-R2")
>>>>>>
>>>>>> A typical PC would consist of a multiply-instanced attribute or
>>>>>> attributes:
>>>>>>
>>>>>> (Type="BIOS", Vendor="Phoenix", Name="Phoenix DCore BIOS",
>>>>>> Version-"7R2")
>>>>>> (Type="OS", Vendor="Microsoft", Name="Windows Vista Ultimate",
>>>>>> Version="SP1")
>>>>>> (Type="APP", Vendor="Symantec", Name="AntiVirus",  
>>>>>> Version="3.2R2")
>>>>>> (Type="APP", Vendor="Microsoft", Name="IE", Version="7.3")
>>>>>> (Type="APP", Vendor="Symantec", Name="Firewall", Version="4.3")
>>>>>> (Type="CFG", Vendor="Symantec", Name="fwrules", Version="16")
>>>>>>
>>>>>> Using the "module" abstraction would even allow the creation, and
>>>>>> subsequent management/remediation of individual, updateable
>>>>>> components
>>>>>> like firewall
>>>>>> rulesets, which could be updated without necessarily updating the
>>>>>> application
>>>>>> itself. NOTE: the "CFG" module type as illustrated above.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Nea mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/nea
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> _______________________________________________
>>>> Nea mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/nea
>>>>
>>>>
>>>> End of Nea Digest, Vol 34, Issue 5
>>>> **********************************
>>>
>>>
>>
>
>

_______________________________________________
Nea mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/nea