Draft Minutes of IETF NEA BOF at IETF 65 March 21, 2006 Taken by Hormuzd Khosravi and Mauricio Sanchez Steve Hanna reviewed the agenda and goals for the BOF. Susan Thomson gave a presentation on the NEA Problem Statement Internet-Draft. Discussion of the problem statement began. Stefan Santesson - I agree this is an important problem. But the protocols you have described are architecture dependent. It's not clear what you are trying to achieve. Steve Hanna - We are trying to achieve interoperability between NEA clients and servers. Amardeep Sibia of Goldman Sachs - Posture should include location as well. Steve Hanna - Do you mean geographic location or topological location? Amardeep - Both. Sam Hartman - Why focus so much on RADIUS? The protocols should work with DIAMETER or other protocols. Also, the posture data format should be specified. I understand why some of that needs to be proprietary but there should be a standard mandatory to implement posture format to ensure interoperability. Susan Thomson - The Posture Attribute protocol does define posture attribute format. It may address your concerns. As for RADIUS, there may be a need for new RADIUS attributes for new enforcement mechanisms. Bernard Aboba - We already have EAP-TTLS, PEAP, and EAP-FAST. Why don't we just publish those? Hao Zhou - It's too early to tell whether we'll simply pick a protocol or design a new one. Bernard Aboba - A posture attribute format is built into the PEAP & EAP-FAST. Hao Zhou - This may be true but vendors still use vendor specific attributes. Mike Linsco of General Motors - This is a very important subject for enterprises. Interoperability is crucial for this technology. We must have standards for this. Ram of Avaya - Is the goal to define a standard posture policy or define a framework? Steve Hanna - This group would not define a minimum policy for nodes to get onto the network. That would be up to the network administrator. Stefan Santesson - The interoperability goals are not clear enough to form a working group. There are several separate problem domains: A) how to communicate between client and server B) how to protect/authenticate communication C) how to express a statement of health. Also, RADIUS may not be applicable. IPSec (for example) could be used for enforcement. Uri Blumenthal - All of the lines in the diagram should be considered as protocols. The standard should not be restricted to particular interfaces. I do not think we should standardize posture attributes beyond the overall structure. Vidya or Tatiana of Qualcomm - Forcing EAP as a requirement is too limiting. Certificates allow greater application, regardless of the transport. Uri Blumenthal - You can't put posture into certificates. Certificates are long-lived and posture is short-lived. John Vollbrecht - The problem with the current tunneled EAP methods is that they are not well defined and documented. Getting standards for those is therefore important Elwyn Davies - The integrity of the client posture is important for the total solution, Are you going to work on this? Steve Hanna - This is the classic "lying client" problem. A compromised client can lie and say it's totally healthy. There are ways to mitigate this risk using a trusted software kernel or trusted hardware. But the NEA architecture is useful even if you don't solve the lying client problem. It helps keep honest clients healthy, thus reducing the risk of infection. You can think of that as an immunization program. But no, we won't work on solving the lying client problem. That can be done as an add-on to NEA. Amardeep Sibia - I'd like to reiterate that this is a very important problem in the enterprise. I'd also like to raise another issue. Some clients may not have an agent. That needs to be addressed as well. Pasi Eronen - The problem statement would benefit from additional discussion on what interoperability means. Ideally, posture collectors and validators from different vendors should be interoperable. But there's still value in standardization even if posture attributes are proprietary. Unknown Person - The Trusted Computing Group has been already working on this and has published several standards. You should look at them. Stefan Santesson - Certificates don't need to be long-lived. They can be short-lived. Also, certificates can be used with IPSec, TLS, etc. Pasi Eronen - A certificate would work if this was one way information only. But it will not work for two way communication. Uri Blumenthal - A statement of health could be used in a certificate. I want collectors and validators from different vendors to interoperate. Vidya or Tatiana of Qualcomm - Clarifies previous comment on certificates. My point is that limiting NEA to a specific set of EAP methods is overly limiting. Steve Hanna - User authentication can use any EAP method if you run it in a tunneled EAP method with an EAP method that carries posture. Thomas Narten - What's the client model? Will code for this ship in the operating system? Susan Thomson - An operating system could ship with a default policy of what it collects, but it's expected that most enterprises will want to have their own policy. Bob Hinden - This is a big problem, I'm not sure you understand it, and it's awfully complicated to get all the applications to support this. Anyway, it doesn't solve the problem. People who hack systems are very sophisticated. If you build this, they will just figure out how to subvert it. Steve Hanna - A trusted kernel or trusted hardware can make it much harder to subvert the system. And even if some attacks are successful, the health of endpoints will be improved overall. Security is not absolute. This is a big improvement. Susan Thomson - Information from other systems (like IDS) can be provide additional information beyond what the endpoint provides. Sean Conry -The lying client problem is manageable. As my father used to say, locks keep honest people honest. Bernard Aboba - Creating yet another EAP method doesn't make any sense. You should move one layer up and use IP. Steve Hanna - Runs through NEA Charter slides. Any comments? Questions? Unknown Person (Paul?) - How far up in the NEA architecture should we go? Where is the cut line? Sam Hartman - I believe this should be a Security area working group not an Internet area one. If you don't have some standardization of PA (at least a mandatory to implement minimum), then you won't have end-to-end interoperability so you won't meet the explicit IESG requirements. RADIUS is only one deployment scenario. You should be clear about when you're talking about EAP and when you're talking about RADIUS. They are separate. Paul Hoffman - A lot of work has been done in other groups. How do we pull in other vendors? Steve Hanna - Folks from TCG and Cisco are co-chairing this BOF. And there are a lot of major vendors in this room. I hope we'll get good participation. Stefan Santesson - Focusing this on EAP/Radius is wrong and the wg should not be chartered around this. Sam Hartman - Looks like we are rat holing on this. Margaret Wasserman - What problem are we trying to solve? The client might be completely unhealthy and lie about its state. Sam - NEA is definitely useful. I'd like to have the network inform me about new patches and offer to quarantine me to get them. And this is especially useful for inexperienced users. Jari Arkko - Yes, this is useful, but the charter isn't ready yet. We should agree on requirements first. Thomas Hardjono - How about a common standard for Posture Attributes? Sam Hartman - You need to be clear on how you want to achieve interoperability. Paul Hoffman - People are confusing format and protocols. Some see value in standardizing formats and some in standardizing protocols, some in both things. Instead of protocols, maybe we need to work with formats. Steve Hanna - I think I hear a consensus that the posture attribute (PA) protocol should be included in our scope. Is there consensus around that? Joe Tardo - Yes. Speaks in favor of standardization of PA. Steve Hanna takes a hum poll on whether standardization of Posture Attribute should be in. Poll is unanimous. Posture Attribute protocol should be in. Uri Blumenthal - PV is necessary in addition to PA. Paul Hoffman - Standardization of protocol between server broker and network access authority should also be considered. Uri Blumenthal - All the interfaces in the architecture diagram should be standardized. Steve Hanna - We don't need that for client server interoperability, which I have heard is the highest priority. Mark Townsley - Is PV a protocol or an API? Susan Thomson - In some existing architectures, it's a protocol. In others, it's an API. Uri Blumenthal - PV is necessary for a multi vendor solution. Steve takes hum poll on which protocols should be standardized as part of NEA charter: Posture Validation protocol - Clear majority in favor Interface Posture collectors and client broker - Uncertain Client broker and network access requestor - Clear majority opposed Server broker and network access authority - Uncertain Amardeep Sibia - I have a point to make on the problem statement. We should support endpoints that don't have agents. That's very important. Unknown Person - We should focus on the new work (PA, PV, etc.) that drives the rest of the protocols. Mark Townsley - Do we need to work on the yellow box (EAP & RADIUS) or might it be better to move up the stack? Stefan Santesson - Focusing on EAP/Radius may not be the right thing. Hao Zhu - We should define the requirements for the yellow box. Unknown Person - I want to provide some clarification on the EAP tunneling method. No wg is working on this right now. Amardeep Sibia - The yellow box is most important for interoperability. We do care about PA format as well. Consensus check questions for group (hum poll) Do you understand the problem? Yes Do you think it's an important problem? Yes Is it important and solvable? Yes Is there interest in forming a WG to solve this problem? There is some interest, but the results are not conclusive. Are you willing participate as a reviewer? About a dozen people held up their hands. Jordi Martinez - This is very important work. We have already been working on this for two years in the DISTSEC effort. Maybe the NEA effort is already focused in one direction which is not necessarily the right one.