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: Tuesday, March 11, 2008 Time: 0900-1130 EST (GMT-0500) WG Charter: http://www.ietf.org/html.charters/nea-charter.html WG Tools: http://tools.ietf.org/wg/nea WG email: nea@ietf.org 0900 Administrivia Blue Sheets Jabber & Minute scribes Agenda bashing 0905 WG Status 0910 Discuss IESG Requested Changes to NEA Requirements draft draft-ietf-nea-requirements-06.txt 0930 Review Proposals for NEA Protocols:PB-TNC, PA-TNC, PA-TNC Security draft-sahita-nea-pb-tnc-00.txt draft-sangster-nea-pa-tnc-00.txt draft-sangster-nea-pa-tnc-security-00.txt 1100 Consensus Check - Shall We Adopt These As WG Drafts? (To Be Confirmed On List) 1120 Review Milestones 1130 Adjourn WG Status: Susan Thomson reviewed WG status since the last IETF. --- Nea-requirements-05 submitted to IESG (12/6/2007) --- IETF Last Call issued (12/10/2007-12/24/2007) --- Call for PA and PB proposals (01/03/2008) --- IESG reviewed nea-requirements-05 (1/10/2008) --- IESG reviewed nea-requirements-06 (1/28/2008) --- PA and PB candidate submissions (2/18/2008) draft-sangster-nea-pa-tnc-00.txt draft-sahita-nea-pb-tnc-00.txt draft-sangster-nea-pa-tnc-security-00.txt Meeting Goals: Susan stated there were two main goals for the meeting: 1. Resolve remaining IESG issues with the NEA requirements draft 2. Determine WG consensus for adopting candidate proposals as WG drafts --- PB-TNC --- PA-TNC --- PA-TNC Security Consensus Check process: Susan reviewed the consensus check process. An initial consensus check would be taken at the end of the meeting after the candidate proposals have been reviewed, and then the same check would be done on the mailing list. For each of the proposed drafts, the following question would be asked: Do you support adoption as WG draft? Possible answers: 1. Yes 2. No 3. Defer 1) means that the draft is regarded as a good foundation for a WG -00 draft. The draft will be treated as any I-D -00 version where updates are made based on WG consensus. 2) means that the draft would not form a good basis for a WG draft. 3) means to defer a decision based on some further action taking place. NEA Requirements Status: Kaushik Narayan reviewed the changes that had been made to the NEA requirements draft based on IESG feedback. One concern has been that some PT choices would not be able to meet requirements for reliable bulk data transfer. A change has been made to Section 5.2.3. of -06 version of the requirements draft to acknowledge that one PT may not be able to meet all requirements and describes possible deployment considerations. Tim Polk said that he thought the IESG wanted to see a new requirement for PT. Steve Hanna said he thought this could be addressed through a wording change. Tim responded that if that addresses the IESG concern, then that would be ok. Steve said that, either way, this change would need to return to mailing list. Another IESG concern had been regarding MITM attacks on NEA endpoints, and attacks on components that trigger posture assessment. Clarifying text has been added to Section 8.1.3 to address these concerns. Other comments were mainly out of scope of NEA WG charter. GEN ART review comments have been addressed in -06 version. Alan Breese raised the issue of dealing with the lying endpoint problem. Tim pointed out that this was outside the scope of the charter, although the intent is that the NEA WG protocols accommodate solutions to addressing this problem. Susan asked about next steps for addressing IESG concerns re the requirements draft. Steve responded that Paul Sangster is working with the IESG to resolve the PT concern. A new -07 version will be posted and changes reviewed by the mailing list prior to sending to the IESG. Review of PB-TNC: Steve described the PB-TNC protocol for carrying PB messages between a Posture Broker Client and Server. He reviewed the protocol requirements, state machine and protocol format, and then took questions from the working group. Kaushik said he would send editorial comments to the mailing list. Kaushik asked about how the protocol handled multiple sessions, possibly over multiple PTs. Steve responded that multiple sessions can be supported by assigning a different connection ID or socket number to each session. This would be handled through APIs, which are not in scope for this WG. Kaushik raised the issue of supporting server-initiated reassessment given the half-duplex nature of the protocol. Steve responded that this is an important issue. If the WG consensus is to address this issue, it could be in a subsequent draft. Tim added that adoption of this proposal as a -00 draft does not preclude such changes, assuming it is agreed that the draft provides a sound foundation for doing so. It is good to highlight such issues, but the draft should not be regarded as fully baked. Gary Tomlinson says there are issues to be worked through, but believed the draft provides a solid starting point. Yaron Sheffer queried the size of the Private Enterprise Number. Steve clarified that it was 24 bits. Yaron asked whether there was a need for conflict resolution if two servers initiated a posture exchange at the same time. Steve said the assumption is that this use case would be supported through distinct sessions. Yaron asked for clarification regarding how information was routed between Posture Collectors and Validators. Are Posture Collector Indetifier (PCI) and Posture Validator Identifier (PVI) types or instances? Steve answered that the PA subtype indicates the type of information the PC and PV are reporting on e.g. anti-virus. PCI and PVI indicate the instance. Kaushik asked about the reason for vendor-specific identifiers in PB. Steve responded that this supports vendor-specific PB message types. Kaushik says need to take offline to clarify. Susan asked why assertion attributes had been omitted from the spec. Steve said it was not part of the requirements. There was no particular reason for omitting it in the first version, but rather it was mainly due to lack of time to consider a proposal. Jeffery Dion asked about queuing up messages prior to sending them for efficiency purposes. Steve responded that this could be done, and was an implementation issues versus a protocol issue. PA-TNC Review: Steve described the PA-TNC protocol which carries posture attributes between one or more Posture Collectors and Validators. He reviewed the requirements, design and protocol format, and then took questions. Kaushik raised the question again of the need for vendor identifiers at both the PA and PB layers and suggested that there may be alternate ways to support vendor-specific attributes that could be taken to the list. Gary Tomlinson asked about constraints on port filter semantics. It was agreed to take this issue and comments on other posture attributes to the list. PA-TNC Security Review: Steve described the PA-TNC security protocol which secures communication between Posture Collectors and Validators and is based on Cryptographic Message Syntax (CMS). Steve also presented a list of concerns regarding the draft including the need for review by CMS experts, data size, implementation complexity and ease of configuration of PC and PV authorization. Michael Peck questioned the MUST requirement for including the signer's certificate. Steve agreed that client may not need it. Michael said there are many options in the spec which may need to be trimmed down. Kaushik shared Steve's concerns re deployability. He suggested deferring a decision on PA-TNC security until further progress has been made on PA and PB and the implications are better understood. Steve said that given the publish/subscribe model, there is some concern regarding the appropriate authorization for Posture Collectors and Validators. Gary concurs re concerns, and believes that most people will not need this level of security, and that PT security is sufficient. Kaushik added that one of the original reasons for PA security was because server components are not co-located. However, it is possible that the security issue can be addressed by securing the vertical protocol itself when it is defined. Steve agreed that this was one possible approach. Yaron asked whether mutual authentication is required at the PT layer. Steve answered yes. Yaron said that he is still confused on message routing between different components. Steve explained how individual instances of PC/PV are identified and clarified the use of the correlation ID. Gary added that the “wildcard” usage in PA needs to be clarified. Steve agreed and, and said that, as Nancy pointed out on the mailing list, it would be good to have examples. Consensus Check: The following consensus question was raised for each draft: "Do you support adopting the draft as a WG draft?" 1. Yes 2. No 3. Defer There was unanimous support at the meeting for adopting PA-TNC and PB- TNC as WG drafts. A majority supported deferring the decision on the adoption of PA-TNC Security until more work has been done on the PA and PB protocols so that the protocol implications are better understood. Tim said that the next step is to post this same consensus check on the WG mailing list. Kaushik asked whether there are any IPR claims to be aware of. Steve says none that he is aware of so far. Milestone Review: Susan reviewed the milestones saying that these have not changed since review at the last meeting. They have been posted to the mailing list and no issues raised. Tim agreed that these milestones could be added to the charter now. Next Steps: If consensus holds on adopting PA-TNC and PB-TNC, Tim suggests these drafts be published as -00 WG drafts. The PA-TNC security draft should be left as an individual submission. Meeting adjourned.