IDS> Comments on PWG HCD Health Attrs

IDS> Comments on PWG HCD Health Attrs

IDS> Comments on PWG HCD Health Attrs

Stephen Hanna shanna at
Tue Apr 14 18:35:02 UTC 2009

Here are my comments on the February 18 draft of the
PWG Hard Copy Device Health Assessment Attributes.
I have divided them into substantive and not.
I hope that this is useful. I joined your list
for now so that I can participate if these
comments spark discussion.





* The descriptions of both HCD_Certification_State
  and HCD_Configuration_State say that a change in
  the underlying value "MUST cause a change in the
  attribute" (or "in the attributes value"). Because
  of information theory, that's not possible unless
  the attribute value is at least as long as the
  underlying value. Otherwise, there will always be
  multiple underlying values that will map to the
  same attribute value. I suggest that you change
  the words I just quoted to "MUST be highly likely
  to cause a change in the attribute value". In fact,
  I'd suggest that you go further and require a
  cryptographic hash to be used for this value.
  Otherwise, implementers may choose a simpler
  algorithm like CRC32 or even XOR that doesn't
  provide preimage resistance, which you need.

* For HCD_Configuration_State, you are trying to
  quickly detect any variance from a standardized
  configuration. If it might be possible for an
  administrator to change which configuration
  settings are used to calculate this value, you
  should probably say "A change to any configuration
  setting that is included in the creation of this
  attribute or change to the set of configuration
  settings that are included MUST be highly likely
  to cause a change in the attribute value". That
  should ensure that a malicious administrator
  can't just remove a setting from the configuration
  and then change that setting without detection.

* For HCD_Downloadable_Application_Enabled,
  I would expect that a value of 0 would not
  only disable the ability to download applications
  but also the ability to run downloadable
  applications that have previously been downloaded.
  Why? Because I think the goal is to lock down
  the HCD to only built-in functions. Am I right?
  If so, this should be documented.

* I think that there might be several attributes
  of type HCD_Downloadable_Application_Name in a
  single assessment. Each one of these attributes
  might be followed by the Patches, String_Version,
  and/or Version for that application. Right? If so,
  these attributes seem to be grouped together by
  the fact that they come one after the other.

  I'm not sure that all network health assessment
  protocols support having multiple attributes with
  the same ID and that they preserve order. For the
  NEA specs, you should be OK if you place the
  attributes as PA-TNC attributes within a PA-TNC
  message. That PA-TNC message will be delivered
  to the Posture Validator, which will have its
  own code to parse the message. That code can
  accommodate multiple attributes with the same ID
  and ensure that the order of the attributes within
  the PA-TNC message is properly interpreted.

  Similarly, you should be fine for the TNC specs
  as long as you place all the attributes that
  pertain to one downloadable application within
  one IF-M message. You can even place all of the
  HCD-related attributes within one IF-M message.

  With Microsoft NAP, I think you're going to run
  into message size limitations very quickly. There
  is a 4KB maximum message size for NAP. All of the
  attributes that the NAP agent sends to the NAP server
  must fit within 4KB! So I don't think that you'll
  want to send over a long list of application names
  and patches.

  I don't know much about Cisco NAC's message format.
  You should ask someone who's more familiar with that
  whether there are limitations that might affect you.

* How will the HCD_Forwarding_Enabled attribute be
  handled in a NEA or TNC environment since PA-TNC
  now includes a Forwarding Enabled attribute that
  has a similar definition to HCD_Forwarding_Enabled
  but not quite the same. HCD_Forwarding_Enabled is
  only non-zero if the network interface that's
  requesting access is forwarding. PA-TNC's Forwarding
  Enabled attribute is on any time that forwarding
  is happening on any interface.

* I assume that HCD_Default_Password_Enabled will
  be handled in a NEA or TNC environment by using
  the Default Password Enabled attribute defined
  in PA-TNC. Right? There's no need to have an
  HCD-specific version of this attribute in that
  environment since there's already a standard
  PA-TNC attribute defined for this purpose.

* In section 5.2.1, the second sentence should have
  these additional words at the end: "if this feature
  is enabled". If an HCD supports dynamically downloadable
  applications but this feature has been disabled through
  administrative interfaces, the
  HCD_Downloadable_Application_Enabled attribute should
  not be set!

*Not Substantive*

* Several references are missing from the references
  section but cited in the spec: [rfc2119] and [RFC2277].

* In the definition of Device administrator, "other that"
  should be "other than".

* The use case in section 3.2.1 doesn't really say how
  the hard copy device attributes will be used. I suggest
  adding a sentence at the end of the second paragraph
  saying "Having HCDs report attributes will remove the
  need for most exceptions and therefore decrease the
  chance of unprotected laptops spreading malware."

* The first item in the list at the end of section 3.2.2
  should read "The specific level of firmware that is
  loaded into the HCD." Include "that is" for consistency
  with the other items in the list.

* I puzzled over the last sentence in the first paragraph
  of section 3.2.3 for a while, trying to figure out which
  example you were referring to. Instead of "the first
  example", I think you mean "the following example"
  (the one in the second paragraph of section 3.2.3).
  Is that right? If so, please fix the text. If not,
  please make the text clearer.

  In that same sentence, I suggest that you insert the
  words "it may be seen that" before "configuration
  settings". Those words seem to be implied but it is
  easier for the reader if they are actually present.
  Also, there is no period at the end of the sentence.

* In the second item in the list of section 3.2.3,
  "x509" should be "X.509" and "Certificate Authority"
  should be "Certification Authority".

* The last sentence in section 3.2.3 is missing a
  period at the end.

* Toward the end of the Implementer Note under
  HCD_Configuration_State, you say that PWG provides
  "notification of a change". Notification seems
  to imply that any change would trigger a
  notification of some party. Many NAC systems
  don't provide client-triggered notification
  of configuration changes. Therefore, I'd say
  that "detection" would be a better word than
  "notification" in this context.

  I suggest rewording the following sentence to
  change "Any access control restrictions that
  change in this attribute may trigger" to "Any
  access control restrictions that may be
  triggered by a change in this attribute".
  Otherwise, it's easy to misread the sentence.

* In the description of HCD_Forwarding_Enabled,
  there's an extra comma before USB.

* In the description of HCD_Resident_Application_Patches,
  an "i" is missing from HCD_Resident_Application_Version.

* In section 5.2.2, "HCDs" should be "HCD's".

More information about the ids mailing list