Minutes from NEA WG Meeting IETF 68 in Prague, Czech Republic March 20, 2007, 1.00 PM - 3.00 PM Chaired by Steve Hanna and Susan Thomson Notes taken by Mani Mahalingam and Mauricio Sanchez 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. The following draft agenda was agreed to: 1:00 Preliminaries 1:05 WG Status 1:10 Proposed Milestone Revisions 1:25 Discuss NEA Requirements draft 2:40 FWNA, Eduroam, and NEA 2:55 Next Steps 3:00 Adjourn * WG Status * Steve reviewed WG status. Two revisions of NEA requirements draft have been posted since IETF 67. Steve asked how many had read either the -00 or -01 of the draft. A significant number of people raised their hand. * Proposed Milestone Revisions * Steve reviewed the updated milestones, a previous version of which had been distributed on the mailing list. He asked for a hum to determine support for the revisions. The hum demonstrated significant support for the revisions. There were no objections. The milestones will be confirmed on the mailing list before sending to the area director. * NEA Requirements I-D * Paul Sangster reviewed the -01 version of the NEA requirements I-D. He covered the following topics in the presentation in the meeting (please refer to the slides): --- Reference Model --- Attribute Types & Use Case examples --- Open Issues Reference Model: Paul reviewed the reference model agreed to at the IETF67 meeting. Steve asked whether there are any people in the room who do not understand what problem the NEA WG is trying to solve. Nobody raised their hand. Attribute Types and Use Cases: Paul presented three usage scenarios for NEA as the motivation for defining different attribute classes: (1) request/response for posture information (2) request for compliance to a given policy (3) allow for re-use of assertions from prior assessments. The requirements draft currently defines different types of attributes to meet these usage scenarios. A NEA server may send 4 attribute types: request attributes, policy attributes, result attributes and remediation attributes. A NEA client may send posture attributes, compliance claim attributes and assertion attributes. The requirements draft contains 5 use cases which are intended to illustrate usage of different attribute types. Paul presented the 5 use cases defined thus far. Yaron Sheffer: The draft has classified many attributes, but it does not specify the semantic power of attributes. Are attributes similar to RADIUS attributes? Are they collections of attributes, rule-sets for policies, etc? It could become very complex. Paul: The WG needs to specify the attributes in more detail in the protocol specs after completing the requirements document. The attributes may be more sophisticated than RADIUS attributes, because they may contain references to policies, for example. Yaron: A clearer description of attributes is preferred. Specify something more than "what attributes can do", but less than "what attributes can look like". Paul: This is a valid comment. For further discussion on mailing list. Alan de Kok: Not clear that all these attribute types are necessary. For example, the compliance claim attribute. Paul: The intent is to support the models previously described. Alan: No one knows how to transport policies well in protocol. Suggest not even try. Why would an administrator tell the client what the policies are since the administrator does not trust the client? Paul: The policy could be in the form of a URI or just some name, or some minimal indication of where the policies are. Alan: How is asking for the version of AV different from asking for compliance to a specific policy? Steve: There was discussion on the mailing list that it was important that allowance be made for privacy-sensitive clients; hence the current attribute in the draft. We can take this requirements back to the mailing list to reconfirm. Paul: This is another issue that should be discussed further on the list. Alan: Why does the draft identify 3 different protocols? There is a need for one protocol with layers of proxying. Paul: It seems that the draft is saying the same thing, just using different words. Leif Johannsen: The requirements I-D should explicitly state whether there is a need for a schema, or not. If so, do not invent a new one. Paul: The requirements draft does say that existing standards should be used where applicable. This comment is a similar one to the comment made earlier on attribute type definitions. This is another topic to be taken to the list. Chairs: All WG participants are encouraged to send their comments to the alias. Do not make the editorial team the bottleneck for raising issues on the list for resolution. Hannes Tschofenig: The draft includes a problem statement, use cases, architecture,trust-model as well as requirements. This was surprising given the document title. These topics are useful to have described, but at least change the title of the document. Also, the WG should have a chance to see some of the design team's discussions. Harald Alvestrand: Since the use of the term protocols for the three layers seems to be causing confusion, at least make the layering explicit. The term "prove" is asking for trouble. Another term should be used. Open Issues: Virtualization: Should virtualization be explicitly supported? This topic is not discussed in the current requirements draft. Three options presented: no change (ignored), say it's out of scope, or be more explicit about virtualization models and how NEA supports it . Alan de Kok: There should be a discussion on virtualization. The hypervisor is just a proxy to virtual clients. There is no need for a change in the model. Paul Sangster: There are many virtualization models. One would not expect the NEA client to be part of virtualization layer. Paul asks whether hypervisor should be actively involved in NEA process, or just act as a pass-through. Alan: Depends on whether the endpoint appears to network as one machine or as N machines. Tim Chown: What is the client identifier used to distinguish virtual machines? Need to identify these issues in the draft and specify explicitly that out of scope, not just ignore. Paul Hoffman: Virtualization is analogous to a NAT box which has multiple endpoints behind it. To NEA server, it looks like a single endpoint. Thus, no change in model. NEA client on non-endpoint: Should the draft recognize a device that acts as a NEA client for the endpoints behind it that do not have an NEA client? The device may be an intrusion detection system or intrusion protection system, for example. Alan de Kok: May be useful to talk about the specific case of NAT or FW acting on behalf of the endpoints they allow into the network. Mauricio Sanchez: Does this use case imply any changes to the protocol requirements? Paul: No changes foreseen to the requirements themselves. It changes some of the normative text. Mauricio Sanchez: It is better to focus on use cases that impact the requirements. Tim Chown: It would be useful to have some discussion on how the communication between IDS, NEA server and firewall works and how these devices get configured in this use case, but agree do not want to be too distracted by this. Is it possible to have multiple NEA servers in a domain? Paul Sangster: Yes, there could be multiple NEA servers Steve: How the NEA server communicates with an enforcement point is explicitly out of scope per the charter. Bob Morgan: This should be a supported option in the model. It does have an impact on protocol requirements because the protocol needs to ask about endpoint X even though talking to client Y. Paul Sangster: NEA server does create awkwardness in model, and agrees it will add attributes to the protocol requirements. Steve: Our AD needs to assess if this use case is within the scope of the charter. Tim Polk: The WG should continue to discuss the use case to better understand if this scenario falls within the scope of an endpoint as used in the charter. Depending on the outcome of this investigation, we may have to slate this for future work. Alan: NEA use cases need to take into account enforcement. Steve: Enforcement is present in the model but out of scope for WG. Tim Polk: The charter states that enforcement is not mandatory. Paul Hoffman: Suggests that we ignore this use case. It could be an extension of the existing reference model. Security at all layers: The requirements document currently specifies authentication, confidentiality and integrity requirements for all 3 layers. Requirements for PA & PT are currently listed as a MUST, while PB is a SHOULD. These requirements are intended to cater for cases where all client or server components may not be co-resident. Steve: Alternately, NEA could use hop-hop protection with remote validators on the NEA server. Paul: Yes. However, this does not support authentication of a posture collector to a posture validator or vice versa Hao Zhou: Why is there a need for protection on PA layer? Its possible for components at this layer to define their own since they typically come from the same vendor. Paul: Possible to do vendor-specific security, but the advantage is that there is a standard one that allows for interoperability. Paul: PB security is expected to be needed least as PT and PB components typically are co-resident. Mauricio Sanchez: Proposes making PB a MAY. Privacy considerations (Section 9.2 ) Paul said that intent of the current text in Section 9.2 is to be a starting point for discussion. The text was motivated by an earlier thread on the mailing list regarding privacy concerns with use of NEA. Paul described that, for privacy reasons, a client may have a policy regarding what information to disclose. Possible models are: --- Client sends all attributes by default --- Client has local policy regarding what attributes to send --- Client can respond to requests based on local policy. Server can iteratively request attributes (factoring in responses to previous requests). Richard Graveman: How do I know if a NEA server is legitimate? Paul: Through strong authentication of the NEA server. Trust anchors are pre-configured. Paul Hoffman: We just got into a policy rat-hole. One side should pick policy. The expectation is that this would be the server. If server asks for posture attributes, the client either responds or not. This is an option with any protocol. Need not specify in the requirements draft. Yaron: I think there should be some discussion in the draft, probably in an appendix in reduced form as implementation advice. The 3rd policy option mentioned in the draft is overkill, however. The client need not disclose information at the risk of not being allowed onto network. Hannes: There are more complex privacy considerations in the roaming scenario, where there is a difference between the access network and home network. Steve: The roaming use case is explicitly excluded from the charter and is out of scope. Other issues on current draft? Paul Hoffman: The requirements document currently lacks discussion of how remediation works and what happens afterwards. For example, an endpoint may be given restricted access for the purposes of remediation after which posture may need to be revalidated. Paul: Remediation is out of scope of the charter. Paul, others: The draft needs to describe that remediation could happen, not how it happens. Tim Chown: Should specify the quarantine phase in an example (while not describing quarantine enforcement itself) Leif Johansson (FWNA/EDUROAM): There was a short presentation on use of federated 802.1x in FWNA/eduroam deployments, and how it may be impacted by NEA. In these deployments, the network provider (foreign provider) and the identity provider (home provider) are different organizations when a host roams. If the same model is used when performing posture assessment, some method of communication is needed between the network and posture provider. While it is clear that support for such networks is outside the current NEA charter, the presenters' intent was to raise awareness of potential issues in an attempt to avoid problems with supporting such deployments in the future. Several proposals for resolving the issues without affecting NEA were suggested including (1) proxying (2) providing foreign network provider with a reference to the posture results and (3) separating authentication and posture assessment. Wrap-up: Steve discussed the next steps: --- Confirm revised milestones on mailing list --- Discuss open issues on mailing list --- Revise NEA requirements I-D --- Further discussion on list --- Revise NEA requirements I-D based on discussions --- WGLC in June