Subject: [Nea] NEA WG meeting minutes at IETF 68

From: "Susan Thomson \(sethomso\)" <[email-masked]>
Date: Sun, 29 Apr 2007 16:45:26 -0400

Below are minutes of NEA WG meeting at IETF meeting in Prague. Let me know of any corrections by Friday, May 4.

Thanks
Susan
---------------------------------

Minutes from NEA WG Meeting
IETF 68 in Prague, Czech Republic
March 20, 2007, 1.00 PM - 3.00 PM
Chaired by Steve Hanna and Susan Thomson
Notes taken by Mani Mahalingam and Mauricio Sanchez
          
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.
          
The following draft agenda was agreed to:
          
1:00 Preliminaries
1:05 WG Status
1:10 Proposed Milestone Revisions
1:25 Discuss NEA Requirements draft
2:40 FWNA, Eduroam, and NEA
2:55 Next Steps
3:00 Adjourn

* WG Status *
Steve reviewed WG status. Two revisions of NEA requirements 
draft have been posted since IETF 67. Steve asked how many had
read either the -00 or -01 of the draft. A significant number of 
people raised their hand.

* Proposed Milestone Revisions *
Steve reviewed the updated milestones, a previous version of 
which had been distributed on the mailing list. He asked for a 
hum to determine support for the revisions. The hum demonstrated 
significant support for the revisions. There were no objections. The 
milestones will be confirmed on the mailing list before sending to the 
area director.

* NEA Requirements I-D *
Paul Sangster reviewed the -01 version of the NEA requirements I-D. 
He covered the following topics in the presentation in the meeting 
(please refer to the slides):
--- Reference Model
--- Attribute Types & Use Case examples
--- Open Issues 
 
Reference Model:

Paul reviewed the reference model agreed to at the IETF67 meeting. 
Steve asked whether there are any people in the room who do not 
understand what problem the NEA WG is trying to solve. Nobody 
raised their hand.

Attribute Types and Use Cases:

Paul presented three usage scenarios for NEA as the motivation 
for defining different attribute classes: 
(1) request/response for posture information 
(2) request for compliance to a given policy 
(3) allow for re-use of assertions from prior assessments. 

The requirements draft currently  defines different types of 
attributes to meet these usage scenarios. A NEA server may 
send 4 attribute types: request attributes, policy attributes, 
result attributes and remediation attributes. A NEA client may 
send posture attributes, compliance claim attributes and 
assertion attributes.

The requirements draft contains 5 use cases which are intended 
to illustrate usage of different attribute types. Paul presented 
the 5 use cases defined thus far.

Yaron Sheffer: The draft has classified many attributes, but 
it does not specify the semantic power of attributes. Are 
attributes similar to RADIUS attributes? Are they collections of 
attributes, rule-sets for policies, etc? It could become very 
complex.

Paul: The WG needs to specify the attributes in more detail 
in the protocol specs after completing the requirements document. 
The attributes may be more sophisticated than RADIUS attributes, 
because they may contain references to policies, for example.

Yaron: A clearer description of attributes is preferred. Specify 
something more than "what attributes can do", but less than 
"what attributes can look like".

Paul: This is a valid comment. For further discussion on mailing 
list.

Alan de Kok: Not clear that all these attribute types are necessary. 
For example, the compliance claim attribute.
 
Paul: The intent is to support the models previously described. 

Alan: No one knows how to transport policies well in protocol. 
Suggest not even try. Why would an administrator tell the client 
what the policies are since the administrator does not trust the client? 

Paul: The policy could be in the form of a URI or just some name, 
or some minimal indication of where the policies are.
 
Alan: How is asking for the version of AV different from asking 
for compliance to a specific policy? 

Steve: There was discussion on the mailing list that it was important 
that allowance be made for privacy-sensitive clients; hence the 
current attribute in the draft. We can take this requirements 
back to the mailing list to reconfirm.

Paul: This is another issue  that should be discussed further on 
the list. 

Alan: Why does the draft identify 3 different protocols? 
There is a need for one protocol with layers of proxying. 

Paul: It seems that the draft is saying the same thing, just 
using different words.

Leif Johannsen: The requirements I-D should explicitly state 
whether there is a need for a schema, or not. If so, do not 
invent a new one. 

Paul: The requirements draft does say that existing standards 
should be used where applicable. This comment is a similar one  
to the comment made earlier on attribute type definitions. 
This is another topic to be taken to the list.

Chairs: All WG participants are encouraged to send their comments 
to the alias. Do not make the editorial team the bottleneck for 
raising issues on the list for resolution.

Hannes Tschofenig: The draft includes a problem statement, use cases, 
architecture,trust-model as well as requirements. This was surprising 
given the document title. These topics are useful to have described, 
but at least change the title of the document. Also, the WG should 
have a chance to see some of the design team's discussions. 

Harald Alvestrand: Since the use of the term protocols for the three 
layers seems to be causing confusion, at least make the layering 
explicit. The term "prove" is asking for trouble. Another term should 
be used.

Open Issues:

Virtualization: 
Should virtualization be explicitly supported? This topic is not 
discussed in the current requirements draft.  Three options presented: 
no change (ignored), say it's out of scope, or be more explicit about 
virtualization models and how NEA supports it .

Alan de Kok: There should be a discussion on virtualization. The 
hypervisor is just a proxy to virtual clients.  There is no need 
for a change in the model.

Paul Sangster:  There are many virtualization models. One would 
not expect the NEA client to be part of virtualization layer. 
Paul asks whether hypervisor should be actively involved in 
NEA process, or just act as a pass-through. 

Alan: Depends on whether the endpoint appears to network as 
one machine or as N machines.

Tim Chown: What is the client identifier used to distinguish 
virtual machines? Need to identify these issues in the draft and 
specify explicitly that out of scope, not just ignore.

Paul Hoffman: Virtualization is analogous to a NAT box which 
has multiple endpoints behind it. To NEA server, it looks like 
a single endpoint. Thus, no change in model.

NEA client on non-endpoint:

Should the draft  recognize a device that acts as a NEA client 
for the endpoints behind it that do not have an NEA client? 
The device may be an intrusion detection system or intrusion protection 
system, for example.

Alan de Kok: May be useful to talk about the specific case of NAT 
or FW acting on behalf of the endpoints they allow into the network. 

Mauricio Sanchez: Does this use case imply any changes to the protocol 
requirements? 

Paul: No changes foreseen to the requirements themselves. It changes 
some of the normative text.

Mauricio Sanchez: It is better to focus on use cases that impact the 
requirements. 

Tim Chown: It would be useful to have some discussion on how the 
communication between IDS, NEA server and firewall works and how 
these devices get configured in this use case, but agree 
do not want to be too distracted by this. Is it possible to have 
multiple NEA servers in a domain?  

Paul Sangster: Yes, there could be multiple NEA servers

Steve: How the NEA server communicates with an enforcement point 
is explicitly out of scope per the charter.

Bob Morgan: This should be a supported option in the model. 
It does have an impact on protocol requirements because the protocol 
needs to ask about endpoint X even though talking to client Y.

Paul Sangster: NEA server does create awkwardness in model, and 
agrees it will add attributes to the protocol requirements.

Steve: Our AD needs to assess if this use case is within the 
scope of the charter. 

Tim Polk: The WG should continue to discuss the use case to 
better understand if this scenario falls within the scope of an 
endpoint as used in the charter. Depending on the 
outcome of this investigation,  we may have to slate this for future work.

Alan: NEA use cases need to take into account enforcement. 

Steve: Enforcement is present in the model but out of scope for WG.

Tim Polk: The charter states that enforcement is not mandatory. 

Paul Hoffman: Suggests that we ignore this use case. It could be 
an extension of the existing reference model.

Security at all layers:

The requirements document currently specifies authentication, 
confidentiality and integrity requirements for all 3 layers. 
Requirements for PA & PT are currently listed as a MUST, 
while PB is a SHOULD. These requirements are intended to cater for 
cases where all client or server components may not be co-resident. 

Steve: Alternately, NEA could use hop-hop protection with remote 
validators on the NEA server.

Paul: Yes. However, this does not support authentication of a 
posture collector to a posture validator or vice versa

Hao Zhou: Why is there a need for protection on PA layer? Its possible 
for components at this layer to define their own since they typically 
come from the same vendor.

Paul: Possible to do vendor-specific security, but the advantage is that 
there is a standard one that allows for interoperability.

Paul: PB security is expected to be needed least as PT and PB 
components typically are co-resident.

Mauricio Sanchez: Proposes making PB a MAY.

Privacy considerations (Section 9.2 )
Paul said that intent of the current text in Section 9.2 is to be 
a starting point for discussion. The text was motivated by an earlier 
thread on the mailing list regarding privacy concerns with use of NEA. 

Paul described that, for privacy reasons, a client may have a policy 
regarding what information to disclose. Possible models are:
--- Client sends all attributes by default 
--- Client has local policy regarding what attributes to send
--- Client can respond to requests based on local policy. Server can 
iteratively request attributes  (factoring in responses to previous 
requests).

Richard Graveman: How do I know if a NEA server is legitimate?

Paul: Through strong authentication of the NEA server. Trust 
anchors are pre-configured.

Paul Hoffman: We just got into a policy rat-hole. One side should 
pick policy. The expectation is that this would be the server. 
If server asks for posture attributes, the client either responds or not. 
This is an option with any protocol. Need not specify in the requirements 
draft. 

Yaron: I think there should be some discussion in the draft, probably 
in an appendix in reduced form as implementation advice. The 3rd policy 
option mentioned in the draft is overkill, however. The client need 
not disclose information at the risk of not being allowed 
onto network.

Hannes: There are more complex privacy considerations in the  roaming 
scenario, where there is a difference between the  access network 
and home network. 

Steve: The roaming use case is explicitly excluded from the charter 
and is out of scope.

Other issues on current draft?
Paul Hoffman: The requirements document currently lacks discussion 
of how remediation works and what happens afterwards.  For example, 
an endpoint may be given restricted access for the purposes of 
remediation after which posture may need to be revalidated.

Paul: Remediation is out of scope of the charter. 

Paul, others: The draft needs to describe that remediation could happen, not 
how it happens.

Tim Chown: Should specify the quarantine phase in an example 
(while not describing quarantine enforcement itself) 

Leif Johansson (FWNA/EDUROAM): 
There was a short presentation on use of federated 802.1x in 
FWNA/eduroam deployments, and how it may be impacted by NEA. 
In these deployments, the network provider (foreign provider) and 
the identity provider (home provider) are different organizations 
when a host roams. If the same model is used when performing posture 
assessment, some method of communication is needed between the network 
and posture provider. 

While it is clear that support for such networks is outside the 
current NEA charter, the presenters' intent was to  raise awareness of 
potential issues in an attempt to avoid problems with supporting 
such deployments in the future. 

Several proposals for resolving the issues without affecting NEA were 
suggested including (1) proxying (2) providing foreign network provider 
with a  reference to the posture results and (3) separating authentication 
and posture assessment.

Wrap-up:
Steve discussed the next steps:
--- Confirm revised milestones on mailing list
--- Discuss open issues on mailing list
--- Revise NEA requirements I-D 
--- Further discussion on list 
--- Revise NEA requirements I-D based on discussions
--- WGLC in June

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