attachment-0001
<br><font size=2 face="sans-serif">Steve,</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">Thank you again for your feedback.</font>
<br>
<br><font size=2 face="sans-serif">dhw</font>
<br>
<br><font size=2 face="sans-serif">David H. Whitehead<br>
Development Engineer<br>
Lexmark International, Inc.<br>
859.825.4914<br>
davidatlexmarkdotcom</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Stephen Hanna <shanna@juniper.net></b>
</font>
<br><font size=1 face="sans-serif">Sent by: owner-ids@pwg.org</font>
<p><font size=1 face="sans-serif">04/14/09 02:35 PM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">"ids@pwg.org" <ids@pwg.org></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">IDS> Comments on PWG HCD Health Attrs</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br><tt><font size=2>Here are my comments on the February 18 draft of the<br>
PWG Hard Copy Device Health Assessment Attributes.<br>
I have divided them into substantive and not.<br>
I hope that this is useful. I joined your list<br>
for now so that I can participate if these<br>
comments spark discussion.<br>
</font></tt>
<br><tt><font size=2>Thanks,<br>
</font></tt>
<br><tt><font size=2>Steve<br>
</font></tt>
<br><tt><font size=2>--------<br>
</font></tt>
<br><tt><font size=2>*Substantive*<br>
</font></tt>
<br><tt><font size=2>* The descriptions of both HCD_Certification_State<br>
and HCD_Configuration_State say that a change in<br>
the underlying value "MUST cause a change in the<br>
attribute" (or "in the attributes value"). Because<br>
of information theory, that's not possible unless<br>
the attribute value is at least as long as the<br>
underlying value. Otherwise, there will always be<br>
multiple underlying values that will map to the<br>
same attribute value. I suggest that you change<br>
the words I just quoted to "MUST be highly likely<br>
to cause a change in the attribute value". In fact,<br>
I'd suggest that you go further and require a<br>
cryptographic hash to be used for this value.<br>
Otherwise, implementers may choose a simpler<br>
algorithm like CRC32 or even XOR that doesn't<br>
provide preimage resistance, which you need.</font></tt>
<br>
<br><tt><font size=2><ids></font></tt>
<br><tt><font size=2>The group acknowledged that the comment is theoretically
correct. It was agreed that the editor will qualify </font></tt>
<br><tt><font size=2>the text with the phrase “within the limits of information
theory” to “A change to any configuration </font></tt>
<br><tt><font size=2>setting that is required for the device to maintain
its certification status MUST cause a change in the </font></tt>
<br><tt><font size=2>attribute within the limits of information theory.”
</font></tt>
<br><tt><font size=2></ids></font></tt>
<br>
<br><tt><font size=2>* For HCD_Configuration_State, you are trying to<br>
quickly detect any variance from a standardized<br>
configuration. If it might be possible for an<br>
administrator to change which configuration<br>
settings are used to calculate this value, you<br>
should probably say "A change to any configuration<br>
setting that is included in the creation of this<br>
attribute or change to the set of configuration<br>
settings that are included MUST be highly likely<br>
to cause a change in the attribute value". That<br>
should ensure that a malicious administrator<br>
can't just remove a setting from the configuration<br>
and then change that setting without detection.</font></tt>
<br>
<br><tt><font size=2><ids></font></tt>
<br><tt><font size=2>The group agreed to change “must be highly likely”
to “must (within the limits of information theory.)” </font></tt>
<br><tt><font size=2></ids></font></tt>
<br>
<br><tt><font size=2>* For HCD_Downloadable_Application_Enabled,<br>
I would expect that a value of 0 would not<br>
only disable the ability to download applications<br>
but also the ability to run downloadable<br>
applications that have previously been downloaded.<br>
Why? Because I think the goal is to lock down<br>
the HCD to only built-in functions. Am I right?<br>
If so, this should be documented.</font></tt>
<br>
<br><tt><font size=2><ids></font></tt>
<br><tt><font size=2>It was felt that Steve’s comment was not based on
a correct interpretation of the attribute. However, the </font></tt>
<br><tt><font size=2>group agreed that the name of the attribute is somewhat
ambiguous. The name should be changed to </font></tt>
<br><tt><font size=2>Application Download Enabled. And a note should be
added to clarify that it is not intended to disable </font></tt>
<br><tt><font size=2>previously downloaded or resident (persistent) applications.
</font></tt>
<br><tt><font size=2> </font></tt>
<br><tt><font size=2>A bit more discussion generated more confusion and
disagreement, because of the current definitions of </font></tt>
<br><tt><font size=2>downloadable applications vs. resident application
vs. persistent applications vs. user downloadable vs. </font></tt>
<br><tt><font size=2>administrator downloadable applications. There seems
to be some overlap in the definitions—which </font></tt>
<br><tt><font size=2>creates difficulties in interpretation. </font></tt>
<br><tt><font size=2> </font></tt>
<br><tt><font size=2>We will re-visit the term definitions to [hopefully]
clarify the differences of downloadable </font></tt>
<br><tt><font size=2>applications. </font></tt>
<br><tt><font size=2> </font></tt>
<br><tt><font size=2>To help the clarification difficulty, one person asked
“What is a user-downloadable application?” PDL </font></tt>
<br><tt><font size=2>interpreters were given as examples. </font></tt>
<br><tt><font size=2> </font></tt>
<br><tt><font size=2>It was suggested that from a health assessment standpoint,
there is no practical difference </font></tt>
<br><tt><font size=2>between persistent and non-persistent downloadable
applications. However, not everyone agreed. </font></tt>
<br><tt><font size=2> </font></tt>
<br><tt><font size=2>The group agreed that “downloadable application”
should be re-defined to “user application”. Another </font></tt>
<br><tt><font size=2>attribute should be added to determine whether downloadable
applications can be persistent (across </font></tt>
<br><tt><font size=2>jobs) vs. temporary. </font></tt>
<br><tt><font size=2> </font></tt>
<br><tt><font size=2>It was later suggested that the document should identify
some recommended default values for these </font></tt>
<br><tt><font size=2>attributes. </font></tt>
<br><tt><font size=2></ids></font></tt>
<br>
<br><tt><font size=2>* I think that there might be several attributes<br>
of type HCD_Downloadable_Application_Name in a<br>
single assessment. Each one of these attributes<br>
might be followed by the Patches, String_Version,<br>
and/or Version for that application. Right? If so,<br>
these attributes seem to be grouped together by<br>
the fact that they come one after the other.</font></tt>
<br>
<br><tt><font size=2>I'm not sure that all network health assessment<br>
protocols support having multiple attributes with<br>
the same ID and that they preserve order. For the<br>
NEA specs, you should be OK if you place the<br>
attributes as PA-TNC attributes within a PA-TNC<br>
message. That PA-TNC message will be delivered<br>
to the Posture Validator, which will have its<br>
own code to parse the message. That code can<br>
accommodate multiple attributes with the same ID<br>
and ensure that the order of the attributes within<br>
the PA-TNC message is properly interpreted.</font></tt>
<br>
<br><tt><font size=2>Similarly, you should be fine for the TNC specs<br>
as long as you place all the attributes that<br>
pertain to one downloadable application within<br>
one IF-M message. You can even place all of the<br>
HCD-related attributes within one IF-M message.</font></tt>
<br>
<br><tt><font size=2>With Microsoft NAP, I think you're going to run<br>
into message size limitations very quickly. There<br>
is a 4KB maximum message size for NAP. All of the<br>
attributes that the NAP agent sends to the NAP server<br>
must fit within 4KB! So I don't think that you'll<br>
want to send over a long list of application names<br>
and patches.</font></tt>
<br>
<br><tt><font size=2>I don't know much about Cisco NAC's message format.<br>
You should ask someone who's more familiar with that<br>
whether there are limitations that might affect you.</font></tt>
<br>
<br><tt><font size=2><ids></font></tt>
<br><tt><font size=2>The group agreed that when the Binding documents to
NEA, NAP and NAC are addressed, it will be </font></tt>
<br><tt><font size=2>necessary to include some type of correlation ID—or
equivalent capability. </font></tt>
<br><tt><font size=2></ids></font></tt>
<br>
<br><tt><font size=2>* How will the HCD_Forwarding_Enabled attribute be<br>
handled in a NEA or TNC environment since PA-TNC<br>
now includes a Forwarding Enabled attribute that<br>
has a similar definition to HCD_Forwarding_Enabled<br>
but not quite the same. HCD_Forwarding_Enabled is<br>
only non-zero if the network interface that's<br>
requesting access is forwarding. PA-TNC's Forwarding<br>
Enabled attribute is on any time that forwarding<br>
is happening on any interface.</font></tt>
<br>
<br><tt><font size=2><ids></font></tt>
<br><tt><font size=2>Yes, they are similar—but not identical. </font></tt>
<br><tt><font size=2> </font></tt>
<br><tt><font size=2>The group agreed that the IDS document will be modified
to handle this attribute in the same way as the </font></tt>
<br><tt><font size=2>NEA method. However, Dave said that he would like
to limit this topic to external facing (i.e., outside </font></tt>
<br><tt><font size=2>of the device) network interfaces. Steve agreed. Bluetooth,
WiFi, and “nets and rings” should all be </font></tt>
<br><tt><font size=2>included in the definition of external facing network
interfaces. </font></tt>
<br><tt><font size=2></ids></font></tt>
<br>
<br><tt><font size=2>* I assume that HCD_Default_Password_Enabled will<br>
be handled in a NEA or TNC environment by using<br>
the Default Password Enabled attribute defined<br>
in PA-TNC. Right? There's no need to have an<br>
HCD-specific version of this attribute in that<br>
environment since there's already a standard<br>
PA-TNC attribute defined for this purpose.</font></tt>
<br>
<br><tt><font size=2><ids></font></tt>
<br><tt><font size=2>It was determined that the description of the HCD_Default_Password_Enabled
attribute should be </font></tt>
<br><tt><font size=2>changed to: </font></tt>
<br><tt><font size=2>“The HCD_Default_Password_Enabled attribute is a
single bit-field that indicates that one or </font></tt>
<br><tt><font size=2>more of the devices’ administrator passwords or other
credentials are set to the factory defaults. </font></tt>
<br><tt><font size=2>(0 = no default passwords)” </font></tt>
<br><tt><font size=2></ids></font></tt>
<br>
<br><tt><font size=2>* In section 5.2.1, the second sentence should have<br>
these additional words at the end: "if this feature<br>
is enabled". If an HCD supports dynamically downloadable<br>
applications but this feature has been disabled through<br>
administrative interfaces, the<br>
HCD_Downloadable_Application_Enabled attribute should<br>
not be set!</font></tt>
<br>
<br><tt><font size=2><ids></font></tt>
<br><tt><font size=2>Agreed. The Note in Section 5.2.1 will be removed.
</font></tt>
<br><tt><font size=2></ids></font></tt>
<br>
<br><tt><font size=2>*Not Substantive*<br>
</font></tt>
<br><tt><font size=2><ids></font></tt>
<br><tt><font size=2>The group agreed to accept all the editorial comments.</font></tt>
<br><tt><font size=2></ids></font></tt>
<br>
<br><tt><font size=2>* Several references are missing from the references<br>
section but cited in the spec: [rfc2119] and [RFC2277].</font></tt>
<br>
<br><tt><font size=2>* In the definition of Device administrator, "other
that"<br>
should be "other than".</font></tt>
<br>
<br><tt><font size=2>* The use case in section 3.2.1 doesn't really say
how<br>
the hard copy device attributes will be used. I suggest<br>
adding a sentence at the end of the second paragraph<br>
saying "Having HCDs report attributes will remove the<br>
need for most exceptions and therefore decrease the<br>
chance of unprotected laptops spreading malware."</font></tt>
<br>
<br><tt><font size=2>* The first item in the list at the end of section
3.2.2<br>
should read "The specific level of firmware that is<br>
loaded into the HCD." Include "that is" for consistency<br>
with the other items in the list.</font></tt>
<br>
<br><tt><font size=2>* I puzzled over the last sentence in the first paragraph<br>
of section 3.2.3 for a while, trying to figure out which<br>
example you were referring to. Instead of "the first<br>
example", I think you mean "the following example"<br>
(the one in the second paragraph of section 3.2.3).<br>
Is that right? If so, please fix the text. If not,<br>
please make the text clearer.</font></tt>
<br>
<br><tt><font size=2>In that same sentence, I suggest that you insert the<br>
words "it may be seen that" before "configuration<br>
settings". Those words seem to be implied but it is<br>
easier for the reader if they are actually present.<br>
Also, there is no period at the end of the sentence.</font></tt>
<br>
<br><tt><font size=2>* In the second item in the list of section 3.2.3,<br>
"x509" should be "X.509" and "Certificate Authority"<br>
should be "Certification Authority".</font></tt>
<br>
<br><tt><font size=2>* The last sentence in section 3.2.3 is missing a<br>
period at the end.</font></tt>
<br>
<br><tt><font size=2>* Toward the end of the Implementer Note under<br>
HCD_Configuration_State, you say that PWG provides<br>
"notification of a change". Notification seems<br>
to imply that any change would trigger a<br>
notification of some party. Many NAC systems<br>
don't provide client-triggered notification<br>
of configuration changes. Therefore, I'd say<br>
that "detection" would be a better word than<br>
"notification" in this context.</font></tt>
<br>
<br><tt><font size=2>I suggest rewording the following sentence to<br>
change "Any access control restrictions that<br>
change in this attribute may trigger" to "Any<br>
access control restrictions that may be<br>
triggered by a change in this attribute".<br>
Otherwise, it's easy to misread the sentence.</font></tt>
<br>
<br><tt><font size=2>* In the description of HCD_Forwarding_Enabled,<br>
there's an extra comma before USB.</font></tt>
<br>
<br><tt><font size=2>* In the description of HCD_Resident_Application_Patches,<br>
an "i" is missing from HCD_Resident_Application_Version.</font></tt>
<br>
<br><tt><font size=2>* In section 5.2.2, "HCDs" should be "HCD's".</font></tt>
<br>
<br />--
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.