Minutes from NEA WG Meeting IETF 75 in Stockholm, Sweden July 27, 2009, 5:40 PM - 7:40 PM Chaired by Steve Hanna and Susan Thomson Notes taken by Paul Hoffman and Stefan Winter 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 for IETF 75 NEA WG meeting ================================= Date: Monday, July 27, 2009 Time: 1740-1940 CEST (GMT+0200) WG Charter: http://www.ietf.org/html.charters/nea-charter.html WG Tools: http://tools.ietf.org/wg/nea WG email: nea@ietf.org 1740 Administrivia Blue Sheets Jabber & Minute scribes Agenda bashing 1745 WG Status 1750 Discuss PB-TNC (IETF LC and IESG comments) http://www.ietf.org/internet-drafts/draft-ietf-nea-pb-tnc-04.txt 1820 Discuss PA-TNC (IETF LC and IESG comments) http://www.ietf.org/internet-drafts/draft-ietf-nea-pa-tnc-04.txt 1850 Discuss proposed charter updates 1915 Process for soliciting proposals on Posture Transport protocol 1930 Review Milestones and Next Steps 1940 Adjourn The agenda was reviewed with no change. Minute takers volunteered. Susan Thomson reviewed WG status. Since IETF 74, we have published -04 drafts for PA-TNC and PB-TNC that reflect the WG consensus for response to comments received during WGLC. After this, we submitted the specifications to our AD, who forwarded them to IESG with a request to consider them for publication as Proposed Standards. An IETF LC was held from June 9 to June 23 and several comments were received, including a Gen-Art review and IANA comments. After this, the documents were scheduled for an IESG telechat but they have been deferred due to several COMMENTs and DISCUSSes received from IESG members. We will discuss the IESG comments today and agree on resolutions on the mailing list. More IESG comments are expected. Since we have completed all the milestones in our charter, we have drafted a charter revision that calls for us to begin work on PT, the Posture Transport protocol. This charter revision was sent to the NEA WG for review and support was received. We will discuss the proposed charter changes today. Steve Hanna gave a quick overview of the NEA reference model and showed an example of PA-TNC messages nested in PB-TNC messages inside PT. Steve reviewed the comments received on the -04 version of PB-TNC. First, he pointed out that the changes in that document were previously presented at IETF 74 and reviewed on the mailing list. During IETF LC, a comment was received complaining that the text in section 1.1 regarding the TCG is confusing and ambiguous, especially with respect to change control. The proposed resolution is to remove this section and add a note in the acknowledgements section thanking the TCG for submitting the first draft of this protocol. IETF has change control for PB-TNC but there's no need to point that out since that's always true for RFCs unless there's a note to the contrary. No comments were received on this proposal. The IANA also provided comments during IETF LC. First, they caught several mistakes: values that were included in the main part of the spec but left out of the IANA Considerations section. Those will be added to the IANA Considerations section. Second, they raised a concern with our instructions that said that when a vendor submits a request to register a vendor-specific value in one of our registries, the IANA should archive the vendor's spec describing that value and then make that spec publicly available if the vendor stops doing so. In their IETF LC comments, the IANA said they don't have a process for archiving specs. However, after further consultation they have decided that they do have a process for this. It's just very new so some IANA employees didn't know about it yet. So this is no longer a problem. Susan Thomson pointed out several issues with PB-TNC. First, she pointed out that the Retry-Acknowledge flag is no longer needed now that we have moved to our new, simpler state machine. The proposed resolution is to remove that flag, returning that bit to the Reserved field. No comments on that. Second, Susan pointed out that section 4.1 of PB-TNC said to send Version Not Supported errors in a PB-TNC message with version 1. That conflicts with section 4.9.2, which says to send those errors in a message with version 2. Section 4.9.2 is correct so section 4.1 will be fixed. Moving on to IESG comments, Alexey pointed out that we missed including a language tag to go with the Remediation-String field since that's a human readable string. BCP 18 (RFC 2277) says that we must provide a way to indicate the language for human readable strings so we will add a language tag to this string. Alexey also pointed out that the Version Not Supported error includes a range of versions (Min and Max) but this won't work if the range of versions supported includes one of the reserved values, like 0x09. The proposed solution is to just say that the reserved values listed in the PB-TNC spec are understood to be omitted from the range. Teddy Hogeborn asked whether it would be permitted to provide a range of 2-13 if 13 is a reserved value and what the meaning would be, if permitted. Steve said that the meaning should be 2-13 with the reserved values blocked out (i.e. 2-12 if 13 was the only reserved value). Teddy asked for this to be clear in the spec and Steve agreed. Teddy also asked whether these protocols duplicate most of SNMP. Steve said that there is some duplication but SNMP can't run before an IP address is assigned. The next IESG comment is that the PB-TNC spec doesn't reflect our earlier decision to allow a single Posture Collector to have multiple Posture Collector Identifiers (and similarly for Posture Validators). The proposed resolution is to fix this text in the PB-TNC spec. Another IESG comment was that the error handling in the PB-TNC spec is not as tightly specified as it should be. We had lots of SHOULDs that should really be MUSTs to maximize compatibility and minimize confusion. We must be careful not to create infinite loops where both sides loop sending errors because they don't understand each others' errors. Paul Hoffman asked for us to include a complete list of the changes that we make during this process. Steve agreed that the editors will send a complete list of changes to the NEA mailing list. Teddy pointed out that some fatal errors can't actually be reported, for example when the underlying transport fails. Steve agreed. We'll note that in the spec. Next, we moved on to comments on the PA-TNC spec. The first few comments were very similar to the first comments on the PB-TNC specification: a request to remove or clarify the TCG text in section 1.1, a few values missing from the IANA Considerations section, an IANA concern about archiving vendor specifications, and a request to have a language tag on the Remediation-String. These will be resolved in the same way discussed above. The first new comment is a suggestion that we should require a Posture Collector to respond to an Attribute Request (either with an error or with the requested attribute) instead of saying the Posture Collector SHOULD respond. This seems like a good idea since it will make it easier for a Posture Validator to determine whether the Posture Collector is present (even if it returns an error) vs. absent (in which case no response will be received). An IESG member suggested that we include a warning about the dangers of accepting and executing automated remediation instructions. The proposed resolution is to include such a warning in the Security Considerations section and probably also in the section that describes remediation instructions. The next IESG comment was a question about the status of the PA-TNC Security draft. Apparently, we didn't remove all references to this draft when we decided to drop it last year. This will be fixed by removing those references. Then there was another request to tighten up our error handling. Yes, we'll do that, as described under PB-TNC above. The next request was to use the Field Types defined in section 3.6 throughout the document. The editors have been discussing this. Some of us think that this is a good idea since we reuse these types several places in the spec and Posture Collector vendors might want to reuse those types in their vendor specific values. Others of us think that we don't actually reuse many types, other than unsigned integers which are easy to specify. Since we don't agree on this, the editors that favor reuse will try editing the spec to have reuse. Then we'll all review this revised specification to see if it's better. If so, we'll keep it. If not, we won't. Teddy asked that if we're going to define our own terms, we should choose names that make it clear when we're talking about our special kind of date or string type and when we're just referring to dates or strings in general. Steve agreed. Yoran Sheffer asked that when we remove section 1.1 and add an acknowledgement for TCG, it would be good to retain the text that explains the relationship between the TNC specifications and this document. Tim Polk (our Area Director) said that the IESG would rather not include this text since it raises too many issues. First, the IETF shouldn't be making statements about what the TCG is going to do in the future. Second, it's hard to predict what the relationship between IETF and TCG will be in the future. We hope that it will be good but we can't say for sure. It's better to just say that the specs came from TCG. That's a fact that will always be true. Paul Hoffman agreed that it's better to take out this text since it's very hard to predict the future. We might fork in the future. We hope not but we can't promise anything. Another issue pointed out by the IESG is that we should select Designated Experts. The best process for doing this is for the WG chairs to recommend nominees to the Area Director, who will pass those recommendations on to the IESG, who will decide and appoint the Designated Experts. Steve asked if there are any volunteers for this position. He described the duties also. Nobody spoke up. Steve and Susan will go find some volunteers. The last issue was some minor typos, clarifications, and inconsistencies that must be fixed. Those will be fixed in the next draft of the documents, which will be sent around for WG review. Susan presented the goal of the charter changes. Our current charter says that we should select a PT protocol defined by others. That's not quite right. We want to run our PT protocols over existing transports but some NEA-specific work will be needed. We must define how PB should be carried over those existing transports (like EAP or TLS or whatever). The goal of the proposed charter changes is to explain that and set out a process and timeline for the NEA WG to develop PT protocols, which will be thin layers over existing transport protocols. The gist of this proposed charter was discussed at IETF 74 and the actual text has been reviewed on the NEA mailing list. Susan reviewed the actual text in the proposed charter changes. A discussion ensued on the change from "one" mandatory to implement PT protocol to "at least one". The problem is that some customers want to do posture assessment before assigning an IP address to the NEA client (probably using an EAP-based transport) and some want to do posture assessment after an IP address has been assigned (probably using an IP-based transport). Some want to do both. If we select only one mandatory to implement PT protocol, one of these groups of customers will be disappointed. Tim said that we should leave the charter flexible so that we wait until we have some concrete protocols before we make our decision. Yaron said that leaving this charter text flexible might cause us to adopt two equivalent transport protocols. Steve and Tim both said that they will push hard to avoid having two transport protocols unless there is a very strong reason to do so, such as if there are two incompatible use cases. Paul suggested saying that we should require one PT protocol for layer 2 and one PT protocol for layer 3. Tim said that we may end up there but probably shouldn't put that in the charter. Susan reviewed the new milestones. The plan is to use a process to get PT protocols that is similar to the process that we used for PA and PB protocols. We'd solicit proposals that meet our requirements in September with submissions due in October. At IETF 76, we'd review the submissions and decide what to do for WG drafts. Then we'd aim for rapid development of the specifications, probably including a virtual interim meeting in January. If all goes well, we should be able to do a WG LC on the specifications in March, resolve the comments at IETF 77 in April, and submit the specs to the IESG in May 2010. Paul pointed out that the first milestone needs an "s" on the end ("protocols" not "protocol"). Tim said he thinks the draft charter is ready for IESG consideration. They may decide that it needs changes or that it needs an IETF LC. We'll see. We did a hum on whether the charter changes proposed by Susan are acceptable. The hum was unanimous that the charter changes are fine. We discussed the timing of when to have the IESG consider the charter and when to have them look at modified versions of PA-TNC and PB-TNC. After some discussion, it was agreed that we can not get PA-TNC and PB-TNC revisions through WGLC by August 13, especially since we still have not received comments from several IESG members. Therefore, we'll ask the IESG to send us their comments on PA-TNC and PB-TNC ASAP. We'll make changes to address their comments, post new versions of PA-TNC and PB-TNC, do WGLC, and then ask for them to be on the IESG telechat. We'll ask the IESG to consider our charter changes on August 13. Teddy asked about whether we could reuse data structures from MIBs, since there's lots of overlap. Steve said that there's not actually that much overlap. Teddy thinks there is some. And even if there aren't MIBs for this, maybe we should just define MIBs and use those in our protocol. Tim said that the OPS and Management ADs didn't seem to think this was a solved problem. Also, the Security Area doesn't have a good track record on defining MIBs. And we have a good set of protocols that should work well. Meeting adjourned