Subject: [Nea] Draft NEA BOF minutes

From: Steve Hanna <[email-masked]>
Date: Mon, 27 Mar 2006 14:44:13 -0500

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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 29 Mar 2006 10:52:00 +0200

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
> 

**********************************************
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.

---

From: "Thomas Hardjono" <[email-masked]>
Date: Wed, 29 Mar 2006 11:12:48 -0800

Thanks Jordi.

I should apologize first if anything I say offends anyone on this list.  But
I thought it would be useful to provide some context/background around NEA
(as I understand it:)  There is, I think, focus on the work being proposed.
It may not have come across that clear in the BOF. 

There is already a large body of work behind the Trusted Network Connect
(TNC) effort and also behind Cisco's Network Admission Control (NAC)
program. The TNC work started around May 2004, while NAC was probably even
earlier. The TNC community (which has nearly two dozen vendors) has already
published a bunch of specifications at N+I in 2005, and even some demo
implementations shown at N+I. Some vendors supporting TNC are already
implementing some portions of the TNC functionalities in their products.
Ditto with NAC partner companies.

So, its not that the folks proposing the BOF/WG are working from zero and
have no idea what they want to do:)

The reason I attended and support the BOF is to try to develop some *common
baseline architecture* agreement between TNC and NAC with the final aim of
interoperability between *implementations in products*. 

So, the focus of the BOF is this common baseline architecture. This is why
(rightly or wrongly) the draft focuses so many pages on a common
architecture (and spends few lines on background information).

I believe the folks proposing the NEA BOF agree that this is the focus and
direction (ie. very clear, in fact). So its not quite correct to say NEA is
not focused:)

I don't think NEA takes away anything from DISTSEC
(draft-kaeo-distsec-framework-00.txt). My reading of the distsec draft is
that it focuses on policy definition/creation and enforcement (ie. core
proposal is in Section 6.5 and 6.6). So, in many ways it complements NEA.

cheers,

/thomas/

-----Original Message-----
From: JORDI PALET MARTINEZ [mailto:[email-masked]] 
Sent: Wednesday, March 29, 2006 12:52 AM
To: [email-masked]
Subject: Re: [Nea] Draft NEA BOF minutes

Hi Steve,

Regards,
Jordi

> 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
> 
> And there are a lot of major vendors in this room. I hope we'll get 
> good participation.
> 
> 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.
> 

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.

---

From: Merike Kaeo <[email-masked]>
Date: Wed, 29 Mar 2006 11:52:14 -0800

I agree that NEA essentially complements the  distributed security 
work.  In my opinion it is a subset of the problem that the distributed 
security problem statement /threat model is based on.  My hope is that 
the NEA work ensures that any common baseline architecture can later be 
supplemented to take into consideration distributed policy enforcement 
and distributed firewall architectures.

- merike