Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea)

From: "Darryl \(Dassa\) Lynch" <[email-masked]>
Date: Mon, 9 Oct 2006 19:48:40 +1000

Brian E Carpenter wrote:
>>>>> This is what I meant when I said that the charter is unclear and
>>>>> it must explicitly state that NEA is not meant as a protection
>>>>> mechanism of any sort for the network.
>>> 
>>> 
>>> I don't believe the Charter needs to delve into this at all.  If
>>> some people see it as part of their protection mechanisms, so be it.
>>> 
>>> Darryl (Dassa) Lynch
>> 
>> The IETF has an obligation to "truth in advertising" so IMHO
>> we should not claim protection that doesn't exist, even implicitly.

I can't see anywhere in the charter where it is implied NEA is a protection
mechanism.  That doesn't mean the use of NEA can not be a part of an overall
strategy to improve security on a network or on endpoints.  NEA is not
itself a protection mechanism but it may be used to assist in creating some
protection mechanisms.  Much like TCP/IP can be used to build a network but
is itself not a network.

For instance, if I have a network with the policy that only a small number
of anti-virus products are trusted and the products must be version X with
data files of at least version Y, an endpoint with a product C will not be
allowed on the network.  If NEA can be used to automatically check this
policy is complied with at the endpoints before they are given full access
then I consider NEA has been used as part of the security strategy.  

My understanding is this is already achieved with some vendor specific
systems.

Another side of the issue is NEA may be used to ensure a financial package
is installed and has all the applicable patches installed before it is
allowed to connect into the main database, which would be of assistance to
maintain data integrity.

To me NEA is just a means to have compatible standard communications.  The
full use of the communications data is really beyond the scope of the WG.

Darryl (Dassa) Lynch 

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

---

From: Ted Hardie <[email-masked]>
Date: Sun, 8 Oct 2006 23:45:37 -0700

I have a very basic fear that this working group is getting chartered
with a bunch of aims added by people who will not take on the
task of doing the work.  After private discussion with folks
involved, my sense is that the very core of this work is a perceived 
need to be able to pass opaque strings between a host and the network 
prior to the host attaching.  Those opaque strings are, essentially,
the vendor-specific strings currently associated with posture assessment.
The standard protocol carrying these strings would connect on the network
side to a system that has plug-ins which understand the vendor-specific
strings.  

With a charter that clarified that this was intended to assist the end
systems with vulnerabilities prior to attachment because the
network they are attaching to might be filled with danger, I 
think this work would get done reasonably quickly. (As a control
mechanism to protect the network, I agree with the point made
clearly by others that this is not appropriate).

I am less sure of the task of standardizing attributes.

I am not sure that the number of attributes which can be standardized
will ever be high enough to be truly useful, and I am pretty sure
that all of these will be already covered by vendor-specific attributes.
Since there must be an assessor in place on the client for those few
standardized attributes to be assessed and that assessor will likely already
have these covered by vendor-specific attributes, in other words,
we seem to be standardizing redundancy.  On the network attachment
side, it is possible, of course, that an offer of remediation could be made
based on just the standard attributes, but it seems far more likely that
it would be a two step process (assess standard attributes, then pass
vendor-specific attributes to vendor plug-in).  Again, if the vendor's
attributes cover the standard attributes, then this is largely redundant
and may add measurable latency; it seems far more likely that 
step one would simply be skipped if there were a vendor-specific string
and an available plug-in. Since there has to be an assessor, the first
seems very likely to me.  If you don't have a vendor's plug-in, then
I suppose there is some chance that you will trust and act based on the standard
attributes, but the chance of getting the right remediation seems
pretty slight in those circumstances.  Especially when many vulnerabilities
are a combination of conditions, (Browser version Foo on OS patch level Bar) 
that you could remediate by upgrading either one, checking for and
acting on the attributes which could be standardized seems of very, very 
limited utility.

				Ted Hardie

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 09 Oct 2006 11:07:38 +0200

>>>This is what I meant when I said that the charter is unclear
>>>and it must explicitly state that NEA is not meant as a
>>>protection mechanism of any sort for the network.
> 
> 
> I don't believe the Charter needs to delve into this at all.  If some people
> see it as part of their protection mechanisms, so be it.
> 
> Darryl (Dassa) Lynch 

The IETF has an obligation to "truth in advertising" so IMHO we should not
claim protection that doesn't exist, even implicitly.

    Brian

---

From: "todd glassey" <[email-masked]>
Date: Mon, 9 Oct 2006 06:17:33 -0700

The IETF has an obligation to WIPO and to the DMCA and well - so far its
failed those pretty well I think.

Todd Glassey

----- Original Message ----- 
From: "Brian E Carpenter" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, October 09, 2006 2:07 AM
Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea)

> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Fritz F. Saad" <[email-masked]>
Date: Mon, 9 Oct 2006 07:58:20 -0600

Tood,

Agreed, we should work to fix that.

Fritz.

----- Original Message ----- 
From: "todd glassey" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, October 09, 2006 7:17 AM
Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea)

Todd Glassey

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 09 Oct 2006 16:31:34 +0200

> Agreed, we should work to fix that.
...
> The IETF has an obligation to WIPO and to the DMCA 
...

I can only assume this was intended as some form of joke.

    Brian

---

From: Keith Moore <[email-masked]>
Date: Mon, 09 Oct 2006 11:03:33 -0400

> I can only assume this was intended as some form of joke.

regardless of intent, it should be treated as such.

Keith

---

From: "todd glassey" <[email-masked]>
Date: Mon, 9 Oct 2006 09:05:50 -0700

Fritz this is a much bigger issue than ANYONE thinks at this time and its
based on the idea that the WIPO standard says that the IETF MUST be doing
Industrial Design IP Models, and it only does Copyright which is a violation
of the WIPO IP protection framework  and the treaties ALL of the Member
States have signed.

Interesting eh?

Todd Glassey

----- Original Message ----- 
From: "Fritz F. Saad" <[email-masked]>
To: "todd glassey" <[email-masked]>; "Brian E Carpenter"
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, October 09, 2006 6:58 AM
Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea)

---

From: "todd glassey" <[email-masked]>
Date: Mon, 9 Oct 2006 09:08:42 -0700

No it wasn't Brian - the WIPO IP Framework calls for a set of protections
for Industrial Designs which ALL of the work that happens here is controlled
by right? Otherwise, do you formally want to make a declaration as the
IETF's Chair that the IETF and the ISOC are immune from Global IP Law and
can pretty much do anything they want.

Todd Glassey

---

From: Frank Yeh Jr <[email-masked]>
Date: Mon, 9 Oct 2006 10:41:51 -0700

Ted Hardie <[email-masked]> wrote on 10/08/2006 11:45:37 PM:

> [snip]
> my sense is that the very core of this work is a perceived
> prior to the host attaching.

      Yes, that is the essence of this work which is what we need to
remember and focus on. It will probably be applied for various purposes.

> Those opaque strings are, essentially,

      There seems to be confusion as two why people would want to do this.
In one sense we can protect things by not giving compromised endpoints
access to network-attached resources, including parts of the network
itself. This application has caused significant discussion as to the
security of the protocol and solutions using it, which promises to be a
subject of debate for the near future.

      Another way of looking at this is that it allows customers to use the
network to enforce endpoint compliance to policy and provide a convenient
"place" to challenge endpoints, collect data from them, thus providing an
audit trail.

> acting on the attributes which could be standardized seems of very, very

      Standardized VS vendor-specific attributes is not something that
needs to be solved today. Solutions can start with vendor-specific and
migrate toward a standard, if one develops, without changing the protocol.
The specification should not preclude the addition of standardized
attributes. IE the specification is like an alphabet, attributes are like
vocabulary. You can add new words without changing the letters.

>             Ted Hardie

Frank Yeh

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 9 Oct 2006 10:36:10 -0700

On Mon, Oct 09, 2006 at 09:08:42AM -0700, todd glassey wrote:
> by right?

I suppose you might consider ALL IETF work as protected or threatened by
WIPO Inustrial Designs [1] treaties if you first accept that "ALL" IETF
work is ornamental.

But of course, the joke isn't funny if you have to explain it.

[1] http://www.wipo.int/designs/en/designs.html

-- 
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DDNS & DHCP.  Email [email-masked].
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins
_______________________________________________
Nea mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea

---

From: Theodore Tso <[email-masked]>
Date: Mon, 9 Oct 2006 15:09:31 -0400

> can pretty much do anything they want.

Todd,

According to the WIPO web site:

	"The World Intellectual Property Organization (WIPO) is a
	specialized agency of the United Nations. It is dedicated to
	developing a balanced and accessible international intellectual
	property (IP) system, which rewards creativity, stimulates innovation
	and contributes to economic development while safeguarding the public
	interest."

What the WIPO might or might not call for might perhaps be of interest
to various national legislative bodies, but it is completely out of
scope for the IETF list.

Regards,

					- Ted
					IETF Sergeant-at-Arms

---

From: "todd glassey" <[email-masked]>
Date: Mon, 9 Oct 2006 13:54:51 -0700

No you are wrong Ted, and its pretty funny too.  As it happens you are
incorrect for saying that this is inappropriate for the IETF's lists.

You need to dig farther into the WIPO Site and find all the State Signatures
to the Treaties - its them that the IETF is bound by whether it likes it or
not.  Since the countries through with the IETF's actions operate including
the meetings, are all signatories to the WIPO Treaties you are exactly stuck
with them.

Todd Glassey

----- Original Message ----- 
From: "Theodore Tso" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: "Brian E Carpenter" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Monday, October 09, 2006 12:09 PM
Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea)

---

From: Theodore Tso <[email-masked]>
Date: Mon, 9 Oct 2006 17:25:55 -0400

> the meetings, are all signatories to the WIPO Treaties you are exactly stuck

I said it was inappropraite for the IETF list.  If you have specific
ideas as they relate to the ipr working group, feel free to be
specific about specific WIPO treaties that have resulted in national
legislation, and specific changes to be made to IETF's IPR policies,
feel free to make them on that list, but not on the main IETF list,
please.

Thanks,

					- Ted

---

From: "todd glassey" <[email-masked]>
Date: Mon, 9 Oct 2006 14:39:46 -0700

So then Ted are you formally saying that it is inappropriate to discuss IETF
operations or its processes on the [email-masked] mailing list?

The problem with the IPR working group is simply that Harald kicks people
off for disagreeing with him or his very limited charter. He doesn't want to
hear about expanding the charter or how these other issues fit into the IPR
Working Group and in doing so he is violating my and others participatory
rights as well as our First Amendment rights I believe too.

Todd Glassey.

----- Original Message ----- 
From: "Theodore Tso" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: "Brian E Carpenter" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Monday, October 09, 2006 2:25 PM
Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea)

> ideas as they reFrom [email-masked] Mon Oct 09 18:02:11 2006
From: "todd glassey" <[email-masked]>
To: "Theodore Tso" <[email-masked]>
Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea)
Date: Mon, 9 Oct 2006 14:39:46 -0700
Cc: Brian E Carpenter <[email-masked]>, [email-masked], [email-masked]

So then Ted are you formally saying that it is inappropriate to discuss IETF
operations or its processes on the [email-masked] mailing list?

The problem with the IPR working group is simply that Harald kicks people
off for disagreeing with him or his very limited charter. He doesn't want to
hear about expanding the charter or how these other issues fit into the IPR
Working Group and in doing so he is violating my and others participatory
rights as well as our First Amendment rights I believe too.

Todd Glassey.

----- Original Message ----- 
From: "Theodore Tso" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: "Brian E Carpenter" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Monday, October 09, 2006 2:25 PM
Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea)

---

From: "todd glassey" <[email-masked]>
Date: Mon, 9 Oct 2006 17:04:14 -0700

You know Ted you crack me up.

Todd Glassey

----- Original Message ----- 
From: "Theodore Tso" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, October 09, 2006 3:16 PM
Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea)

> On Mon, Oct 09, 2006 at 02:39:46PM -0700, todd glassey wrote:
> If you have a specific and actionable suggestion regarding IETF
> direction, policy, meetings, and procedures, where there is not a more
> appropriate e-mail venue (such as the IPR wg list), then it is
> certainly, appropriate for the IETF list.
>
> Your recent postings, alas, have not met this test.
>
> First Amendment rights only apply when the US Government restricts
> speech.  It does not apply anywhere else.  In general, you have been
> making various legal claims without being a lawyer, and fairly wild
> ones which make it very clear that you don't know what you are talking
> about.  For what it's worth, be advised that I know of know legally
> enforceable "right" that you might have towards participating in any
> IETF forum, and certainly if you persist in sounding like someone who
> does not know what they are talking about, no one is required to
> listen to you, either --- and more and more people may in fact decide
> that it is wise for them to exercise their right to ignore you.
>
> Regards,
>
> - Ted

---

From: Theodore Tso <[email-masked]>
Date: Mon, 9 Oct 2006 18:16:49 -0400

Regards,

						- Ted

---

From: "todd glassey" <[email-masked]>
Date: Tue, 10 Oct 2006 11:37:49 -0700

Hey Ted - the more I thought about this post of yours the more it annoyed
me. You see - when a WG chair doesn't want someone saying something in their
WG and they control the number of players in that WG, they will always
control the consensus such as it is.

The point is that there is no where to permanently register a dissenting
opinion in an effort or IETF program now that you claim that the charter for
the [email-masked] mailing list is restricted.

The IETF needs IMHO one general list for everything that doesn't fall under
the rubric/charter/umbrella of some WG and their list, and personally after
NETWORK was shutdown I thought that this was it.

Todd Glassey

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 10 Oct 2006 14:34:51 -0500

Todd,

I've received several complains from people that think that you are crossing
the limit again and being off-topic with this thread and I seriously agree
with them.

Consequently I warn you. If you keep going on this, I will apply a new ban
(two weeks, as it will be your second one in a very short period of time).

Regards,
Jordi, acting as IETF Sergeant-at-arms

> De: todd glassey <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Tue, 10 Oct 2006 11:37:49 -0700
> Para: Theodore Tso <[email-masked]>
> CC: "[email-masked]" <[email-masked]>, <[email-masked]>
> Asunto: Re: [Nea] WG Review: Network Endpoint Assessment (nea)
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 13 Oct 2006 15:43:11 -0400

>>>>> "Frank" == Frank Yeh <[email-masked]> writes:

    Frank> Standardized VS vendor-specific attributes is not something that needs to be
    Frank> solved today. Solutions can start with vendor-specific and migrate toward a
    Frank> standard, if one develops, without changing the protocol. The specification
    Frank> should not preclude the addition of standardized attributes. IE the
    Frank> specification is like an alphabet, attributes are like vocabulary. You can add
    Frank> new words without changing the letters.

One of the things coming out of the most recent BOF was a strong
desire for PA-level interoperability.  That can be accomplished
through standardized attributes or vendor-specific attributes that are
sufficiently well documented (and not subject to patents) that third
parties can implement collectors or analysis tools that interoperate
with the vendor tools for the vendor attributes.

Will we be able to meet these interoperability goals?  Why or why not?

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 16 Oct 2006 17:06:02 -0700

Sam, 

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]] 
> Sent: Friday, October 13, 2006 12:43 PM
> To: Frank Yeh Jr
> Cc: Hardie, Ted; [email-masked]; [email-masked]
> One of the things coming out of the most recent BOF was a 
> strong desire for PA-level interoperability.  That can be 
> accomplished through standardized attributes or 
> vendor-specific attributes that are sufficiently well 
> documented (and not subject to patents) that third parties 
> can implement collectors or analysis tools that interoperate 

I am very apprehensive of achieving any meaningful PA-level
interoperability. I am not sure what minimum set of PA attributes will
be standardized, but, whatever that set is, I doubt will be sufficient
to provide any acceptable level of security, even for the endpoints.
Even assuming ongoing standardization of vendor specific attributes, it
is not totally realistic to assume that all applications will support
the appropriate attributes. The rate of standardization is also very
likely to be much slower than the rate of the growth in the number of
attributes needed for any continued meaningful protection. 

Regards,
Vidya

---

From: "Stephen Hanna" <[email-masked]>
Date: Tue, 17 Oct 2006 02:04:42 -0400

> to provide any acceptable level of security, even for the endpoints.

This is not surprising, since you have said that you don't see
any security value to NEA.

> attributes needed for any continued meaningful protection.  

NEA is not based on applications supporting attributes.
Attributes are supported by Posture Collectors and
Posture Validators, specialized NEA components. An AV
Posture Collector will handle attributes pertaining
to AV, perhaps by interfacing with an existing AV
application. Still, I agree that a given endpoint
will typically only support a small subset of the
universe of possible attributes. Not a problem.
As long as the endpoint supports enough attributes
that the Posture Broker can evaluate its compliance
with the posture policy, that's enough.

Thanks,

Steve

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Monday, October 16, 2006 5:06 PM
To: Sam Hartman; Frank Yeh Jr
Cc: Hardie, Ted; [email-masked]; [email-masked]
Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea)

Sam, 

>     From [email-masked] Tue Oct 17 02:12:49 2006
Content-class: urn:content-classes:message
Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea)
Date: Tue, 17 Oct 2006 02:04:42 -0400
To: "Narayanan, Vidya" <[email-masked]>,
	"Sam Hartman" <[email-masked]>, "Frank Yeh Jr" <[email-masked]>
Cc: "Hardie, Ted" <[email-masked]>, [email-masked], [email-masked]

> to provide any acceptable level of security, even for the endpoints.

This is not surprising, since you have said that you don't see
any security value to NEA.

> attributes needed for any continued meaningful protection.  

NEA is not based on applications supporting attributes.
Attributes are supported by Posture Collectors and
Posture Validators, specialized NEA components. An AV
Posture Collector will handle attributes pertaining
to AV, perhaps by interfacing with an existing AV
application. Still, I agree that a given endpoint
will typically only support a small subset of the
universe of possible attributes. Not a problem.
As long as the endpoint supports enough attributes
that the Posture Broker can evaluate its compliance
with the posture policy, that's enough.

Thanks,

Steve

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Monday, October 16, 2006 5:06 PM
To: Sam Hartman; Frank Yeh Jr
Cc: Hardie, Ted; [email-masked]; [email-masked]
Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea)

Sam, 

Regards,
Vidya

---

From: "Stephen Hanna" <[email-masked]>
Date: Tue, 17 Oct 2006 02:04:42 -0400

Sam Hartman wrote:
> strong desire for PA-leFrank> Standardized VS vendor-specific attributes is not 
> something that needs to be

Regards,
Vidya

---

From: "Stephen Hanna" <[email-masked]>
Date: Tue, 17 Oct 2006 02:04:42 -0400

> Will we be able to meet these interoperability goals?  Why or why not?

Yes, we can. If we define a small set of standardized attributes
(OS and app version, AV status, etc.) and make them mandatory to
implement, then we will have interoperability with respect to
those attributes. We should allow the definition of attributes
that go beyond this minimal standard mandatory to implement (MTI)
set but the MTI set will provide a baseline of information
available for all endpoints that implement NEA.

Thanks,

Steve

vel interoperability.  That can be 
> Will we be able to meet these interoperability goals?  Why or why not?

Yes, we can. If we define a small set of standardized attributes
(OS and app version, AV status, etc.) and make them mandatory to
implement, then we will have interoperability with respect to
those attributes. We should allow the definition of attributes
that go beyond this minimal standard mandatory to implement (MTI)
set but the MTI set will provide a baseline of information
available for all endpoints that implement NEA.

Thanks,

Steve

---

From: Douglas Otis <[email-masked]>
Date: Tue, 17 Oct 2006 15:07:26 -0700

On Oct 17, 2006, at 11:22 AM, Eliot Lear wrote:

> I would think that five or six values are appropriate:
>
>   1. Vendor name (string)
>   2. Vendor engine version (integer)
>   3. Vendor virus definitions version (integer)
>   4. Enabled? (binary)
>   5. Buggered? (binary)
>   6. Other gobbledigook the vendor wants to include that might get
>      standardized later. (blob)

This still seems like too much.  Information offered for access can  
be contained within one or more certificates.   The information  
within these certificates should be limited to a minimal set of values:

1) creator
2) class
3) user-host
4) time-stamp
5) update resources

The essential information would be the creator/class/user-host/time- 
stamp fields.  When protection is not enabled or is buggered, then a  
newer certificate should not be offered.  The virus definitions or  
patch updates can be deduced from the time-stamp or by extensions  
added to class, i.e. AVX-VISTA-37.  If a vulnerability is reported  
subsequent to the time-stamp regarding the creator/class of service,  
then a new certificate could be required.  This would simplify  
tracking at the access point.  By keeping the information exchanged  
and decisions limited to this minimal information, NEA should provide  
a valuable services in many environments.

Perhaps there should be some consideration given regarding which sets  
of certificates are offered in various environments.  Allowing the  
certificates to be accessed beyond an authentication process seems to  
increase security exposures.  As this information is not trustworthy,  
there would be also little gained sharing this information  
elsewhere.  In fact, sharing this information may increase infection  
rates when this aids malware.

-Doug

---

From: Ted Hardie <[email-masked]>
Date: Tue, 17 Oct 2006 09:28:32 -0700

At 2:04 AM -0400 10/17/06, Stephen Hanna wrote:
>implement,

Sorry, but doesn't "AV status" above refer to the existing, proprietary anti-virus
systems?  How does standardizing an attribute for carrying that help
create a standardized understanding of what it means?    Don't I still
have to treat that as, essentially, a vendor attribute, since I have
to know which vendor statuses cover which vulnerabilities?

Or do you mean "there is some anti-virus software here"?

			Ted Hardie

---

From: Ted Hardie <[email-masked]>
Date: Tue, 17 Oct 2006 09:28:32 -0700

Ted Hardie

---

From: Ted Hardie <[email-masked]>
Date: Tue, 17 Oct 2006 12:25:01 -0700

At 8:22 PM +0200 10/17/06, Eliot Lear wrote:
> would think that five or six values are appropriate:
>
>  1. Vendor name (string)
>I could envision 3 being a bit of an issue if it is possible to update specific viruses but not others.

Thanks for this.  I was assuming we were talking primarily about a "1 and 3" combined
value.  As it stands now, you need access to the vendor's database to know what
viruses are covered by any specific version (your 3).  For the charter discussions,
I want to know whether it will be an aim of the working group to standardize:

* a way of carrying this information
* the structure of this information (but not its content)
* a standard representation of the content, so that access to the vendor database
   is no longer required

The tasks are substantially different in scope, and the level of interoperabilty
the community can expect from them are similarly different.
			regards,
				Ted Hardie

@proton.jnpr.net>
	<p06240601c15ab4897e51@[10.0.1.4]> <[email-masked]>
Date: Tue, 17 Oct 2006 12:25:01 -0700
To: Eliot Lear <[email-masked]>
From: Ted Hardie <[email-masked]>
Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea)
Cc: Sam Hartman <[email-masked]>, [email-masked], [email-masked]

At 8:22 PM +0200 10/17/06, Eliot Lear wrote:
> would think that five or six values are appropriate:
>
>  1. Vendor name (string)
>I could envision 3 being a bit of an issue if it is possible to update specific viruses but not others.

Thanks for this.  I was assuming we were talking primarily about a "1 and 3" combined
value.  As it stands now, you need access to the vendor's database to know what
viruses are covered by any specific version (your 3).  For the charter discussions,
I want to know whether it will be an aim of the working group to standardize:

* a way of carrying this information
* the structure of this information (but not its content)
* a standard representation of the content, so that access to the vendor database
   is no longer required

The tasks are substantially different in scope, and the level of interoperabilty
the community can expect from them are similarly different.
			regards,
				Ted Hardie

---

From: Eliot Lear <[email-masked]>
Date: Tue, 17 Oct 2006 20:22:57 +0200

Ted,

   1. Vendor name (string)

I could envision 3 being a bit of an issue if it is possible to update 
specific viruses but not others.

I would expect the normal enterprise administrator to be able to act on 
the first 5.  The 6th is there as a placeholder.  I'm not sure I'd trust 
5 if it's false.  I'd also suggest we're well into solving the problem 
at this point.

Eliot

---

From: Douglas Otis <[email-masked]>
Date: Wed, 18 Oct 2006 13:19:24 -0700

On Oct 18, 2006, at 7:37 AM, Sam Hartman wrote:

>
> Douglas> 1) creator 2) class 3) user-host 4) time-stamp 5) update  
> resources
>
> How do I get a new cert if mine is expired?  Go for remediation and  
> get it there?
>
> I actually like a lot of what you specify.

The NEA server indicates required certificates by presenting sets of  
certificates where user-host is identified as "hostmaster/ 
<example.com>."

The NEA client then offers a matching certificate for each set  
obtained from a variety of services such as:

1) Acknowledge AUP web-form
2) Acknowledge Deficiency web-form
3) Network Configuration
4) OS Update
5) AV Update
6) System Scan

Upon completion of NEA negotiations, the granted network environment  
is returned.

-- remediation --

When a certificate is considered expired or required by the NEA  
server, the service associated with the creator/update-resources  
generates their certificate with a relevant time-stamp only upon  
successful completion.  The time-stamp would be relative to the  
service and not always the current time.  When an update service  
detects that a related mechanism is not functioning, prior  
certificates it may have produced should be withdrawn from the NEA  
client.

"Update resources" could be defined as a list of URLs.  When the  
endpoint is placed into a walled garden, these resources are enabled  
to allow access to the services.  Upon completion of the service, a  
new certificate is generated and appended to those held by the NEA  
client.  Modifying the list of certificates could then trigger a new  
NEA negotiation.

Once a valid certificate is presented by the NEA client, the NEA  
server has only one additional check to make before deciding whether  
to accept the certificate.  Has the creator/class time-stamp  
expired?  This may expire when a vulnerability is reported by the  
related service since a time-stamp or perhaps when a deficiency has  
been detected.

This minimal structure should be suitable for any service type and  
use environment, without adding unneeded complexity to the NEA client/ 
server.

Security would be reduced by exchanging service related details with  
NEA server.  These services should be considered separate and  
independent of the NEA protocol, except for the service generated  
certificates.  Service related details should not be exposed to  
untrusted third-parties.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Wed, 18 Oct 2006 18:42:26 -0700

On Oct 18, 2006, at 2:15 PM, Sam Hartman wrote:

> You didn't really answer the question I asked.

I'll try again.

> I think you have the core of a really cool idea here.  I strongly  
> urge you to find someone who cares a lot about the details of how  
> you get these certificates and how the overall user experience  
> works.  The two of you should write up a concrete proposal.  I  
> think this is well outside of what current work in the NEA space is  
> doing, but I think it might provide better interoperability.

This concept might still fit within the NEA charter.

The suggestion was to use a type of PKI certificate ("Posture-Cert")  
as a proxy for the "posture" details defined within the NEA  
descriptions.  Private keys generating Posture-Certs would be held by  
Service servers, and not by Service clients.  Service servers and  
clients are external to the NEA protocol.

Once a Service updates the OS or AV software, does a system scan, or  
checks configuration settings and completes satisfactorily, a Posture- 
Cert is generated for the User-Host identity.  This Posture-Cert is  
sent to the Service client at the end of the Service exchange, which  
is then placed into the NEA Posture-Cert repository visible to the  
NEA client as .nea/repo/creator--class.

Posture-Certs prevent exposure of Service related details to third- 
parties where security might be compromised. The NEA server may  
decide to trust a Service server's Posture-Certs.  At that point, the  
NEA server only needs to track when these Posture-Certs expire.   
Expiry could be published for each class by the creator or  
independently asserted by the NEA server.

A user's experience could be controlled by automatically invoking  
related Service Update-Resources when needed, by prompting for their  
execution, or by offering a launching mechanism when network status  
indicates interaction is required.  These resources are defined as  
URLs such as:

  os-update-deamon://some-os-distro.com:6002/repo/version-xyz/

A web-form service might use the URL:

  https://www.some-isp.com:443/members/agreement.html

The web-form could inform users of their obligations when accessing  
the network resources being offered.  Once the user agrees to the  
terms, the web-form prompts for a download of the created Posture- 
Cert then stored in the NEA client Posture-Cert repository.

These Services are not part of the NEA protocol.  The Service Posture- 
Certs Update-Resource URLs may help ensure a Service still functions  
when access is constrained.  A Service Posture-Cert may also be  
needed to obtain full access.  Regardless of the Service, the  
underlying details are not exposed, where granting access is based  
only upon the Posture-Cert's creator/class/time-stamp information.

-Doug

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Oct 2006 11:37:40 +0200

Seems like you are starting the WG discussion on the
IETF list. Bad idea?

(ietf list dropped)

>   3. Vendor virus definitions version (integer) 

These need to be strings. Version numbers are often more complex
than an integer.

    Brian

Douglas Otis wrote:
> This still seems like too much.  Information offered for access can  be 
> contained within one or more certificates.   The information  within 
> these certificates should be limited to a minimal set of values:
> 
> 1) creator
> 2) class
> 3) user-host
> 4) time-stamp
> 5) update resources
> 
> patch updates can be deduced from the time-stamp or by extensions  added 
> to class, i.e. AVX-VISTA-37.  If a vulnerability is reported  subsequent 
> to the time-stamp regarding the creator/class of service,  then a new 
> certificate could be required.  This would simplify  tracking at the 
> access point.  By keeping the information exchanged  and decisions 
> limited to this minimal information, NEA should provide  a valuable 
> services in many environments.
> 
> there would be also little gained sharing this information  elsewhere.  
> In fact, sharing this information may increase infection  rates when 
> this aids malware.
> 
> -Doug
> 
> 
> 
> 
>

---

From: Eliot Lear <[email-masked]>
Date: Wed, 18 Oct 2006 12:06:36 +0200

> These need to be strings. Version numbers are often more complex

I really don't have a horse in this race, so I won't claim to know 
what's best.  I do know that were I a network administrator I would want 
to say something like, "if engine name = "Norton" and engine version < 
X, then as an action reject or whine.  Forcing the use of an = sign for 
version information, particularly for virus definitions, would seem 
suboptimal from a configuration standpoint.  Obviously we at Cisco are 
not fond of simple integers.  Consider the case of 12.2(21)XS.  
Fortunately, in my case I'm doing unto others and not unto ourselves 
;-)  Of course, one could allow for an overloaded C++esque verison of 
'<' and leave to implementations to understand what's earlier.  But this 
might be overkill for the problem.  Clearly the major AV people should 
have their say, here.

Anyway, my real point to Ted was simply that I believe this problem is 
NOT insurmountable and I would agree with you that it is best discussed 
in a smaller audience, like a  WG.

Eliot

---

From: Sam Hartman <[email-masked]>
Date: Wed, 18 Oct 2006 10:37:22 -0400

>>>>> "Douglas" == Douglas Otis <[email-masked]> writes:

    Douglas> This still seems like too much.  Information offered for
    Douglas> access can be contained within one or more certificates.
    Douglas> The information within these certificates should be
    Douglas> limited to a minimal set of values:

    Douglas> resources

    Douglas> The essential information would be the
    Douglas> creator/class/user-host/time- stamp fields.  When
    Douglas> protection is not enabled or is buggered, then a newer
    Douglas> certificate should not be offered.  The virus definitions
    Douglas> or patch updates can be deduced from the time-stamp or by
    Douglas> extensions added to class, i.e. AVX-VISTA-37.  If a
    Douglas> vulnerability is reported subsequent to the time-stamp
    Douglas> regarding the creator/class of service, then a new
    Douglas> certificate could be required.  This would simplify
    Douglas> tracking at the access point.  By keeping the information
    Douglas> exchanged and decisions limited to this minimal
    Douglas> information, NEA should provide a valuable services in
    Douglas> many environments.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 18 Oct 2006 17:15:29 -0400

I think you have the core of a really cool idea here.  I strongly erge
you to find someone who cares a lot about the details of how you get
these certificates and how the overall user experience works.  The two
of you should write up a concrete proposal.  I think this is well
outside of what current work in the NEA space is doing, but I think it
might provide better interoperability.

---

From: "Mike Fratto" <[email-masked]>
Date: Thu, 19 Oct 2006 09:14:31 -0400

> clients are external to the NEA protocol.

Or you can just roll out Microsoft's Network Access Protection. :)

---

From: Sam Hartman <[email-masked]>
Date: Thu, 19 Oct 2006 01:08:53 -0400

>> You didn't really answer the question I asked.

    Douglas> I'll try again.

Still failed.

You are failing to focus on the detail that NEA intends to run
*before* network access.  The obvious implementation of what you are
proposing depends on network access to work.  But I don't need an
answer at this point.  I've been convinced that I personally think the
idea is worth developing as something for NEA to consider.

    >> I think you have the core of a really cool idea here.  I
    >> strongly urge you to find someone who cares a lot about the
    >> details of how you get these certificates and how the overall
    >> user experience works.  The two of you should write up a
    >> concrete proposal.  I think this is well outside of what
    >> current work in the NEA space is doing, but I think it might
    >> provide better interoperability.

    Douglas> This concept might still fit within the NEA charter.

I believe it does.  I don't think it is what NEA proponents were
thinking of when they proposed the charter but I think it falls within
the charter.

---

From: "Stephen Hanna" <[email-masked]>
Date: Thu, 19 Oct 2006 10:44:23 -0400

Ted Hardie wrote:
> For the charter discussions, I want to know whether it will
> be an aim of the working group to standardize:
>

I believe that we'll need to define all three of these.
There may be times when access to an external database
would be useful (if you want to know exactly which viruses
are covered by which AV defs version, for example) but
such access should not be required to use the standard
attributes.

Thanks,

Steve

---

From: Douglas Otis <[email-masked]>
Date: Thu, 19 Oct 2006 10:03:07 -0700

On Oct 18, 2006, at 10:08 PM, Sam Hartman wrote:

> *before* network access.  The obvious implementation of what you  
> are proposing depends on network access to work.  But I don't need  
> an answer at this point.  I've been convinced that I personally  
> think the idea is worth developing as something for NEA to consider.

Understood.  NEA can be used as a method to prompt for remediation  
where non-essential services are constrained until these needed  
Services have been preformed.  Normally Posture-Certs are obtained in  
the background during normal use.  When walled-garden or sandbox  
techniques are not available or considered adequate, then another  
mode of network operation can be used.  Part of the NEA protocol may  
include a network tunnel.  This tunnel could work much like SSH with  
port forwarding.  This tunnel allows only the connections found in  
the Posture-Certs Update-Resources presented by the NEA server.  The  
changes required to accommodate hundreds of existing Services that  
could become a component of NEA requirements are thereby minimized.

-Doug

---

From: "Alan DeKok" <[email-masked]>
Date: Thu, 19 Oct 2006 14:04:02 -0400

Douglas Otis <[email-masked]> wrote:
> Part of the NEA protocol may include a network tunnel.  This tunnel
> could work much like SSH with port forwarding.

  Or 802.1x, which already sets up an SSL tunnel between the end
machine and a AAA server.  The AAA server is already doing
authentication and authorization.  AAA servers already perform a
limited form of assesment and control of end devices.  Adding posture
assessment and remediation isn't much of a stretch.

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