Subject: [Nea] Posted draft minutes from IETF 69 NEA meeting

From: "Stephen Hanna" <[email-masked]>
Date: Wed, 15 Aug 2007 15:31:39 -0400

I have posted draft minutes from the IETF 69 NEA WG
meeting on the IETF 69 meeting materials web site.
For your convenience, I have also copied them below.

Please review these minutes. If you find any errors
or omissions, please send email to the list. The
deadline for correcting these minutes is September 12
so please send corrections to the list by end of day
on September 11 so I have time to make the corrections.

Thanks,

Steve

-----------

Minutes from NEA WG Meeting
IETF 69 in Chicago, IL
July 23, 2007, 1:00 PM - 3:00 PM
Chaired by Steve Hanna and Susan Thomson
Notes taken by Mani Mahalingam and Joe Tardo

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 and Susan called the meeting to order at 1:04 PM and 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:

1:00 Administrivia
      Blue Sheets
      Jabber & Minutes Scribes
      Agenda Bashing
1:05 WG Status
1:10 Discuss NEA Requirements Draft
  http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-03.txt
2:55 Review of Next Steps
3:00 Adjourn

*WG Status*

Steve reviewed the current status of the Working Group.
Our requirements document is in Working Group Last Call.
Please review it and sent comments to the list.

Steve asked for a show of hands from those who have read
some version of the requirements document and another show
of hands from those who have read the latest version (-03).
A good number of people raised their hands for both.

Steve explained that our next steps are:

* Finish WGLC on NEA Requirements I-D
* Revise NEA Requirements I-D
* Another WGLC if major changes made
* Submit NEA Reqs I-D to IESG for IETF LC and approval
  as Informational RFC
* Revise milestones to start work on PA & PB

Tim Polk (our AD) agreed.

Paul Hoffman: When will the rechartering start?
Tim Polk: We should start work on that when IETF LC completes
so that it can be approved when or shortly after the time when
the IESG approves the requirements document.
Steve Hanna: I hope we'll only need to change milestones
not do a real rechartering.
Tim Polk: If that's true, it will be easy.

Hannes Tschofenig: The mailing list has been quiet, which
means the document has not received much review. You need
more review, especially since this document has more than
just requirements.
Tim Polk: Agreed. I'm going to recruit more reviewers.
We were waiting until the document was solid.

Steve Hanna: Could I see a show of hands from people who
are willing to review the document? Got seven volunteers.
Hannes: Write down people's names so you can bug them!
Here are the names of the volunteers: Hao Zhou, Nancy Winget,
Alan Breese, Alan DeKok, Joe Salowey, Mauricio Sanchez,
and Hannes Tschofenig.

Steve reviewed the NEA Reference Model and reminded people
of the WG's scope: endpoint assessment and in particular
agreeing on standard PA, PB, and PT protocols.

*NEA Requirements*

Kaushik Narayan started reviewing the latest NEA requirements
document. He reviewed the changes made in the -02 and -03 drafts.
See his slides for details.

Kaushik raised some issues for discussion.

1) The current draft contains informative text that touches
   upon a few aspects of protocol design at a high level to
   provide guidance but does not impose requirements. Should
   this text be retained?

Paul Hoffman: It's good to have this text as long as you
make it VERY clear that this text is informative.
Kaushik Narayan: We've tried to do that.
Steve Hanna: Is it true that the only normative text is in
the Requirements section?
Kaushik Narayan: Yes.
Steve Hanna: Maybe we should say that somewhere.
Paul Sangster: We do.
Susan Thomson: We must make sure this is clear and not confusing.
Steve Hanna: Maybe we should place at the beginning of each
section a reminder that all normative text is in the Requirements
section.
Susan Thomson: We should also avoid having too much informative text.
Paul Sangster: I think we should just change the title for the
Requirements section to say "ONLY NORMATIVE TEXT".
Steve Hanna: That wouldn't address my concern sufficiently.
Kaushik Narayan: Let's take this to the list.

2) Requirement PB-3 seems redundant in light of requirement C-1.
In fact, the requirement for supporting multiple messages can
be met by the PT layer or the PB layer so this requirement is
going into protocol design. Should we remove requirement PB-3?

There were no comments on this topic at the meeting.

Kaushik Narayan: The Design Team has decided we'd like to remove
requirement PB-3. If there are no other comments, we'll do so.

3) The Privacy Considerations section includes implementation
guidelines. We haven't received much input on this section.
Is it adequate? Too much? Not enough? Needs to be changed?

Mauricio Sanchez: I think the document is going in the right
direction and has the right level of detail.
Steve Hanna: Are there privacy experts we should consult?
Tim Polk: I'll look into that.
Kaushik Narayan: And we'll take this to the list.

Kaushik Narayan: OK. That's the last of the open issues we wanted
to discuss today. But we thought it would be productive to review
every one of the requirements in the draft now and see if anyone
has any concerns or issues with them.

Kaushik ran through the requirements, starting with C-1.
The text here is taken from Kaushik's slides.

C-1 Capable of multi-message dialog

Hao Zhou: You mean multiple round trips?
Kaushik Narayan: That's right. This is clear in the actual
requirement text. I'm sorry the summary on the slide is
ambiguous.

C-2 Allow assessment prior and after normal network access
C-3 Enable re-assessment by either client or server

Paul Hoffman: What's the difference between C-2 and C-3?
Kaushik Narayan: C-3 is about triggering. It's saying that
either the client or server should be able to trigger a
reassessment.
Alan Breese: So C-2 is about initial assessment and C-3
is about reassessment?
Kaushik Narayan: Actually, C-2 includes both initial assessment
and reassessment. C-3 says either party can trigger reassessment.

C-4 Protection against active/passive attacks by intermediaries
C-5 PA and PB transport agnostic interfaces
C-6 Selection process prefer reuse of existing open standards
C-7 Scalable (many collectors and validators on multiple servers)
C-8 Efficient transport of many Attributes
C-9 Large numbers of compliance policies
C-10 Allow for Assessment with reduced amount of information exchanged

Alan DeKok: For C-8, if the server caches the results of previous
assessments, later assessments can be quick since they can just
send what has changed. For C-9, I'm not sure there's any way
around that. If you don't comply, you may need to download a
lot of data to come into compliance.
Kaushik Narayan: For C-9, we'd just be looking for ways to make
the data transmitted for assessment as small as possible.
Alan DeKok: The only way we know to express complex policies is
running code. So I'm not sure I agree with C-9. You can push down
the policies during remediation along with patches, not during
assessment. Then assessment will be much faster.
Kaushik Narayan: We removed the idea of policy attributes so
policies will no longer be pushed down during assessment.

PA-1 Support transport standard Attributes
PA-2 Support transport of vendor-specific Attributes
PA-3 Enable validator to request Posture and Assertion Attributes
     from client's Collector
PA-4 Allow for multiple requests for posture information within
     a single assessment.
PA-5 Carry validator results and remediation instructions
PA-6 Capable of authentication, integrity and confidentiality
     of Attributes
PA-7 Capable of carrying Attributes including binary data
PA-8 String Attributes being encoded with an encoding standard
     that supports internationalization. 

PB-1 Capable of carrying the decision and (if present) remediation
     instructions
PB-2 Carry naming for collectors and validators (used for message
     delivery). Naming should allow for dynamic registration.
PB-3 MAY be capable of authentication, integrity and confidentiality
     of messages, decision and remediation instructions
PB-4 Support grouping of attributes to optimize messages per roundtrip

PT-1 SHOULD incur low overhead for low bandwidth links
PT-2 SHOULD be capable of using a half duplex link
PT-3 MUST NOT interpret the contents of PB messages
PT-4 Capable of protecting the integrity and confidentiality of
     the PB messages
PT-5 Reliable delivery of PB messages (detect dups, fragmentation)
PT-6 Capable of mutual authentication (possibly leveraging an
     authentication inside the protected tunnel.)

An open mike session was next.

Alan DeKok: Overall, much clearer than the previous versions.
I'd still like to emphasize clarity and simplicity. I have
sent some comments to the list and will send some more. In
Section 5, every other word is "posture". At that point,
it doesn't mean anything. Just take it out.

There were no other comments.

Steve Hanna: Please review the current draft, which is
draft-ietf-nea-requirements-03.txt. It's in WGLC, which
closes August 10. Send comments on the document to the list.

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

---

From: "todd glassey" <[email-masked]>
Date: Wed, 15 Aug 2007 13:26:50 -0700

comments on the NEA Requirements Draft:

1)    in the opening paragraph, NEA is more a tool for 'remote management of 
networks and their infrastructure' than a VPN tool. I think the line in the 
opening paragraph which reads:

(e.g. an enterprise offering remote access)

should be changed to notice that the intent behind NEA is not a VPN 
enablement, but a remote hands-off management tool for system.

2) in the SCOPE segment - these two changes to the scope statement are to be 
cleaner.

 a) PA and PB will be designed to be carried over a variety of lower layer 
transport (PT) protocols.

Should read something like:

    NEA components are designed to be transport layer independant (TLI), and 
so they will work with a number of different transport layers.

 b) protocols are intended to allow interoperability between an NEA
    Client from one vendor and an NEA Server from another.

Should read something like:

    protocols implemeted on standardized network transports like IP are 
intended to allow complete interoperability between NEA components from 
different vendors or sources.

    c) What I am also concerned for is that without the ability to detect 
lying endpoints that there is no real security available here. That said I 
strongly suggest that this requirement be added back into scope and if not 
considered in the first round only deferred to the second round. Its 
important...

3)    In section 3.2

    Conversely, some environments where NEA is not expected to be
    applicable would be environments where the endpoint is owned by
    a user that has not agreed to conform to a network provider's
    policies.  An example might include when the above contractor
    visits any public area like the local coffee shop which offers
    Internet access.  This coffee shop would not be expected to be
    able to use NEA technologies to assess the posture of the
    contractor's laptop.  Because of the potentially invasive nature
    of NEA technology, such an assessment could amount to an
    invasion of privacy of the contractor.

The problem is that NEA could easily become a valuable system for places 
that operate Hidden Gardens and the like as controlled Internet Hotspots. 
For instance the Denny's across the street from a client's place in 
Sunnyvale has a new 'access enablement webpage and agreement process' that 
has to be setup for their proxy to work. NEA would be a tremendously 
valuable tool to have to allow those proxies to be able to check the local 
mobile computing nodes for proper configuration of their firewall's for 
instance, or their patches. The value here is as a tool to limit liability 
from collateral damages based on some twirp hacking your laptop while your 
sitting in Denny's per se.

That said I think that NEA is exactly what those coffee shops need in the 
form of an embedded NEA server built into the WAP itself.

4)    Section 4 ...

    NEA technology may be used for several purposes.  One use is to
    facilitate endpoint compliance checking against an
    organization's security policy when an endpoint connects to the
    network.  Organizations often require endpoints to run an IT-
    specified OS configuration and have certain security
    applications enabled, e.g. anti-virus software, host intrusion
    detection/prevention systems, personal firewalls, and patch
    management software.  An endpoint that is not compliant with IT
    policy may be vulnerable to a number of known threats that might
    exist on the network.

One of the big problems network operators have is with rogue systems which 
are placed on a network by individuals who are running them in modes not 
compliant to the network's operatio's policy. That has any number of 
meanings including that the system is infested with something, 
mis-configured, or is mascarading as something it isnt. Also there are those 
instances where NON-NEA devices or systems may be placed on a network and 
that also must be dealt with.

snip

    Re-assessment is an important part of NEA technology as it
    allows for additional assessments of previously considered
    compliant endpoints to be performed.  This might become
    necessary because network compliance policies and/or endpoint
    posture can change over time.

or that the systems configuration of those nodes under NEA management could 
also change or be changed by patches, human error, hacking, or other attack 
processes.

    A system initially assessed as
    being compliant when it joined the network may no longer be in
    compliance after changes occur.

You mean Periodic Recertification... the process of running the NEA 
"Client/Node Admittance" (CNA)certification process continuously or on a 
periodic basis.

    For example, re-assessment
    might be necessary if a user disables a security protection
    (e.g. host firewall) required by policy or when the firewall
    becomes non-compliant after a firewall patch is issued and
    network policy is changed to require the patch.

This also feeds back into the idea that NEA is supposed to continuously tell 
us that all the systems connected to the entity's networks are configured 
properly and are not running evil things. So... say that.

SNIP

5)    The Refernece Model (5.0)

...

    The NEA Reference model does not include mechanisms for discovery
    of NEA Clients and NEA Servers.  It is expected that NEA Clients
    and NEA Servers are configured with information that allows them to
    reach each other.  The specific methods of referencing the
    configuration and establishing the communication channel are out of
    scope for the NEA Reference Model and should be covered in the
    specifications of candidate protocols for the Posture Transport
    (PT) protocol.

OK so can we change this to say "does not at this time include mechanisms 
for discovery" so we dont eliminate that as as feature. Its a powerful one.

And can I ask... Isnt the  Posture Transport Client really a reconfigurable 
NEA proxy? If so can we call it that?

6)    5.1.1

    The NEA Client is responsible for responding to requests for
    attributes describing the configuration of the local operating
    domain of the client and handling the assessment results
    including potential remediation instructions for how to conform
    to policy.  An NEA Client is not responsible for reporting on
    posture of entities that might exist on the endpoint or over the
    network that are outside the scope/visibility of the NEA Client.

    For example a NAT device might route communications for many
    systems behind it, but when the NAT device is joining the
    network its NEA Client would only report its own (local)
    posture.  Similarly, endpoints with virtualization capabilities
    might have multiple independent domains of execution (e.g. OS
    instances).

Should read:

    The NEA Client is responsible for responding to requests for
    attributes describing the configuration of the local operating
    domain of the client and handling the assessment results
    including potential remediation instructions for how to conform
    to policy.

An NEA Client is not responsible for reporting on posture of entities that 
might exist on the endpoint or over the network that are outside the 
scope/visibility of the NEA Client.  For example a NAT device might route 
communications for many systems behind it, but when the NAT device is 
joining the network its NEA Client would only report its own (local) 
posture.

    Similarly, endpoints with virtualization capabilities
    might have multiple independent domains of execution (e.g. OS
    instances).

blah blah blah...

- I will go through sections 5 and 6 later tonight and send them in too..

Todd

----- Original Message ----- 
From: "Stephen Hanna" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, August 15, 2007 12:31 PM
Subject: [Nea] Posted draft minutes from IETF 69 NEA meeting

Thanks,

Steve

-----------

1:00 Administrivia
      Blue Sheets
      Jabber & Minutes Scribes
      Agenda Bashing
1:05 WG Status

*WG Status*

*NEA Requirements*

---

From: "Paul Sangster" <[email-masked]>
Date: Wed, 15 Aug 2007 17:57:33 -0700

The minutes are a good reminder that we had hoped to take a couple
topics to the mailing list.  The design team raised the following
question in Chicago:

"3) The Privacy Considerations section includes implementation
guidelines. We haven't received much input on this section.
Is it adequate? Too much? Not enough? Needs to be changed?"

There was not a lot of discussion about this during the meeting beside
an initial show of support for section 9's direction.  We would
appreciate feedback on this section particularly whether the
implementation guidance is helpful or whether it should be scaled back.
In particular what should we do with section 9.2 discussing Minimal
Attribute Disclosure.  Comments welcome.

In Chicago we also discussed whether and how to make it more clear that
most of the document is informative and that only section 7
(requirements) are normative.  In response to this discussion we added
text in section 1 making this clear and then augmented the title of
section to "Requirements (Only Normative Section)" and added text to the
initial paragraph.  Hopefully this is sufficient.

Paul

> -----Original Message-----
> From: Stephen Hanna [mailto:[email-masked]] 
> Sent: Wednesday, August 15, 2007 12:32 PM
> To: [email-masked]
> I have posted draft minutes from the IETF 69 NEA WG meeting 
> on the IETF 69 meeting materials web site.
> Please review these minutes. If you find any errors or 
> omissions, please send email to the list. The deadline for 
> correcting these minutes is September 12 so please send 
> corrections to the list by end of day on September 11 so I 
> have time to make the corrections.
> 
> Thanks,
> 
> Steve
> 
> -----------
> 
> Chaired by Steve Hanna and Susan Thomson Notes taken by Mani 
> Mahalingam and Joe Tardo
> 
> 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 and Susan called the meeting to order at 1:04 PM and 
> 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:
> 
> 1:00 Administrivia
>       Blue Sheets
>       Jabber & Minutes Scribes
>       Agenda Bashing
> 1:05 WG Status
> Steve asked for a show of hands from those who have read some 
> version of the requirements document and another show of 
> hands from those who have read the latest version (-03).
> so that it can be approved when or shortly after the time 
> when the IESG approves the requirements document.
> Steve Hanna: I hope we'll only need to change milestones not 
> do a real rechartering.
> Steve Hanna: Could I see a show of hands from people who are 
> willing to review the document? Got seven volunteers.
> Alan Breese, Alan DeKok, Joe Salowey, Mauricio Sanchez, and 
> Hannes Tschofenig.
> 
> Steve reviewed the NEA Reference Model and reminded people of 
> the WG's scope: endpoint assessment and in particular 
> Paul Hoffman: It's good to have this text as long as you make 
> it VERY clear that this text is informative.
> section a reminder that all normative text is in the 
> Requirements section.
> Paul Sangster: I think we should just change the title for 
> the Requirements section to say "ONLY NORMATIVE TEXT".
> Kaushik Narayan: The Design Team has decided we'd like to 
> remove requirement PB-3. If there are no other comments, we'll do so.
> 
> Kaushik Narayan: OK. That's the last of the open issues we 
> wanted to discuss today. But we thought it would be 
> productive to review every one of the requirements in the 
> draft now and see if anyone has any concerns or issues with them.
> 
> requirement text. I'm sorry the summary on the slide is ambiguous.
> 
> either the client or server should be able to trigger a reassessment.
> Alan Breese: So C-2 is about initial assessment and C-3 is 
> about reassessment?
> Kaushik Narayan: Actually, C-2 includes both initial 
> assessment and reassessment. C-3 says either party can 
> trigger reassessment.
> 
> C-9 Large numbers of compliance policies C-10 Allow for 
> Assessment with reduced amount of information exchanged
> 
> Alan DeKok: For C-8, if the server caches the results of 
> previous assessments, later assessments can be quick since 
> they can just send what has changed. For C-9, I'm not sure 
> there's any way around that. If you don't comply, you may 
> need to download a lot of data to come into compliance.
> Kaushik Narayan: For C-9, we'd just be looking for ways to 
> make the data transmitted for assessment as small as possible.
> Alan DeKok: The only way we know to express complex policies 
> is running code. So I'm not sure I agree with C-9. You can 
> push down the policies during remediation along with patches, 
> not during assessment. Then assessment will be much faster.
> Section 5, every other word is "posture". At that point, it 
> doesn't mean anything. Just take it out.
>