Draft Minutes of IETF NEA BOF at IETF 66
July 11, 2006
Minutes taken by Brian Ford and Mauricio Sanchez

Meeting was called to order at 9:01 AM
Steve Hanna and Susan Thomson chairing

*Agenda Bashing*

No agenda changes needed. Chairs were asked to please give their email
addresses. They were added to the title slide.

*NEA Background Presentation*

The chairs went through the NEA background
presentation in the slides. See those slides
for content. Questions asked are noted here.

Dave Oran: Does NEA include a capability for the client to
interrogate the network to make a decision if it wants to join?

Susan Thomson: This is not in our requirements.

Eric Rescorla: Any given system has many pieces of software installed
and many may not have the capability to communicate via NEA. What
fraction of applications are expected to be able to provide posture
data?

Steve Hanna: Most applications will not include a posture collector or
validator. Instead, something like a patch manager application would
provide posture for a large number of applications.

*Discussion*

Discussion of the NEA Use Case and Architecture began.

Jeff Schiller: If lying endpoints are not in scope, what's the point?

Uri Blumenthal: NEA is a vaccination technology not a treatment
technology. It is infeasible to detect a lying endpoint just with
protocols. But there are other methods being developed, like TCG's TPM.

Kurtis Lindqvist: Lying endpoints are important.

Bernard Aboba: Are we saying that NEA will be incompatible with TPM
and other technologies that use signed assertions?
Steve Hanna: We can do this with vendor-specific attributes.
Uri Blumenthal: Calling those vendor-specific is misleading. They'd
probably be vendor-independent, especially for TPM.

Michael Galant: Does the architecture support external validators?
Steve Hanna: Yes. Validators can take input from external sources
like Intrusion Detection Systems and network scanners.

Stefan Santesson: This is a solution that allows us to reduce risk of
operating a network. The community consists of different vendors with
solutions. We have customers looking for solutions with common
interfaces. But standards do not work well when vendors try to impose
their will through standards.  We might be too early to know where
that vendors-customer ecosystem should exist.
Susan Thomson: Actually, lots of work has in fact been done.
People have been shipping products that do this for years.

Thomas Narten: When I hear that lying endpoints are out of scope, I
fear that security is out of scope and that the system will not work.
Adding security later is very hard.
Steve Hanna: TCG has done lots of work on handling lying endpoints.
But IETF does not want to get into that area. So that problem is 
not being avoided. External mechanisms can be used.

Eric Rescorla: The techniques for detecting lying endpoints are not
compatible with open systems. What is the likelihood that a posture
collector from one vendor will interoperate with a posture validator
from another vendor? And will this working group stay around to
standardize more attributes?
Steve Hanna: For standardized attributes, we should be able to get
good interoperability. I hope we can avoid hanging around for years,
extending that set of standardized attributes. Just choose a few.

Uri Blumenthal: Big vendors are already doing this. The question is
whether IETF will step in to develop an interoperable solution.

Vidya Narayanan: It is not clear to me what the scope of
interoperability is here. What is it in terms of interoperability are
we talking about?
Susan Thomson: Posture attributes will likely be vendor specific. All
we are talking about is trying to standardize how the communication
will work.
Vidya Narayanan: Are we trying to standardize SMS (Microsoft Systems
Management Server)?
Ryan Hurst: No, this is not SMS. Customers definitely want
interoperability. But I'm not sure that this work will provide an
interoperable solution. It doesn't cover all the protocols needed.
Also, it will take a long time to be completed. There are a number of
EAP methods that are stalled in draft stage. And how successful can we
be if only limited posture variables are available? Again, I'm not
sure that as chartered the WG will result in a working solution.

Tim Polk: Solving the lying endpoint problem should be out of scope
but the group should be required to provide protocols that are
designed to support solutions for detecting lying endpoints. The
charter should be updated to reflect this.

Pat Calhoun: This technology is being deployed whether the IETF wants
it or not. If the IETF doesn't get involved, all the issues raised
today probably won't be addressed.

Amardeep Sibia: I'm with Goldman Sachs. NEA is a risk mitigation
technology for us and most of our peers in the industry agree with
us. Without standards in this area, we fear that we may invest here
and in 2-3 years not have a viable technology solution that supports
this.

Bob Morgan: We need solutions to the lying endpoint problem. NEA
should at least be compatible with those. The set of attributes will
need to be constantly extended (like MIBs and LDAP). Multiple
transports is fine. That may raise a negotiation issue but it should
probably be out of scope. But you should at least ID an EAP transport.

Unknown Person (Leif Johansson?): I support Tim's comments. And I
support the need for external sources of posture information. On
detecting viruses, we needn't be perfect to be useful.

Ryan Hurst: A number of players in this industry are already trying to
work together. This proposal maps to what they have produced so far.
I do see value in a standard being created but I worry about the
narrow scope of the charter. It should be scoped to reflect the
overall problem area, not current vendor capabilities.

Bernard Aboba: NEA's assumptions about posture transport don't always
hold true. For example, EAP-PEAP doesn't support arbitrary inner
methods.

Thomas Narten: We have to be careful about having most of the posture
data in vendor-specific attributes. That can lead to poor
interoperability.

Susan Thomson: Posture collectors and validators will likely come from
the same vendor, but that is not required if they use the minimal set
of standard attributes. The rest of the architecture may or may not
come from the same vendor.

Stefan Santesson: Where are you expecting interoperability?
Steve Hanna: The goal for NEA is to achieve client/server interoperability. 
Stefan Santesson: The NEA architecture diagram is not representative
of all possible or even all current architectures.
Sam Hartman: What else should be added?
Stefan Santesson: It's too early to tell what the best architecture is
and where standardization should be done.
Susan Thomson: The NEA architecture can support a wide variety of
Posture Transport protocols.
Sam Hartman: You should have one that's Mandatory To Implement to
ensure interoperability.

Richard Graveman: Lying endpoints can cause lots of problems. We
should say in a positive sense what we're doing. Is this perimeter
defense? Maybe this isn't security and should be done in the
applications or operations area.

Vidya Narayanan: I question the viability of NEA given perceived
issues around limited posture attribute definition, EAP
incompatibilities, and limited EAP deployment in the enterprise.
Posture validation should not be part of network access
authentication. Otherwise, it will be too intrusive and slow.
A UDP transport would be much better.

Steve Hanna: NEA will support a variety of Posture Transport protocols
not just EAP.

Thomas Narten: Typically in the IETF there is one mandatory to
implement protocol and other optional protocols. That helps ensure
interoperability. Are you saying there won't be a mandatory to
implement Posture Transport protocol?

Steve Hanna: The NEA WG is not the appropriate forum for standardizing
Posture Transport protocols since those go beyond what's needed for NEA.
However, we certainly could identify one as mandatory to implement if
IETF standardizes some.
 
Susan Thomson: There is no standard mandatory to implement EAP carrier
like 802.1x. Why must we define mandatory to implement for all
protocols in the stack?

Thomas Narten: That's necessary to get interoperability.

Brian Ford: Vendors should publish specs for the attributes they
invent so others can reuse them. Also, endpoints can decide which
networks they want to connect to.

Joe Salowey: Most current products support EAP. There are several good
existing EAP methods for this. We probably need the IETF to
standardize one and then we can make it mandatory to implement.

Amardeep Sibia: There are many Posture Transport protocols now.
I'd like to have that set narrow down. Standard attributes are good
but there will always be a need for vendor-specific attributes also.

John Vollbrecht: This is a good architecture. It doesn't solve all
problems but it enables solution of many. For example, it doesn't
detect lying endpoints but it allows other technology to do so.
Collectors can do many things: user authentication, client assessment
of the network, etc. We shouldn't downplay the value of this work.

Pat Calhoun: Is some set of standard attributes in scope?
Steve Hanna: Yes.
Pat Calhoun: Some people have said we can't get interoperability
across vendors. Do you agree?
Susan Thomson: We can get that if it's useful.
Pat Calhoun: Do you think it's useful?
Steve Hanna: I think it's useful and it's in the current draft charter.

Pat Calhoun: This year, I'd say that about 90% of new wireless nets
are running 802.11i not VPNs. And use of 802.1x in wired nets is
increasing.

Dave Oran: I'm speaking as an individual and have several comments.
First, it is an architectural error to cast this as a client server
protocol. It's equally important for the client to evaluate the server
to ensure that its credentials aren't stolen.
Second, at the transport level you can't punt so much. If you don't
define a mandatory to implement Posture Transport protocol, then the
Proxy Broker protocol must be securely proxyable so you can have a
protocol translator in the middle.
Third, posture collection shouldn't be coupled with authentication.
There's no need for those to be so strongly coupled.
Fourth, if SIP had vendor attributes, we'd have a huge mess. Maybe you
should require vendors to publish RFCs with the syntax and semantics
of their attributes.

Stefan Santesson: There might be multiple transport protocols. And
there is also the issue of timing. Do you do posture collection when
you connect to the network or do you do it beforehand and collect a
token that you can use when you connect to the network? Posture
attributes should be the focus for standardization.
Susan Thomson: This system allows for prior posture collection and
assertion.
Stefan Santesson: That's my point. Transport isn't the important issue.

Ryan Hurst: We will need to standardize on the higher level components
as well as the lower for a truly interoperable solution. Microsoft has
documented our equivalents to PA and PB on MSDN and committed to
royalty free licensing of them. And we'll revise our PEAPv0 document
to document the known implementation hurdles and document how PA and
PB can be carried. I'd like to see everyone document how they do
things today so we can achieve interoperability and then we can look
at the larger problem of how best to solve this problem. There is
value here but the scope should be wider.

Dave Nelson: I agree with previous comments that we need true
interoperability and what that entails. What we're discussing here is
necessary but not sufficient. And maybe not generally useful. So maybe
it's not worth creating a Working Group. And if we're going to do only
this part of the work, someone else must finish it.

Brian Ford: The NAC marketplace is exploding. At the RSA show, there
were 24 new NAC-oriented companies. There are dozens of anti-virus
vendors. The time is ripe for IETF to get involved. Everyone needs
multi-vendor interoperability across OS, network hardware, etc.

Bernard Aboba: We can only standardize things we know how to do.
There are dozens of important transport and other documents that IETF
hasn't published. We need to get those published for this work to be
useful.

Steve Hanna: Time for some consensus checks.

* Do you favor IETF forming a WG to work on the NEA problem as
described in the use case described on the slide?

Hum. Outcome: Roughly 2/3 in favor, 1/3 opposed

* Are you comfortable with the architecture shown on the screen and
described in the problem statement? Shall we proceed with this and
with the scope of the WG to be PA, PB, and requirements for PT?

Sam Hartman: Let's hum on Tim's suggestion re lying endpoints first.

* Should we revise the charter to say we're required to support
solutions to the lying endpoint problem but that we won't solve it
ourselves?

Hum. Overwhelmingly in favor.

* With that change, let's return to the previous question. Are you
comfortable with the architecture and scope with that revision
(PA, PB, and requirements for PT)?

Hum. Roughly evenly divided.

Unknown Person: Let's split this by levels to pinpoint the problem.

* Are you comfortable with the overall architecture as a reference
model: three layers with protocols at each layer?

Hum: Large majority in favor.

Eric Rescorla: Why aren't we talking about the charter?
Steve Hanna: We don't have time to discuss the details of the charter
language. All we'll have time for today is maybe to agree on scope.

* Who is uncomfortable with having PA in scope?

Hum: Very few.

Eric Rescorla: But there was big discussion on which attributes should
be standardized.
Steve Hanna:

* Are people comfortable with standardizing the PA protocol and a
small set of messages?

Hum: Majority uncomfortable.

* Are people comfortable standardizing the PB protocol here?

Hum: Majority comfortable.

* Are people comfortable only defining requirements for the PT protocol here?

Hum: Majority uncomfortable.

Dave Oran: For PA, let's do what SIP did: require an RFC
(Informational or Standards Track) to be written before attributes can
go in the protocol.

* Would you be comfortable with the PA-related scope if we adopted
Dave's proposal? We'd standardize PA, standardize some minimal set of
attributes, and require vendors who want to define attributes must
publish an RFC on those.

Hum: Large majority comfortable.

Sam Hartman: On PT, I suggest that we require this group to choose a
mandatory to implement Posture Transport.

* Would you be comfortable with the PT-related scope if we defined
requirements and then eventually our Working Group was required to
identify a mandatory to implement PT?

Hum: Majority comfortable. More than 2/3 but not total agreement.

Steve Hanna: I think we have agreement now on the reference model and
scope. Let me frame the next question. How about:

* Shall we form a NEA WG with the goal of achieving NEA client-server
interoperability across a variety of Posture Transports (assuming
Posture Transport interoperability) and with the scope as previously
described: standardize PA with a few standard attributes and require
vendors to publish RFCs for any vendor-specific attributes,
standardize PB, agree on requirements for PT, and identify a mandatory
to implement PT?

Lakshminath Dondeti: We should ask: given what we've agreed on, how
many people think we'll achieve something meaningful at the end of this.

Steve Hanna: Well, if you think this effort is pointless, please don't
hum in favor of creating a Working Group!

Hum on the question listed in the previous bullet, which was written
up on a slide during the meeting: Outcome unclear

Show of hands on the topic: substantial majority in favor

Sam Hartman: Let's hear 30 second statements from people who don't
think we should form a Working Group.

Ryan Hurst: Charter as specified is too narrow to create an
interoperable solution. Need more detail in PA. But IETF shouldn't
standardize most attributes. And need a more forward-looking
architecture.

Bernard Aboba: I was happier without the most recent changes,
especially identifying a mandatory to implement PT. That's a can of
worms.

Vidya Narayanan: There are so many operating systems and such.
Whatever we do won't create a meaningful interoperability.

Dave Oran: To convince me, you'd have to address my previous points
about symmetry and tying this to authentication.
Steve Hanna: Clients can 

Eric Rescorla: I'm skeptical that this whole concept will work.

Lakshminath Dondeti: ADs, can we slap an applicability statement on
this now? It seems clear to me that this won't work on service
provider networks.

Unknown Person: We should have a show of hands from those who want to
participate.
Steve Hanna: We did that last time but we can do it again.

* Who would be willing to participate actively?

Significant number of hands (15-20).

* Who would be willing to edit or author documents?

Good number of hands (10-15).

Steve Hanna: ADs, anything else we need to do?

Sam Hartman: No. I just want to say that there will now be a
discussion within the IESG of this issue and that will be a very
interesting discussion.

Steve Hanna: Yes, it's not a shoe-in.

Sam Hartman: But this BOF went better than expected and about as well
as it could.

Steve Hanna: I'd like to thank the ADs and BOF participants for a very
constructive and helpful BOF.

Meeting adjourned 11:27 PM