[Nea] Draft minutes from IETF73

["Susan Thomson (sethomso)" <[e-mail]>]

Draft minutes from IETF73 have been posted on the WG web site at
http://tools.ietf.org/wg/nea/. Also included below.

Please send corrections to me by Wed Dec 17.

Thanks
Susan


--------------------------------

These notes do not attempt to duplicate the content of the slides.
Instead, they summarize the material presented, and focus on
comments and discussion.

Agenda:
=======
Date: Wednesday, November 19, 2008
Time: 1300-1500 CST (GMT-0600)
WG Charter: http://www.ietf.org/html.charters/nea-charter.html
WG Tools: http://tools.ietf.org/wg/nea
WG email: [e-mail]

1300 Administrivia
         Blue Sheets
         Jabber & Minute scribes
         Agenda bashing
1305 WG Status
1310 Review changes to PA-TNC I-D
     http://www.ietf.org/internet-drafts/draft-ietf-nea-pa-tnc-02.txt
1320 Review changes to PB-TNC I-D
     http://www.ietf.org/internet-drafts/draft-ietf-nea-pb-tnc-02.txt
1330 Open Issues related to PA-TNC I-D
1400 Open Issues related to PB-TNC I-D
1430 IANA Considerations
1455 Review Milestones
1500 Adjourn

WG Status:
==========
Susan Thomson reviewed WG status since the last IETF. 

Updates to both PA-TNC I-D and PB-TNC I-D were published. 

Joel Snyder conducted a "due diligence" effort on posture attributes.
As discussed at IETF72, the intent is to ensure we have as complete a
set of standard attributes as possible prior to ratification of the
protocol I-Ds. Joel looked at a range of vendor products and identified
a list of attributes commonly supported. He sent the results of his
findings to the NEA mailing list on 11/14. No analysis was done with
respect to applicability to the protocol I-Ds. This is a topic for
discussion on the agenda today.


Changes to -02 version of PA-TNC I-D:
=====================================

Paul Sangster reviewed the changes in the latest version of the PA-TNC 
I-D.

The changes included:
- new approach to attribute correlation
- Added NEA client subtypes
- Included new PA-TNC attributes
- Minor editorial comments

The new approach to attribute correlation was discussed at IETF72. The
notion of a correlation ID has been removed, and the semantics
integrated into the Posture Collector ID.

New PA-TNC attributes include:
- Assessment Result
- Remediation instructions
- Forwarding Enabled
- Factory Default Password

The first two of these attributes were introduced at IETF 72. The other
attributes were added to the latest version of the PA-TNC I-D after
discussion on the mailing list.

Changes to -02 version of PB-TNC I-D:
=====================================
Steve Hanna reviewed the changes in the most recent version of the
PB-TNC I-D.

Changes included the following:
- State machine modified to add async retry
- Batch type field added to replace PB-Batch-Type message
- New message type for PB Assessment Result
- Update of examples

The modification to the state machine allows async retry for those
posture transport protocols that allow it.

PB-Batch-Type message type was removed as discussed at IETF72 and
replaced by a "batch type" field in the PB-TNC message header.

PB-Assessment-Result indicates overall compliance to NEA policy. The
states include compliant, minor non-compliance, major non-compliance,
error, and unable to determine.

Greg Lebowitz asked how to determine minor versus major compliance, and
whether there is a need for both.

Steve replied that this is a policy decision and is not defined in the
specification. It is not needed for interoperability. It is mainly used
for the benefit of the user, not the PBC itself.

PA-TNC Open Issues:
===================
Paul Sangster identified the following outstanding issues for PA-TNC:
- IANA Considerations 
- Impact of "due diligence" effort on posture attributes
- Ready for WG Last Call?

IANA considerations will be updated based on results of discussion
later in the meeting.

The main topic for discussion is the analysis of the results of the
"due diligence" effort on posture attributes as done by Joel Snyder and
reported to the mailing list on Nov 14.

To facilitate discussion, Paul categorized the attributes into 4
classes (which is not the same categorization as Joel has used):
- those that are already covered
- those that are not already covered
  - may have privacy issues
  - product-specific
  - other

The intent is to determine which of the attributes in the "not
covered" category should be included in the base PA-TNC spec. Some of
the attributes have been discussed in the past and were rejected,
e.g. because of privacy concerns or because the attributes did not fall
within the scope of NEA which is to ensure compliance with a particular 
security policy.

On Attributes in the "already covered" category:
------------------------------------------------
Paul explained that the current PA-TNC I-D supports all attributes in 
Joel's table that covers basic product information for a range of
components such as anti-virus, anti-spyware, firewall. This basic
information includes  attributes such as product name, version, whether
installed, and whether running.

Paul Hoffman questioned whether the granularity of the attribute type
definitions in the PA-TNC I-D maps precisely to the descriptions in
Joel's results. In particular, according to Joel's notes, the attribute 
"signature age" may be a range of types including date, whereas Paul's
analysis indicates that this attribute is taken care of by the string
version attribute type in the PA-ID.

Paul agreed that this was the one attribute where the granularity of
attribute types did not match in all cases.  In many products, the
version number can be used to determine how current the signature file
is. One vendor does expose the date of the signature file in such a way
that it can be used in a NEA compliance policy, but it was not clear
whether this information could also be derived from the version number.
This can be discussed further on the mailing list.

On Attributes in the "privacy" category:
----------------------------------------
Paul S. said that the attributes listed in this category were of a
generic nature that could be used to find out anything that was on a
particular machine, rather than asking specific questions that fall
within the scope of a NEA compliance policy. These attributes include
finding out information about what applications, directories, files,
processes, and software are installed or present on the machine.

Attributes in this category included the following:
Item 14b: Generic application - installed Install path, version, 
product settings?
Item 17: Directory exist
Item 18: File name exist
Item 19: File age
Item 20: File creation/modification date
Item 21: File size
Item 23: Hash of file contents
Item 29: Process, Service running
Item 41: Installed software list

Paul H. asked whether the attributes listed in this category are up for
discussion during the meeting, or whether they have already been thrown
out due to privacy concerns. For example, he pointed out that part of a
compliance policy may be to know whether a particular application is
installed, and that configuration details such as  the install path of
the application cannot be regarded as privacy-sensitive.

Paul S. responded that the attributes are up for discussion, and there
will be a time for open discussion later on in the meeting.


On Attributes in the product-specific category:
-----------------------------------------------
Paul explained that attributes in this category include those that are
specific to a particular vendor's product.

Item 15: Specific IE service pack or patch installed
Item 16: Google desktop search installed
Item 22: Windows file version #
Item 30: System needs to be rebooted
Item 35: Windows domain
Item 37: Registry key exist
Item 38: Registry key value
Item 39: Registry key have any value

Paul H. thought that the NEA WG should be concerned about standardizing 
attributes that the vendors of NEA solutions think is useful, rather 
than whether the attribute itself is specific to a certain vendor 
application. He is specifically referring to Item 15 (Internet 
Explorer).

Paul S. says he thinks this could go either way. If the vendor is not 
in the NEA solution space, then the NEA WG will need to standardize the 
attribute. On the other hand, if the vendor of the application in 
question is a NEA solution vendor and publishes these attributes in the
vendor-specific namespace, then these definitions may be adopted. 

Paul H. said that this may not be satisfactory. In some case, it would 
be better for the NEA WG to define the attributes. For instance, a 
particular vendor may not subdivide the version number of an 
application to the desired granularity.

Paul S. explained that item 30 (System need to reboot) is where a patch 
to an OS requires the system to reboot to take effect. Microsoft 
supports this.

Paul Hoffman said OSX does as well. He said that this should not be 
categorized only as an operating system attribute, since there are many 
application patches that require system reboot, e.g. firefox.

Gregory Lebowitz proposed that a new "generic application" component 
type be defined as a component which would allow interrogation of 
information about a particular application. This could support item 30 
(system need to reboot) more generically.

Stefan Winter asserts that registry keys should be categorized as a 
privacy concern given the storage of private information in the 
registry. Paul agrees and states that some of the attributes fall into 
multiple categories.

On "Other" attributes:
----------------------
These attributes include the rest of the attributes in Joel's list that 
were not included in the above categories.

They include:
Item 11: Anti-Virus engine version
Item 12: Anti-Virus signature file date
Item 31: Operating System language
Item 34: System FQDN
Item 40: System hardware information
Item 42: CPU speed
Item 43: Time zone

Paul S. asked whether the group had input on the rationale for item 40 
(system hardware information) e.g. Win, Mac, virtual. 

Paul Hoffman responded that some organizations do not want users to 
connect to the network using virtual machines. So the check could be to 
ask whether the hardware value = VMware.

Open Discussion:
----------------
After reviewing all the attributes, there was an open discussion 
regarding which attributes that are not already covered should be 
considered for standardization.

Tim Polk recognized Joel for putting in the effort since this must have 
been a lot of work. He clarified that the intent of the due diligence 
effort was as a double-check, and was not necessarily to expand the 
list of standard attributes. When he raised this originally, he wanted 
to make sure that we were not missing obvious attributes since the 
focus seemed to be mainly on protocol design rather than the attributes 
themselves. Those attributes that seem useful and do not raise issues, 
they can be added. But where there are concerns with specific 
attributes such as those that raise privacy issues, then the WG is 
probably better off not including them in the base protocol documents. 
Since the protocol is extensible, attributes can be added later. 

Paul H. said that he disagreed with Tim's position above. He said that 
there are attributes listed that are not currently covered, but are 
wanted, not only by NEA vendors, but also organizations using this 
technology. So while the effort so far has been good, he thinks there 
are half a dozen or so attributes in the "not covered" category that 
should be included. He would like to see more discussion on this.

Tim Polk said that he encourages the discussion and is fine with adding 
attributes where there is consensus. However, if support for certain 
attributes is controversial or requires more due diligence, then it may
be 
better to define these in supplemental documents so as not to hold 
up the protocol specifications.

Antti Makela asked whether the remediation attribute should, in 
addition to URI and displayable string, support more options such as 
command names or executable instructions.

Paul S. responded that this attribute had been defined in such a way to 
be extensible both by the IETF and in vendor-specific ways to support 
further options as needed. The question is, is the current definition 
sufficient for the base protocol specification?

Gregory  made a general comment that he agrees strongly with the 
current approach of supporting vendor-specific attributes. He said 
that, in RADIUS, support for vendor-specific attributes has been 
invaluable.

Steve H. indicated that there was time on the agenda to spend 5 mins on 
each of the "not covered" categories to see which attributes there is 
interest to add. Whatever the outcome in the meeting, the discussion  
needs to be taken to the mailing list.


Open Discussion - Privacy Attributes:
-------------------------------------
Paul Hoffman argued that Item 14b (Generic App) would be useful since 
most organizations will want to know that a particular application is 
not on the system. The use is as a negative question to check for a 
certain application that has known negative impacts. If this attribute 
is left to be defined as a vendor-specific attribute, then the NEA 
vendors will all likely need to come up with their own definitions, 
since it is not likely that the vendor of the unwanted application will 
define their own attribute for everyone else to use. Thus, it would be 
useful to have a general bucket which is targeted at asking this 
negative question.

Paul H. also thinks that Item 23 (Hash of file contents) would be useful

as a posture check to detect malware changes to applications.


Paul H. does not have strong opinions regarding other attributes listed 
in this category. He questions the validity of Item 29 (process/service 
running?) since it may not be possible to collect solid information on 
processes or services running. He thinks that Item 41 (Installed 
Software list) where the attibutes requests a whole list of software 
seems way out of bounds.

Paul S asked Paul H. for a clarification on Item 14b. 

Paul H. responded that he would like to see a general bucket defined 
for standard well-known things so that there is a common way to name,
and 
specify the version of, an application in the IANA registry, rather than

forcing the use of vendor-specific attributes. 

Paul S. asked why Item 23 was needed when already-defined security 
components could be used to detect malware issues. 

Paul H. responded that this may not necessarily be covered and that a 
posture compliance policy may want multiple ways to gather such 
information. He would rather err on the side of having standard 
attributes that may not be used, rather than forcing the use of 
vendor-specific attributes.

Dave Harrington pointed out that the data model for some of the 
attributes listed exists and is standardized in the Host Resources MIB. 
Should take a look at that MIB to ensure consistency.

Paul S. responded that NEA was not intended as a protocol for 
collecting inventory information.

Dave did not believe that the Host Resources MIB is an inventory thing. 
It does provide a list of installed software running. 

Tim Polk thinks it is a good suggestion to look at this MIB. We do not 
want to reinvent the wheel for information that already exists. 

Jeff Dion had a question about NEA covert channels such as on NTFS. The 
question needs further clarification and was taken offline.

Paul S. asked whether anyone in the room would like to come to the mic 
to support the attributes Paul H. suggested. Noone came forward.

Open Discussion - Product-specific:
-----------------------------------
Paul Hoffman argued for including Item 30 (System/program needs to be 
rebooted) since this is important to be in a secure state. 

Paul S says he does not have a problem with this one, and as Paul H. 
mentioned earlier, it is not only specific OS patches, but application 
patches as well. Additional thought needs to be put into the definition 
of this attribute.

Open Discussion - Other attributes:
-----------------------------------
Paul S. asked whether anyone would like to step forward to champion any 
of the 'other' attributes. No one did. 

The discussion on attributes is to be taken to the list.


PB-TNC Open Issues:
==================
Steve Hanna listed the open issues with the PB-TNC spec:
- Protocol state machine
- Assertion attributes


PB-TNC state machine:
---------------------

Steve discussed the history of asynchronous retries in state machine. 
- 01 version did not support async retries, even if the underlying 
posture transport supports it
- 02 version added support for async retries, but this version 
introduced synchronization problems

Steve described a proposal that addresses the synchronization problem. 
The proposal includes introducing two new states and a lockstep 
protocol to regain synchronization, after which time it is agreed that 
the client sends the next message. During the lockstep protocol, all 
messages are ignored except the lockstep message that leads to the next 
state.

Using this new state machine, Steve described the protocol flows under 
various scenarios: client initiates the retry, server initiates the 
retry, and client and server initiate the retry at the same time. 

Tim Polk asked about the need for a reset to cater for unreliable 
channels. 

Steve pointed out that the assumption is that the underlying posture 
transport is reliable.

Paul S. asks how the Posture Collectors are made aware that a retry has 
been negotiated and that a message they had sent may be dropped 
during the lockstep protocol.

Steve responded that this is outside the scope of NEA. There should be
an 
API between the Posture Collector and Posture Broker Client which 
supports an upcall allowing the PBC to tell the PC that posture 
validation is to be restarted. Similarly, on the NEA server.

Paul S. asks whether a Posture Validator would be made aware when a 
message from the Posture Collector is dropped during the lockstep 
protocol.

Steve said no. The Posture Validator would be told at some time during 
lockstep protocol is complete that validation is to be restarted.

Paul S. reiterated that this means that if the Posture Validator was 
waiting for a response from a Posture Collector, it must ask again.

Steve agreed.

Steve asked the working group to review the proposal and to let him 
know of improvements. 

Assertion Attributes:
---------------------
Steve described the current status of assertion attributes. An 
assertion attribute allows the client to assert the posture compliance 
result from a prior validation and thereby avoid the need to collect 
posture information all over again. Assertions are an optimization, and 
may be useful, for example, when roaming. 

The NEA requirements document [RFC5209] suggests the use of assertion 
attributes, but there are no normative requirements. 

Currently, there is no support for assertion attributes in the current 
version of the protocol documents. The plan has been to add such 
support and the protocol is extensible enough to allow assertion 
attributes to be added.

There are several possible ways to support assertion attributes, 
including opaque cookies, signed and timestamped data, posture 
certificates. 

However, this is a significant effort which will take time.

Steve proposed that we do not hold up the current protocol documents to 
include assertion attributes. Rather, support for assertion attributes 
can be specified in a separate document, possibly in parallel with the 
base protocol documents going through the IETF ratification process.

Paul H. said that he recalls significant controversy on this topic in a 
prior meeting. It may be a good idea to ask for individual submissions 
on ways to approach this issue. He said that the option to not do it at 
all should be left open. 

Tim says that this sounds like a good approach. He likes Paul H.'s to 
ask for individual submissions on this topic. 

Paul S. asks whether people can start working on individual submissions 
immediately or need to wait until WG rechartering. Paul also 
highlighted that IESG had many questions during RFC5209 on the 
usability of NEA in data constrained networks, and that support for 
assertion attributes was one way to address these concerns.

Steve expanded that one use case for assertion attributes is to perform 
posture validation using NEA over TLS, and allow assertion attributes 
to be presented as part of network access control, e.g. in EAP.

Tim P doesn't believe that lack of support for assertion attributes in 
the base protocol specifications will present problems. If it does, 
then the WG will know what it needs to do. Delaying the base protocol 
specifications will not make things go faster.

Steve conducted a hum poll on whether the group agrees with the 
proposal to decouple assertion attributes from the base protocol 
specification. 

The poll was unanimous in favor of this proposal. This question will be 
confirmed on the list.

IANA Considerations:
====================

Steve described the current status of IANA considerations for PA-TNC 
and PB-TNC specifications given the new IANA Considerations 
specification[RFC 5226]. 

IANA registries needed for PB-TNC are:   
-IETF Standard PB-TNC Message Types
-IETF Standard PA Subtypes
-IETF Standard PB-TNC Remediation Parameters Types
-IETF Standard PB-TNC Error Codes

IANA registries needed for PA-TNC are:   
-PA-TNC Attribute Types
-PA-TNC Error Codes
-PA-TNC Remediation Parameter Types

There are two questions for discussion:
1. What is the process for registering IANA values in the IETF 
namespace?
2. Should we allow IANA values in the IETF namespace to be registered? 
If so, how?

At IETF72, a WG poll indicated that there was unanimous consensus that 
IANA registrations in IETF space (PEN = 0) require public documentation.

At IETF 72, some also suggested allowing registration of name spaces in 
the vendor-specific space (PEN <> 0). The reasoning was  that if values 
have achieved widespread use, it is unlikely that implementations would 
move to a new value. IANA registration would support public 
documentation of widely used values.

There are 3 ways of registering IANA codepoints:
1. IETF consensus (current status)
   - RFC approved by IESG, either done in WG or AD-sponsored 
2. Require a RFC
   - Independent submission through RFC editor is ok
3. Require a public specification
   - Expert Review required 

Steve made the following proposal:
- Require Expert Review
- Specification must be publically available e.g. RFC, IANA archive
- Specification must be clear and ensure interoperability
- Same process for PEN = 0 and PEN <> 0

Paul H. agrees with Steve's proposal except that he thinks that the bar 
for registering in PEN = 0 must be higher than that for PEN <> 0. For 
example, codepoints in PEN = 0 must be useful and not harmful to the 
Internet. 

Tim Polk also thought that there should be a difference between PEN = 0 
and PEN <> 0. He thinks Paul's suggestion sounds reasonable. 

Steve said it also sounds reasonable to him.

With that change, Steve conducted a hum poll of whether WG is 
comfortable with the above proposal. There was no dissent. This 
proposal will be taken to the list.


Milestone Review:
=================
Susan reviewed the milestones. The deliverables remain the same, but 
the timelines have been updated to reflect the fact that we are running 
behind the original schedule by roughly 3-4 months (one IETF meeting). 


Meeting adjourned.

_______________________________________________
Nea mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/nea