From: Stephen Hanna (shanna@juniper.net)
Date: Tue Apr 14 2009 - 14:35:02 EDT
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.
Thanks,
Steve
--------
*Substantive*
* 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".
This archive was generated by hypermail 2.1.4 : Tue Apr 14 2009 - 14:40:50 EDT