Subject: RE: [Nea] Draft NEA BOF minutes

From: Steve Hanna <[email-masked]>
Date: Wed, 29 Mar 2006 20:01:47 -0500

Thanks for pointing out this omission in the minutes, Jordi.
I will correct it in the next version.

Take care,

Steve 

> -----Original Message-----
> From: JORDI PALET MARTINEZ [mailto:[email-masked]] 
> Sent: Tuesday, March 28, 2006 10:52 PM
> To: [email-masked]
> Subject: Re: [Nea] Draft NEA BOF minutes
> 
> Hi Steve,
> 
> When the consensus check was done, I step into the mic and 
> indicated that
> this is a very important work and we have already been 
> working on this for
> two years; actually we were also about to have a DISTSEC (distributed
> security) BOF, and my view about NEA is that is not clear to 
> me if this work
> is already focused in one direction which not necessarily is 
> the right one
> (and that's why we were working in DISTSEC).
> 
> For some reason this has not been captured in the minutes, 
> and I think is
> very important, as we may need first a more open view of the situation
> before going into something such as NEA.
> 
> Regards,
> Jordi
> 
> 
> 
> 
> > De: Steve Hanna <[email-masked]>
> > Responder a: <[email-masked]>
> > Fecha: Mon, 27 Mar 2006 14:44:13 -0500
> > Para: "[email-masked]" <[email-masked]>
> > Asunto: [Nea] Draft NEA BOF minutes
> > 
> > Here are the draft minutes from the NEA BOF last Tuesday, 
> March 21, 2006.
> > Thanks to
> > Mauricio Sanchez and Hormuzd Khosravi for taking great 
> minutes. I may have
> > introduced
> > some errors in combining them so please review these and 
> send any comments
> > or
> > corrections to the list. Please send comments within one 
> week so I can get
> > the final
> > minutes posted on schedule.
> > 
> > Thanks,
> > 
> > Steve
> > 
> > -------------------
> > 
> > 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.
> > 
> > Uri Blumenthal - We should just do requirements for the yellow box.
> > 
> > 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.
> > 
> > _______________________________________________
> > Nea mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nea
> 
> 
> 
> 
> **********************************************
> The IPv6 Portal: http://www.ipv6tf.org
> 
> Barcelona 2005 Global IPv6 Summit
> Slides available at:
> http://www.ipv6-es.com
> 
> This electronic message contains information which may be 
> privileged or confidential. The information is intended to be 
> for the use of the individual(s) named above. If you are not 
> the intended recipient be aware that any disclosure, copying, 
> distribution or use of the contents of this information, 
> including attached files, is prohibited.
> 
> 
> 
> 
> _______________________________________________
> Nea mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nea
> 

_______________________________________________
Nea mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea