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

["Stephen Hanna" <[e-mail]>]

Randy,

I apologize for taking a few days to respond to your email.

Forwarding Enabled
------------------
I think we agree that this is a useful security-related attribute.
Most fixed-function endpoints should be able to easily determine
a value for this attribute (Enabled or Disabled). Extensible
endpoints probably cannot determine an appropriate value. So
I suggest there be three values: Enabled, Disabled, and Unknown.

Secure Time Enabled
-------------------
I think that we agreee that if you can prepare and reach some
rough WG consensus on a brief proposal in time for us to stay
on schedule (in the next two weeks or so), then this can go
in the base spec. If not, then it can be specified separately.
There's no shame in having a separate spec, even if brief.
In fact, it will be good to try out our extension process.

Minimum Cipher Suite
--------------------
You didn't respond to my comments. I guess they were compelling
so you agree that this should not be included in the standard
set of attributes?

Configuration State
-------------------

Developing a standard protocol for managing non-security
attributes is out of scope for us. For security attributes
(and arguably for non-security ones also), it's essential
to know WHAT attributes are being reported. Otherwise, you
can't achieve interoperability. We have already defined a
whole protocol for reporting on labelled attributes. It's
called PA-TNC. I suggest that people use that protocol
to report attributes instead of just reporting a hash
with no labels or information about what has been hashed.


Therefore, I suggest that
people who want to report on security attributes should
mark them 

To properly solve the problem you described (reporting on an
arbitrary set of attributes) in 



> -----Original Message-----
> From: Randy Turner [mailto:[e-mail]] 
> Sent: Tuesday, August 26, 2008 5:12 PM
> To: Stephen Hanna
> Cc: Paul Sangster; [e-mail]
> Subject: Re: [Nea] proposals for attribute categories and 
> attributes, etc.
> 
> 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