attachment-0001
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3527" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=234082116-11052009><FONT face=Arial
size=2>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!</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=234082116-11052009><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=234082116-11052009><FONT face=Arial
size=2>Take care,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=234082116-11052009><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=234082116-11052009><FONT face=Arial
size=2>Steve</FONT></SPAN></DIV><BR>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Dave Whitehead
[mailto:david@lexmark.com] <BR><B>Sent:</B> Monday, May 11, 2009 12:15
PM<BR><B>To:</B> Stephen Hanna<BR><B>Cc:</B> ids@pwg.org<BR><B>Subject:</B>
Re: IDS> Disposition of Comments on PWG HCD Health
Attrs<BR></FONT><BR></DIV>
<DIV></DIV><BR><FONT face=sans-serif size=2>Steve,</FONT> <BR><BR><FONT
face=sans-serif size=2>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
face=sans-serif size=2>Thank you again for your feedback.</FONT> <BR><BR><FONT
face=sans-serif size=2>dhw</FONT> <BR><BR><FONT face=sans-serif size=2>David
H. Whitehead<BR>Development Engineer<BR>Lexmark International,
Inc.<BR>859.825.4914<BR>davidatlexmarkdotcom</FONT> <BR><BR><BR>
<TABLE width="100%">
<TBODY>
<TR vAlign=top>
<TD width="40%"><FONT face=sans-serif size=1><B>Stephen Hanna
<shanna@juniper.net></B> </FONT><BR><FONT face=sans-serif
size=1>Sent by: owner-ids@pwg.org</FONT>
<P><FONT face=sans-serif size=1>04/14/09 02:35 PM</FONT> </P>
<TD width="59%">
<TABLE width="100%">
<TBODY>
<TR vAlign=top>
<TD>
<DIV align=right><FONT face=sans-serif size=1>To</FONT></DIV>
<TD><FONT face=sans-serif size=1>"ids@pwg.org"
<ids@pwg.org></FONT>
<TR vAlign=top>
<TD>
<DIV align=right><FONT face=sans-serif size=1>cc</FONT></DIV>
<TD>
<TR vAlign=top>
<TD>
<DIV align=right><FONT face=sans-serif size=1>Subject</FONT></DIV>
<TD><FONT face=sans-serif size=1>IDS> Comments on PWG HCD
Health Attrs</FONT></TD></TR></TBODY></TABLE><BR>
<TABLE>
<TBODY>
<TR vAlign=top>
<TD>
<TD></TD></TR></TBODY></TABLE><BR></TD></TR></TBODY></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></BLOCKQUOTE><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.
</BODY></HTML>