Minutes from NEA WG Meeting
IETF 67 in San Diego, CA
November 7, 2006, 3:20 PM - 5:20 PM
Chaired by Steve Hanna and Susan Thomson
Notes taken by Kaushik Narayanan, Mauricio Sanchez, and Paul Sangster

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 (especially consensus checks).

Steve Hanna welcomed people to the first meeting of the Network
Endpoint Assessment Working Group. He reviewed logistical information
about the group (email list, chairs, etc.). Blue sheets were
distributed and minutes scribes found. No Jabber scribes were found.
The following draft agenda was agreed to:

3:20 Circulate Blue Sheets, Identify Jabber & Minutes Scribes
3:25 Agenda Bashing
3:30 NEA Milestones
3:40 Discussion of Requirements I-D
5:10 Next Steps
5:20 Adjourn

*NEA Milestones*

Susan Thomson reviewed the milestones in the NEA charter. The current
milestones are aimed at getting a NEA Requirements document submitted
to the IESG by April 2007. Then we'll request AD approval to add
milestones to standardize PA and PB.

Susan Thomson reviewed roles and responsibilities within the NEA WG.
A NEA Requirements design team will be formed to develop an initial
draft of the NEA Requirements I-D and revise that I-D in response to
WG rough consensus. Volunteers for the design team should contact
Steve and Susan. A request for volunteers will be sent to the NEA
list and we hope to have the design team launched within a couple of
weeks.

The goal for today is to discuss what the requirements I-D should
contain and what use cases that requirements I-D should support.
And we'll solicit volunteers for the design team.

*Discussion of Requirements I-D*

Susan reviewed a draft outline for the Requirements I-D (included in
the slides) and asked if there are any obvious missing areas. There
were no responses.

Susan reviewed some basic terminology: endpoint and posture. An
endpoint is any device that can be connected to a network and get
an IP address. Posture is security-relevant configuration of an
endpoint.

Kaushik Narayanan: Isn't it true that posture can be a wide variety of
information as long as it's used in a security policy? That makes it
security relevant.
Susan: Yes.

Susan summarized the NEA problem statement: to assess the posture of
an endpoint and determine whether it's in compliance with a security
policy. Susan reviewed items that our charter says are in scope and
others that are out of scope but must be accommodated.

Susan presented the NEA Reference Model as described in the previously
published problem statement. She suggested a refinement to the model
to change the bottom layer to only perform posture transport since the
PT protocol may be separate from that used in access control/enforcement.
She asked if there are any comments or questions on this change. There
were none.

Steve Hanna took the mike to discuss use cases. The goal here is not
to identify all possible use cases for NEA. It is to identify a
minimal set of use cases that can be included in the Requirements I-D
and that spans the problem space. We don't need to have a lot of
information here, just enough to drive requirements definition.

Paul Ferguson: How can we discuss requirements before defining the
problem space?

Steve: The problem space is described in the charter and will be
described in more detail in the Requirements I-D.

Steve listed several types of flows:

 - Initial assessment - triggered by network connection or service request
 - Re-assessment - triggered by NEA server or client (because of an
   event, timer, etc.)

Steve listed and described several types of attributes:

 - Endpoint Data (client to server), by value or by reference
 - Compliance Policy (server to client)
 - Compliance Policy Evaluation Results (client to server)
 - Cryptographic Protocols (multiple round trips)
 - Compliance Result (server to client)
 - Remediation Instructions (server to client)

Eric Rescorla: Is cryptographic protocol information considered an
attribute? It's not helpful to have it defined as an attribute.

Yaron Sheffer: I thought compliance policy was out of scope. How can
you be including it in an attribute then?
Steve: I'm not suggesting that attribute should be standardized.
I'm just saying that's one attribute that can be sent. In fact,
our charter states that the set of attributes to be standardized
will be minimal. I don't expect policy would be in that set.

Mani Mahalingam: Are enforcement points out of scope?
Steve: Yes, our charter says so. Enforcement is out of scope. Other
IETF WGs do enforcement protocols.

Kaushik: Could completion of remediation be a trigger for reassessment?
Steve: Yes, that would fall under the category of client triggered
reassessment.

Steve: I'll present a set of use cases that seem to span the problem 
space as I understand it, driving all necessary requirements. See
slides for details of those use cases. Brief summary here:

John Smith - inventory collection of software on JS's endpoint at network join
             No enforcement.
Jane Doe -   send patch levels upon service request, upgrade advisory sent
             No enforcement.
Colonel Mustard - constant monitoring while on network. Endpoint detects a 
             posture change so triggers re-assessment. Access is
             limited since the system isn't in compliance.
             Re-assessment occurs after remediation which allows
             access to be restored.

Steve: Are there other use cases that must be addressed and which
drive new PA, PB, or PT requirements?

Bob Morgan: If the first use case is triggered by network connection,
you should show the network access elements. And this would drive PT
requirements since the endpoint may not have full network connectivity.

Doug Otis: Most assessments involve a separate assessment server.
Maybe that server should sign some credentials saying that the
assessment has been completed. Then the NEA server can just look at
those credentials.

Steve: Does that drive any new requirements?

Doug: Lots of trust issues are raised. The client needs to decide
whether it trusts the remediation instructions.

Steve: So that relates to the contents of the remediation instructions.

Alan DeKok: I'm concerned about the defined architecture being overly
limited as I can imagine other architectures for solving this problem.
We could have remediation happen inside EAP-TLS, for instance.

Steve: Using EAP to transport a lot of information such as remediation
doesn't work well. EAP is not well suited for bulk data transfer and
most wireless APs will time out after 25-200 round trips.

However the point remains that there are other architectures for endpoint
assessment. We need to stay within our charter, which talks about NEA Servers
and NEA Clients. So there are some limitations to what's in scope.

Khaja Ahmed: I wonder if a P2P use case would be helpful. And what
about non-enterprise scenarios where an ISP checks the consumer system
for them?
Steve: I think that may violate an applicability limitation in our charter.

Khaja: Am I right that PA might involve multiple round trips?
Steve: Yes. There are use cases where that's required.
Khaja: That could cause lots of latency due to many collectors causing
lots of round trips. There must be a better way.

Khaja: Compliance policy attributes (where the server tells the client
what the policy is) doesn't sound like a good model.

Steve: Any other comments? About any of this? None. So we'll take it
to the list.

Steve: I'm surprised at how quickly this has gone. We've come to the
end of the slides that Susan and I had prepared. Fortunately, Paul
Sangster has a presentation on the requirements I-D that was prepared
last spring when we were a NEA BOF. Of course, these are somewhat
dated and don't reflect the discussions around our chartering. But
it's probably useful to discuss them, given that we have the time.

Kapil Sood: We need a set of security requirements not just the
functional requirements discussed so far.
Steve: Yes, absolutely. We're going to have to do a complete security
analysis of the entire system. We can derive security requirements
from that.

*Review of Previous Requirements I-D*

Paul Sangster presented an overview of the old NEA BOF requirements I-D:
draft-khosravi-nea-requirements-01.txt. See Paul's slides for details.

Paul reviewed the outline and contributors for the spec. Then he
described terminology: component, message, session, and dialog.

Next, he summarized Common Requirements (common to PA, PB, and PT).

1. Capable of multi-message dialog

Khaja: This shouldn't be a requirement. Requirements should be higher
level, as they might be articulated by an IT administrator. This is
more design. And I don't think this is a good idea.

After further discussion, it was agreed that this should be discussed
more later.

2. Allow server requests prior and after network access
3. Possible for client to initiate a posture re-evaluation request
4. Protection against active/passive attacks by intermediaries
5. PA and PB transport agnostic interfaces
6. Selection process prefer reuse of existing open standards
7. Scalable (many collectors and validators on multiple servers)

Kaushik Narayanan: Requirements currently specify horizontal protocols
between NEA client and NEA server, how about the vertical protocols on
the client or server side?
Paul: Vertical protocols are currently out-of-scope in the charter.

Then Paul reviewed PA requirements:

1. Transport core attributes (vendor, version, operational status, ...)
2. Transport of vendor defined attributes
3. Validator request of particular client component's posture
4. Allow for multiple requests for posture information
5. Carry validator results and remediation instructions
6. Selection process prefer re-use of existing open standards for
   transport and attribute representation

Bob Morgan: Whenever you get into schema (attribute formats, etc.),
lots of issues come up. The client and server may need to agree on
which attributes are supported by each.

Doug Otis: We don't need any vendor-unique attributes if instead the
server just asks for certificates proving the client has passed
certain compliance checks. Vendor-specific attributes will cause lots
of compatibility problems.
Paul: Well, it would be nice to avoid those problems. Let's discuss
your idea more.

7. SHOULD support expression of prior remediation state (e.g. time,
   server used.) 
8. Capable of authentication, integrity and confidentiality of
   attributes, results and remediation instructions 

Yaron Sheffer: Those properties can be provided by PB or PT.
Paul: Actually, this requirement is specifically on PA. There are some
use cases that drive that requirement. For instance, a validator that
wants to know the collector is valid. Or a validatror and collector
that want to keep their messages confidential from other components in
the system (like the Posture Broker). We may not want to address
those use cases but we should consider them.

Yaron: PA should define the core attributes not just transport them.
Steve: This requirements I-D is old and pre-dates IETF 66 where the
group did agree to define the attributes. That's in our charter now
and it will be done.

Dave Nelson: When you say authentication of attributes, you really
mean authentication of the component that sent the attributes, right?
Paul: Right. The collector or validator.

Khaja: Does this mean all collectors and validators must be able to
protect their messages?
Paul: No. This means that the protocol must support such protection.
But the collector doesn't have to implement that feature.

9. SHOULD optimize transport of messages and minimize PB RTs

PB Requirements

1. Capable of carrying the decision and (if present) remediation instructions
2. Carry naming for collectors and validators (used for message delivery)
   Naming should allow for dynamic registration
3. Multiplex message dialogs between multiple collectors and validators
4. Capable of authentication, integrity and confidentiality of
   messages, decision and remediation instructions 
5. SHOULD support grouping of attributes to optimize messages/RTs

Kaushik Narayanan: The requirements I-D being presented just seems to
cover use cases with raw attributes. It does not capture requirements
for where rules are being transferred.
Paul: Yes. We need to include those requirements as part of the design
process.

PT Requirements
1. SHOULD incur low overhead for low bandwidth links

Kaushik: The low overhead requirement for PT has a cascading
requirement on PA and PB protocol requirements.
Paul: Yes. There are PA and PB efficiency requirements also.
Kaushik: And data needs to be compact.

2. SHOULD be capable of using a half duplex link
3. MUST NOT interpret the contents of PB messages
4. Capable of protecting the integrity and confidentiality of the PB
   messages

Yaron: Will PT requirements cover everything all the way down to the
IP layer?
Paul: No, we'll primarily capture the requirements of the transport
and not all layers below the PT.
Yaron: The Requirements I-D talks about EAP as the transport.
Steve: That's an historical artifact.

Kapil: The requirement for PT to protect PB messages and the
requirement for PT not to interpret PB messages seem to be in
conflict. If PT protects PB messages, we can't keep it from
interpreting them. And how would you test compliance with those
requirements, anyway?
Paul: These are requirements on the PT protocol. We wouldn't pick a PT
that requires poking around in PB messages.

5. Reliable delivery of PB messages (detect dups, fragmentation)
6. Capable of mutual authentication (possibly leveraging an
   authentication inside the protected tunnel)
7. Establish a restricted session between NAR and NAA prior to
   allowing general access
8. Allow for NAR/NAA session to be initiated from either party when
   both have assigned network addresses

Steve discussed next steps:

1) Solicit Design Team Members (through Nov. 16)
2) Start Design Team Weekly Concalls (probably week of Nov. 27)
3) First Requirements I-D Posted

Meeting adjourned at 5:17pm