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: nea@ietf.org 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.