Minutes from NEA WG Meeting IETF 69 in Chicago, IL July 23, 2007, 1:00 PM - 3:00 PM Chaired by Steve Hanna and Susan Thomson Notes taken by Mani Mahalingam and Joe Tardo These notes do not attempt to duplicate all the material in the slides. Instead, they provide a brief summary of that material and focus on comments and discussion (especially consensus checks). Steve and Susan called the meeting to order at 1:04 PM and reviewed logistical information about the group (email list, chairs, etc.). Blue sheets were distributed and minutes scribes found. No Jabber scribes were found. The following draft agenda was agreed to: 1:00 Administrivia Blue Sheets Jabber & Minutes Scribes Agenda Bashing 1:05 WG Status 1:10 Discuss NEA Requirements Draft http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-03.txt 2:55 Review of Next Steps 3:00 Adjourn *WG Status* Steve reviewed the current status of the Working Group. Our requirements document is in Working Group Last Call. Please review it and sent comments to the list. Steve asked for a show of hands from those who have read some version of the requirements document and another show of hands from those who have read the latest version (-03). A good number of people raised their hands for both. Steve explained that our next steps are: * Finish WGLC on NEA Requirements I-D * Revise NEA Requirements I-D * Another WGLC if major changes made * Submit NEA Reqs I-D to IESG for IETF LC and approval as Informational RFC * Revise milestones to start work on PA & PB Tim Polk (our AD) agreed. Paul Hoffman: When will the rechartering start? Tim Polk: We should start work on that when IETF LC completes so that it can be approved when or shortly after the time when the IESG approves the requirements document. Steve Hanna: I hope we'll only need to change milestones not do a real rechartering. Tim Polk: If that's true, it will be easy. Hannes Tschofenig: The mailing list has been quiet, which means the document has not received much review. You need more review, especially since this document has more than just requirements. Tim Polk: Agreed. I'm going to recruit more reviewers. We were waiting until the document was solid. Steve Hanna: Could I see a show of hands from people who are willing to review the document? Got seven volunteers. Hannes: Write down people's names so you can bug them! Here are the names of the volunteers: Hao Zhou, Nancy Winget, Alan Breese, Alan DeKok, Joe Salowey, Mauricio Sanchez, and Hannes Tschofenig. Steve reviewed the NEA Reference Model and reminded people of the WG's scope: endpoint assessment and in particular agreeing on standard PA, PB, and PT protocols. *NEA Requirements* Kaushik Narayan started reviewing the latest NEA requirements document. He reviewed the changes made in the -02 and -03 drafts. See his slides for details. Kaushik raised some issues for discussion. 1) The current draft contains informative text that touches upon a few aspects of protocol design at a high level to provide guidance but does not impose requirements. Should this text be retained? Paul Hoffman: It's good to have this text as long as you make it VERY clear that this text is informative. Kaushik Narayan: We've tried to do that. Steve Hanna: Is it true that the only normative text is in the Requirements section? Kaushik Narayan: Yes. Steve Hanna: Maybe we should say that somewhere. Paul Sangster: We do. Susan Thomson: We must make sure this is clear and not confusing. Steve Hanna: Maybe we should place at the beginning of each section a reminder that all normative text is in the Requirements section. Susan Thomson: We should also avoid having too much informative text. Paul Sangster: I think we should just change the title for the Requirements section to say "ONLY NORMATIVE TEXT". Steve Hanna: That wouldn't address my concern sufficiently. Kaushik Narayan: Let's take this to the list. 2) Requirement PB-3 seems redundant in light of requirement C-1. In fact, the requirement for supporting multiple messages can be met by the PT layer or the PB layer so this requirement is going into protocol design. Should we remove requirement PB-3? There were no comments on this topic at the meeting. Kaushik Narayan: The Design Team has decided we'd like to remove requirement PB-3. If there are no other comments, we'll do so. 3) The Privacy Considerations section includes implementation guidelines. We haven't received much input on this section. Is it adequate? Too much? Not enough? Needs to be changed? Mauricio Sanchez: I think the document is going in the right direction and has the right level of detail. Steve Hanna: Are there privacy experts we should consult? Tim Polk: I'll look into that. Kaushik Narayan: And we'll take this to the list. Kaushik Narayan: OK. That's the last of the open issues we wanted to discuss today. But we thought it would be productive to review every one of the requirements in the draft now and see if anyone has any concerns or issues with them. Kaushik ran through the requirements, starting with C-1. The text here is taken from Kaushik's slides. C-1 Capable of multi-message dialog Hao Zhou: You mean multiple round trips? Kaushik Narayan: That's right. This is clear in the actual requirement text. I'm sorry the summary on the slide is ambiguous. C-2 Allow assessment prior and after normal network access C-3 Enable re-assessment by either client or server Paul Hoffman: What's the difference between C-2 and C-3? Kaushik Narayan: C-3 is about triggering. It's saying that either the client or server should be able to trigger a reassessment. Alan Breese: So C-2 is about initial assessment and C-3 is about reassessment? Kaushik Narayan: Actually, C-2 includes both initial assessment and reassessment. C-3 says either party can trigger reassessment. C-4 Protection against active/passive attacks by intermediaries C-5 PA and PB transport agnostic interfaces C-6 Selection process prefer reuse of existing open standards C-7 Scalable (many collectors and validators on multiple servers) C-8 Efficient transport of many Attributes C-9 Large numbers of compliance policies C-10 Allow for Assessment with reduced amount of information exchanged Alan DeKok: For C-8, if the server caches the results of previous assessments, later assessments can be quick since they can just send what has changed. For C-9, I'm not sure there's any way around that. If you don't comply, you may need to download a lot of data to come into compliance. Kaushik Narayan: For C-9, we'd just be looking for ways to make the data transmitted for assessment as small as possible. Alan DeKok: The only way we know to express complex policies is running code. So I'm not sure I agree with C-9. You can push down the policies during remediation along with patches, not during assessment. Then assessment will be much faster. Kaushik Narayan: We removed the idea of policy attributes so policies will no longer be pushed down during assessment. PA-1 Support transport standard Attributes PA-2 Support transport of vendor-specific Attributes PA-3 Enable validator to request Posture and Assertion Attributes from client's Collector PA-4 Allow for multiple requests for posture information within a single assessment. PA-5 Carry validator results and remediation instructions PA-6 Capable of authentication, integrity and confidentiality of Attributes PA-7 Capable of carrying Attributes including binary data PA-8 String Attributes being encoded with an encoding standard that supports internationalization. PB-1 Capable of carrying the decision and (if present) remediation instructions PB-2 Carry naming for collectors and validators (used for message delivery). Naming should allow for dynamic registration. PB-3 MAY be capable of authentication, integrity and confidentiality of messages, decision and remediation instructions PB-4 Support grouping of attributes to optimize messages per roundtrip PT-1 SHOULD incur low overhead for low bandwidth links PT-2 SHOULD be capable of using a half duplex link PT-3 MUST NOT interpret the contents of PB messages PT-4 Capable of protecting the integrity and confidentiality of the PB messages PT-5 Reliable delivery of PB messages (detect dups, fragmentation) PT-6 Capable of mutual authentication (possibly leveraging an authentication inside the protected tunnel.) An open mike session was next. Alan DeKok: Overall, much clearer than the previous versions. I'd still like to emphasize clarity and simplicity. I have sent some comments to the list and will send some more. In Section 5, every other word is "posture". At that point, it doesn't mean anything. Just take it out. There were no other comments. Steve Hanna: Please review the current draft, which is draft-ietf-nea-requirements-03.txt. It's in WGLC, which closes August 10. Send comments on the document to the list.