Subject: Re: [Nea] Nea Digest, Vol 34, Issue 5

From: Brian Ford <[email-masked]>
Date: Fri, 29 Aug 2008 12:14:09 -0400

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, "[email-masked]" <[email-masked]> wrote:
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 26 Aug 2008 14:12:14 -0700
> From: Randy Turner <[email-masked]>
> Subject: Re: [Nea] proposals for attribute categories and attributes,
> etc.
> To: Stephen Hanna <[email-masked]>
> Cc: [email-masked], Paul Sangster <[email-masked]>
> Message-ID: <[email-masked]>
> 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: [email-masked] [mailto:[email-masked]] On
>>> Behalf Of Randy Turner
>>> Sent: Sunday, August 17, 2008 7:05 PM
>>> To: Paul Sangster
>>> Cc: [email-masked]
>>> 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
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/nea
>>> 
>> 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Nea mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nea
> 
> 
> End of Nea Digest, Vol 34, Issue 5
> **********************************

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

---

From: Randy Turner <[email-masked]>
Date: Fri, 29 Aug 2008 13:13:12 -0700

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.

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.

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?

Let me know if I've misread or misinterpreted your previous text.

Thanks again,
Randy

---

From: Brian Ford <[email-masked]>
Date: Fri, 29 Aug 2008 18:51:43 -0400

Randy,

Inline.

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

> a separate copy of the data depending upon the "status assessment

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.
  
> aware of both of these aspects of the attributes it receives from a

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.
Liberty,

Brian