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: Monday, March 23, 2009 Time: 1300-1500 PDT (GMT-0700) 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 Discuss PA-TNC (recent changes and WGLC comments) http://www.ietf.org/internet-drafts/draft-ietf-nea-pb-tnc-03.txt 1350 Discuss PB-TNC (recent changes and WGLC comments) http://www.ietf.org/internet-drafts/draft-ietf-nea-pa-tnc-03.txt 1430 Open Mic 1450 Review Milestones and Next Steps 1500 Adjourn WG Status ========= The PA-TNC and PB-TNC were updated based on changes discussed at the last IETF. Working Group Last Call for comments on the documents ended prior to the IETF with one comment. Changes to -03 version of PA-TNC I-D: ===================================== Kaushik Narayan reviewed the changes made to the -03 version of PA-TNC. There were the following changes: 1. IANA Considerations no longer require a RFC. Expert Review with Specification is required. The specification must be permanently and publicly available and likely to ensure interoperability. IETF standard values must be useful and not harmful to the Internet. 2. The section on evaluating the PA-TNC protocol against NEA requirements per RFC 5209 has been moved to the Appendix 3. Pre-RFC 5378 text has been added to the first page WGLC Comments on -03 version of PA-TNC I-D: =========================================== WGLC Comments included the following proposed changes: 1. SHOULD to MUST: A message recipient MUST use the same version number in a response if the version is supported. If the version is not supported, a message recipient MUST respond to the message with a Version Not Supported error message using version 1. 2. Version Discovery: The -03 version of the I-D specifies that a sender can use a special-purpose message with version 0 for version discovery. This is in addition to the ability to send a message, and, if the version is not supported, receive a Version Not Supported error message containing the min-max range of versions supported by the recipient. In the interests of simplicity and to avoid redundancy, the proposal is to remove the version 0 mechanism since it is not deemed necessary to have two ways of performing version discovery. Steve pointed out that the motivation for having the two mechanisms in the first place was to provide a means of performing version discovery without triggering an error. Kaushik asked for those in favor of retaining Version 0 discovery to comment. Nobody did. 3. The WGLC comments also proposed some minor wording changes. All of the above proposed changes to be confirmed on the mailing list. Changes to -03 version of PB-TNC I-D: ===================================== Steve Hanna reviewed changes to the PB-TNC specification. The changes included the following: 1. IANA Considerations were changed in the same way as for PA-TNC described above. 2. The section on evaluating the PB-TNC protocol against NEA requirements has been moved to an Appendix 3. Pre-RFC 5378 text has been added to the first page 4. State machine change has been simplified Steve reviewed the history of changes to the state machine. The -01 version of the state machine allowed the client and server to re-try in the middle of an assessment, but only the client could trigger a posture assessment after an assessment had completed. The -02 version of the state machine made changes to allow the server to trigger an assessment after the completion of an assessment, but it led to synchronization errors when both the client and server trigger a re-assessment at the same time. The -03 version of the state machine addresses the issues with the -02 version. However, this version only supports triggering re-assessment after an assessment has finished. WGLC Comments on -03 version of PB-TNC I-D: =========================================== WGLC Comments included the following proposed changes: 1. Make PB-TNC version handling the same as PA-TNC: Unlike PA-TNC, the -03 version of the specification has no support for version discovery. The proposal is for PB-TNC to adopt the proposal described above for PA-TNC. However, there will be some differences in the version numbers that can be used. Some version numbers will be reserved to accommodate prior usage. 2. PB-Assessment-Result and PB-Access-Recommendation MUST NOT appear in a batch of type other than Result (was SHOULD NOT) 3. PB-Access-Recommendation MAY appear in a batch of type Result (was SHOULD) Steve asked whether these proposals seemed reasonable. There were no objections. Susan asked for confirmation that an implication of the version handling above is that the version number field in PB-TNC would be modified to be the same size as that used in PA-TNC. Steve confirmed that the current size of 4 bits would be expanded to 8 bits to be the same as PA-TNC. Milestones ========== The above proposals will be confirmed on the mailing list and -04 versions of the protocol specs published in late March or early April. After that the specifications will be submitted for IETF Last Call. Once the specifications have passed IETF Last Call and IESG consideration, the milestones in the charter are complete. Next Steps ========== To kick off the discussion, Steve described the 3-layer NEA framework for the benefit of those in the meeting who were not familiar with it. The PA protocol reports information about the environment of a NEA client (OS version, AV status etc) to the NEA server. The PB protocol encapsulates this information in batches between client and server. The PT protocol encapsulates the PB protocol for transport across the network. The PA and PB protocols have been the subject of the working group charter to date. The WG needs to consult with the ADs regarding PT since the charter text and milestones need to be updated. Tim Polk said that once the PA-TNC and PB-TNC specifications are done, re-chartering is likely to occur. The WG needs to define new text and milestones to accomplish this work. It is reasonable to expect that this work can proceed before the PA-TNC and PB-TNC I-Ds are fully approved by the IETF and IESG. Stephen Farrell asked whether this can be accomplished prior to the next meeting. Tim Polk said yes, this was possible. The charter needs to be approved by the IESG. The precise timing depends on the IESG meeting schedule, but it should be doable within a month. It is not unreasonable to expect that this can be done prior to the Stockholm meeting. Susan asked whether the charter updates would be submitted to the IESG if the IETF Last Call did not go smoothly. Tim replied that he does not expect there to be problems during the IETF Last Call, but if there are, the charter updates will not be submitted to the IESG until the IETF Last Call comments are resolved. Steve asked whether the revised charter would be considered if the IETF Last Call went smoothly, but the IESG had comments. Tim said that he would be prepared to consider re-chartering in this case, but it would depend on what the IESG comments were. He does not want the WG to lose momentum between now and the Stockholm meeting. The intent is for the charter revisions to trail closely behind the RFC approval process. Jerry Thrasher referred to a sentence in the charter that indicates that PT is a deliverable. There is wording in the current charter that says that the WG will identify and specify the use of one mandatory to implement PT protocol that is fully documented in an RFC. Steve explained that the intent of this wording was to say that the WG was not in the business of specifying a new transport protocol, and that the WG would identify one that already exists. Kaushik pointed out that it is likely there will be multiple PTs needed, e.g. one pre-access control, and one post-access control. Many existing implementations implement multiple protocols already. The charter currently specifies one mandatory to implement posture transport protocol. Would it be acceptable to have multiple? Tim answered that it is better to have a minimal set of mandatory to implement protocols. It makes sense for there to be one, unless there are strong reasons to the contrary. Kaushik said that different PTs are optimal in different circumstances. He asked whether it would be acceptable for the WG to specify more than one PT, even if only one was mandatory to implement. Tim said yes, he would be comfortable with that. Yaron Sheffer asked whether the TNC documents would be updated to match that of the IETF documents. Steve said that the TNC documents are in public review status, which mean they are in draft form. The goal is to make them semantically equivalent to that of the IETF, even though the text of the specifications may be different. There was a question whether IF-MAP as defined in the TNC would be part of the revised charter. Steve responded that this is not currently within the scope of the charter and will probably not be part of the updated charter at this time. Kaushik asked whether the charter would be opened up for other items such as a protocol between the Posture Broker Server and Posture Validation Server. Tim answered that there is nothing to preclude other work items from being considered during the re-chartering process, but he is not inclined to support opening up the kitchen sink at this point in time unless there is strong WG consensus to do so. Rather, the working group should focus on defining a PT. Kaushik asked whether it would cause problems to re-charter again to include new work items, if the WG found that this was necessary in the near future. Tim said he would be open to re-chartering again, adding that WGs should probably re-charter more often than they do. It does not have to be done serially as has been the case so far. Kaushik said that assertion attributes and data acquisition mechanisms are two examples of work items that have been discussed in the WG, but have been deferred to date. Tim said we should not get ahead of ourselves until there is WG consensus to do so. Kaushik asked whether there is a problem with the fact that the protocol name contains the name of a non-IETF organization, and whether there is precedent for this. Tim did not believe this was a problem, but should verify it. Discussion is to be continued on the mailing list. Meeting adjourned.