From: Randy Turner (rturner@amalfisystems.com)
Date: Thu Sep 18 2008 - 13:11:42 EDT
see below....
R.
Begin forwarded message:
> From: "Stephen Hanna" <shanna@juniper.net>
> Date: September 5, 2008 12:07:32 PM PDT
> To: "Randy Turner" <rturner@amalfisystems.com>
> Cc: "Paul Sangster" <Paul_Sangster@symantec.com>, <nea@ietf.org>
> Subject: RE: [Nea] proposals for attribute categories and
> attributes, etc.
>
> Sorry, this email escaped prematurely. Let me try again.
>
> 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.
>
> PSTN_Fax_Enabled
> ----------------
>
> I think you made a good case for standardizing this as a
> security-related attribute for hard copy devices, since
> fax can be used to cause resource depletion and denial
> of service. I wonder whether this even applies to non
> hard copy devices, since receiving faxes on a desktop
> PC can eat up hard drive space.
>
> Admin_PW_Enabled
> ----------------
>
> I think we agree on this, with a change in name to
> "Factory-Default-PW-Enabled" or something like that.
>
> SMI Subtrees
> ------------
>
> I think we agree that this has been settled. HCD can
> get an SMI PEN for attributes of narrow interest or
> submit Internet Drafts for those of broad interest.
>
> Software Modules
> ----------------
>
> I look forward to seeing your comments on this.
>
> Thanks,
>
> Steve
>
>> -----Original Message-----
>> From: Randy Turner [mailto:rturner@amalfisystems.com]
>> Sent: Tuesday, August 26, 2008 5:12 PM
>> To: Stephen Hanna
>> Cc: Paul Sangster; nea@ietf.org
>> 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: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On
>>>> Behalf Of Randy Turner
>>>> Sent: Sunday, August 17, 2008 7:05 PM
>>>> To: Paul Sangster
>>>> Cc: nea@ietf.org
>>>> 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
>>>> Nea@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/nea
>>>>
>>>
>>
>>
>
This archive was generated by hypermail 2.1.4 : Thu Sep 18 2008 - 13:11:52 EDT