Thanks, Dave. I have reviewed the resolutions in your email. They all seem sensible to me. I'm glad that I helped spark an interesting and useful discussion on this topic. And I'm glad that the PWG has taken such a proactive approach to health assessment. Good work!
Take care,
Steve
________________________________
From: Dave Whitehead [mailto:david at lexmark.com]
Sent: Monday, May 11, 2009 12:15 PM
To: Stephen Hanna
Cc: ids at pwg.org
Subject: Re: IDS> Disposition of Comments on PWG HCD Health Attrs
Steve,
Thank you very much for your insightful comments regarding the IDS Attribute specification. They provided for a lively and informative discussion during the F2F meeting. I have included the disposition for each within your comments.
Thank you again for your feedback.
dhw
David H. Whitehead
Development Engineer
Lexmark International, Inc.
859.825.4914
davidatlexmarkdotcom
Stephen Hanna <shanna at juniper.net>
Sent by: owner-ids at pwg.org
04/14/09 02:35 PM
To
"ids at pwg.org" <ids at pwg.org>
cc
Subject
IDS> Comments on PWG HCD Health Attrs
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.
<ids>
The group acknowledged that the comment is theoretically correct. It was agreed that the editor will qualify
the text with the phrase "within the limits of information theory" to "A change to any configuration
setting that is required for the device to maintain its certification status MUST cause a change in the
attribute within the limits of information theory."
</ids>
* 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.
<ids>
The group agreed to change "must be highly likely" to "must (within the limits of information theory.)"
</ids>
* 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.
<ids>
It was felt that Steve's comment was not based on a correct interpretation of the attribute. However, the
group agreed that the name of the attribute is somewhat ambiguous. The name should be changed to
Application Download Enabled. And a note should be added to clarify that it is not intended to disable
previously downloaded or resident (persistent) applications.
A bit more discussion generated more confusion and disagreement, because of the current definitions of
downloadable applications vs. resident application vs. persistent applications vs. user downloadable vs.
administrator downloadable applications. There seems to be some overlap in the definitions-which
creates difficulties in interpretation.
We will re-visit the term definitions to [hopefully] clarify the differences of downloadable
applications.
To help the clarification difficulty, one person asked "What is a user-downloadable application?" PDL
interpreters were given as examples.
It was suggested that from a health assessment standpoint, there is no practical difference
between persistent and non-persistent downloadable applications. However, not everyone agreed.
The group agreed that "downloadable application" should be re-defined to "user application". Another
attribute should be added to determine whether downloadable applications can be persistent (across
jobs) vs. temporary.
It was later suggested that the document should identify some recommended default values for these
attributes.
</ids>
* 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.
<ids>
The group agreed that when the Binding documents to NEA, NAP and NAC are addressed, it will be
necessary to include some type of correlation ID-or equivalent capability.
</ids>
* 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.
<ids>
Yes, they are similar-but not identical.
The group agreed that the IDS document will be modified to handle this attribute in the same way as the
NEA method. However, Dave said that he would like to limit this topic to external facing (i.e., outside
of the device) network interfaces. Steve agreed. Bluetooth, WiFi, and "nets and rings" should all be
included in the definition of external facing network interfaces.
</ids>
* 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.
<ids>
It was determined that the description of the HCD_Default_Password_Enabled attribute should be
changed to:
"The HCD_Default_Password_Enabled attribute is a single bit-field that indicates that one or
more of the devices' administrator passwords or other credentials are set to the factory defaults.
(0 = no default passwords)"
</ids>
* 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!
<ids>
Agreed. The Note in Section 5.2.1 will be removed.
</ids>
*Not Substantive*
<ids>
The group agreed to accept all the editorial comments.
</ids>
* 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 message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ids/attachments/20090515/87cab92e/attachment-0001.html>