Subject: [Nea] IETF67 NEA WG Meeting summary

From: "Susan Thomson \(sethomso\)" <[email-masked]>
Date: Thu, 9 Nov 2006 13:32:00 -0500

NEA WG Meeting Summary 
Tuesday Nov 7 15.20-17.20

1. Discuss formation of NEA WG Requirements I-D

The first milestone of the WG is formation of the requirements I-D. To
this end, the contents that need to be covered in the Requirements I-D
were reviewed along with the proposed reference model.  Several use
cases were introduced with the goal of driving protocol requirements.  

The WG also reviewed an individual submission on NEA requirements that
had been submitted prior to chartering of the WG. Some material in this
document may be used as a start for the WG document with appropriate
changes to reflect the approved charter.

2. Next Steps:

WG chairs to send call for requirements I-D "design team" volunteers  to
mailing list (done)
Volunteers to send names to WG chairs by Nov 16
WG chairs to select design team by Nov 22
Design team to start con calls week of Nov 27
Post first draft of requirements I-D 

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

---

From: Khaja Ahmed <[email-masked]>
Date: Thu, 9 Nov 2006 10:53:54 -0800

To reiterate a point I made in the meeting, and to prompt some
discussion on it...

I am not sure what the value is of restricting the charter to solving
the problem for enterprises only.  The internet includes home networks.
Why leave them out?  In fact, as the 'Internet' engineering task force,
we should ensure that all of the internet can benefit from whatever
protocols / solutions we design.  

I recommend that we add a home user scenario as well.  

Having discussed this with ISPs like Verizon, SBC, etc, they want to
provide nea as a value-add, optional, service to consumers.  Consumers
benefit, the internet benefits and I suspect the enterprise benefit.  It
doesn't help to ensure that the enterprise networks are healthy if the
internet is slammed because of larger numbers of home users have poorly
managed / administered systems.  

It may be the case what works for enterprises will happen to work for
home users getting such services from ISPs but I'd prefer that we make
it easier to accomplish this by making it an explicit goal.  

Khaja

-----Original Message-----
From: Susan Thomson (sethomso) [mailto:[email-masked]] 
Sent: Thursday, November 09, 2006 10:32 AM
To: Russ Housley; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Nea] IETF67 NEA WG Meeting summary 

NEA WG Meeting Summary 

2. Next Steps:

---

From: Sam Hartman <[email-masked]>
Date: Thu, 09 Nov 2006 16:12:15 -0500

>>>>> "Khaja" == Khaja Ahmed <[email-masked]> writes:

    Khaja> To reiterate a point I made in the meeting, and to prompt
    Khaja> some discussion on it...

    Khaja> I am not sure what the value is of restricting the charter
    Khaja> to solving the problem for enterprises only.  The internet
    Khaja> includes home networks.  Why leave them out?  In fact, as
    Khaja> the 'Internet' engineering task force, we should ensure
    Khaja> that all of the internet can benefit from whatever
    Khaja> protocols / solutions we design.

It seems rather early in the nea working group to be discussing
rechartering.

---

From: "Stephen Hanna" <[email-masked]>
Date: Thu, 9 Nov 2006 16:21:45 -0500

Agreed. We have an approved charter. That charter explicitly restricts
our scope to enterprise environments. There was a lot of discussion on
this topic during the chartering of the WG just a few weeks ago. We
should
not revisit this now. We should focus on our first milestones and work
on
developing the NEA Requirements I-D. So I'm going to rule further
discussion
of this topic on the NEA list out of scope at this time.

Thanks,

Steve

---

From: Khaja Ahmed <[email-masked]>
Date: Fri, 10 Nov 2006 12:02:51 -0800

OK. As we go into the work of defining the actual protocol if we feel
that the solutions is hobbled because of the charter we can reconsider
then.  I am fine with wait and see if is necessary.

I do have a question for the ADs: In your experience is it better to
revise charter later in the game, when there is a tangible evidence that
the limits of the charter are causing design decisions that are
sub-optimal?  ...or it better to do it early in the game when not too
much has been done and we are starting on a relatively clean slate?  I
am hoping it is the former - that is why I am agreeable to the wait and
see if necessary approach, but I'd like to know.  

Khaja

-----Original Message-----
From: Stephen Hanna [mailto:[email-masked]] 
Sent: Thursday, November 09, 2006 1:22 PM
To: Sam Hartman; Khaja Ahmed
Cc: [email-masked]
Subject: RE: [Nea] IETF67 NEA WG Meeting summary

Thanks,

Steve

---

From: Russ Housley <[email-masked]>
Date: Mon, 13 Nov 2006 15:59:03 -0500

At this point, only bad things can happen by asking for a charter revision.

In my opinion, you need to deliver on the existing charter milestones 
before asking for any additional latitude.

Russ

---

From: Keith Moore <[email-masked]>
Date: Mon, 13 Nov 2006 16:53:16 -0500

> before asking for any additional latitude.

my opinion is somewhat stronger than that.  IMHO, you're going to need 
to resolve the conflict between the user's desire for privacy and the 
network operator's desire to spy on end systems, before you can 
accomplish much in this area.  depending on how you interpret the 
charter, that might or might not fit, but I think it would be reasonable 
to do this work as part of developing requirements and security 
considerations.  (however, I don't claim to be able to interpret the 
charter authoritatively, that's up to the ADs.)  if it can't take place 
as part of this WG's discussion, so be it, but it needs to be done 
somehow regardless.

for lots of reasons, it's not sufficient to say that this technology is 
only for use by enterprise networks where they own all of the computers 
that attach to them.  one reason is that this is an increasingly small 
corner case, as very many employees and visitors need to attach to 
enterprise networks.  another is that there are too many incentives for 
other kinds of networks to spy on end systems and to demand the ability 
to do so if the tools become commonly available.

I honestly don't see why this work is any different in principle than 
wiretapping, and why RFC 1984 doesn't apply here to some extent.  leaf 
networks aren't inherently more benign than governments.

Keith

p.s. I think it might actually be possible to resolve this conflict, 
though I can't quite see how to do it.  Offhand the best idea I have 
looks something like this:

- networks cannot query hosts for fine-grained attributes.  instead, 
networks can advertise their policies in detail.  the most that the 
network gets back when querying a host is a yes (does conform), no (does 
not conform), or "no answer" (not willing to tell you whether it conforms).

- hosts report any details of policy conflicts to their owners, 
according to the software configuration.  hosts must not report any 
details in response to the query by the network.  it should be up to the 
owner to take corrective action.  of course, the owner might be the same 
as the network administrator, but then again, it might not be.

- the protocol limits the frequency with which policies can be changed 
and policy queries can be made, to prevent this being used as a probing 
mechanism to find out details of the host's configuration.  either that 
or the protocol specification has other mechanisms to limit the ability 
of the network to use the protocol to probe host configuration.

- predicates that are part of network-specified policies probably do 
have to be standardized.  either that or the network has to be able to 
specify separate policies for each NEA host software package, which 
pretty much defeats the purpose of standardization.

- it should be possible for a host to reconfigure itself to suit the 
whims of the network to which it attaches.  so rather than saying "I 
don't conform to your policy" because it has software X installed, it 
should be able to say "I do conform to your policy" as long as software 
X is not part of the virtual host image that talks to that network 
interface.

Like I say, this is a rough idea, thrown out in the hope that it can be 
improved on rather than shot down.  It's easy to shoot things down, 
harder to take a rough idea and make it a good one.  Of course if it's 
totally unworkable it does need to be shot down.  But offhand it looks 
more promising as a path to a compromise than saying (for instance) 
"hosts can lie".

Keith

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 13 Nov 2006 17:05:43 -0500

> networks aren't inherently more benign than governments.

  Pretty much, yes.

> looks something like this:

  I think there are many ways to approach the NEA requirements without
implementing the full set of NEA protocols on all of the NEA actors.
Since we assume that pretty much anything can be spoofed or
duplicated, many of the attacks on non-intrusive posture assesment
methods are also applicable to NEA.  And those non-intrusive methods
can be implemented using existing software, without requiring new
protocols.

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog

---

From: Keith Moore <[email-masked]>
Date: Tue, 14 Nov 2006 01:16:19 -0500

> can be implemented using existing software, without requiring new

to me NEA seems pointless unless the responses are signed.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 13 Nov 2006 22:36:44 -0800

> to me NEA seems pointless unless the responses are signed.

The responses could be certificates signed by a third-party service.
The affirmative answer would be a time-stamp of the service event still
considered valid by the server.  This service might have a certificate
exchange layer wrapped around an update mechanism, for example.

The NEA server could indicate required services by exchanging sets of
certificates using a hostmaster identifier.  The client would need to
offer one certificate with their identifier for each set.  There could
also be a set of optional services, that the client may wish to make use
of when recommended by their provider.

Each certificate would indicate the provider of the service and the
required resources needed for the service.  This resource information
could enable the relaxation of network rules designed to protect both
the client and the network itself.

-Doug

---

From: Keith Moore <[email-masked]>
Date: Tue, 14 Nov 2006 01:42:48 -0500

> exchange layer wrapped around an update mechanism, for example.

the third-party service is an interesting idea if it can be used to hide 
details of my configuration from the network while still certifying to 
the network that my configuration is (within broad terms) okay.  still, 
I'm not sure I'd trust any third-party to know precisely what is on my 
machine and not misuse that information or disclose it to parties with 
whom I don't want to share it.  I'm certain that I wouldn't trust an 
antivirus software vendor, for instance, with that information - because 
widespread investment of this kind of trust in a few such vendors would 
make them very tempting targets for some kinds of espionage.

> offer one certificate with their identifier for each set.

this seems too intrusive to me.  I don't want a network to know 
precisely which services I have installed on my machine.

Keith

---

From: "Darryl \(Dassa\) Lynch" <[email-masked]>
Date: Tue, 14 Nov 2006 17:58:07 +1100

Keith Moore wrote:
>>> The affirmative answer would be a time-stamp of the service event
>>> still considered valid by the server.  This service might have a
>>> certificate exchange layer wrapped around an update mechanism, for
>>> example. 
>> 
>> the third-party service is an interesting idea if it can be
>> used to hide details of my configuration from the network
>> while still certifying to the network that my configuration
>> is (within broad terms) okay.  still, I'm not sure I'd trust
>> any third-party to know precisely what is on my machine and
>> not misuse that information or disclose it to parties with
>> whom I don't want to share it.  I'm certain that I wouldn't
>> trust an antivirus software vendor, for instance, with that
>> information - because widespread investment of this kind of
>> trust in a few such vendors would make them very tempting
>> targets for some kinds of espionage.
>> 
>>> The NEA server could indicate required services by exchanging sets
>>> of certificates using a hostmaster identifier.  The client would
>>> need to offer one certificate with their identifier for each set.
>> 
>> this seems too intrusive to me.  I don't want a network to
>> know precisely which services I have installed on my machine.

Couldn't the solution be as simple as allowing the client nodes the option
of deciding what information they are prepared to make available and the
network then using what is available to decide how they should be treated?
If not enough information is provided the node can be shunted off for some
form of remediation, if the network deems it has enough information then the
node can be allowed in.

Both parties have choices then, what information to provide and what is
required to be accepted.  

Darryl (Dassa) Lynch