Subject: Re: [Nea] proposals for attribute categories and attributes, etc.

From: Randy Turner <[email-masked]>
Date: Sun, 17 Aug 2008 16:04:58 -0700

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

---

From: "Stephen Hanna" <[email-masked]>
Date: Tue, 26 Aug 2008 14:44:19 -0400

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,
> 
>                                               is configured 
> to acquire  
>                                               manner. If the 
> device is  
>                                                enumerations 
> listed in  
>                                                Registry".  An 
> example

---

From: Randy Turner <[email-masked]>
Date: Tue, 26 Aug 2008 14:12:14 -0700

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