Subject: Re: [secdir] [New-work] WG Review: Network Endpoint Assessment (nea)

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 07 Oct 2006 16:45:19 -0700

It appears that there was consensus to form a NEA working group at 
the last BoF meeting.  Given that, I won't object to a WG being 
formed, but the charter needs to be more tightly scoped.  I have 
asked for an applicability statement to be put on this work at the 
IETF.  I will try and provide draft text to that end.

At 07:40 AM 10/2/2006, IESG Secretary wrote:
>A new IETF working group has been proposed in the Security Area.
>The IESG has not made any determination as yet. The following draft
>charter was submitted, and is provided for informational purposes only.
>Please send your comments to the IESG mailing list ([email-masked])
>by October 9.
>
>+++
>
>Network Endpoint Assessment (nea)
>======================================
>
>Current Status: Proposed Working Group
>
>Chair(s):
>TBD
>
>Security Area Director(s):
>Russ Housley <[email-masked]>
>Sam Hartman <[email-masked]>
>
>Security Area Advisor:
>Russ Housley <[email-masked]>
>
>Mailing List: [email-masked]
>
>Description of Working Group:
>
>Network Endpoint Assessment (NEA) architectures have been implemented in
>the industry to assess the "posture" of endpoint devices for the
>purposes of monitoring compliance to an organization's posture policy
>and optionally restricting access until the endpoint has been updated to
>satisfy the posture requirements. An endpoint that does not comply with
>posture policy may be vulnerable to a number of known threats that may
>exist on the network. The intent of NEA is to facilitate corrective
>actions
>to address these known vulnerabilities before a host is exposed to
>potential attack.

How does NEA facilitate corrective action?  Isn't corrective action 
out of scope for NEA?

>Two deployment scenarios will be supported: advisory mode and mandatory
>mode.
>In advisory mode, an endpoint may be advised of the result of posture
>assessment
>and any recommended remediation actions, but is provided normal network
>access
>regardless of the result. In mandatory mode, a non-compliant endpoint is
>given
>restricted access to the network sufficient for remediation purposes
>and any essential
>services or denied access completely.

I suggest deleting the text about advisory and mandatory 
modes.  Instead let us state that after assessment is complete, 
corrective action such as it is, is up to the organization's policy.

>Posture refers to the hardware or software configuration of an
>endpoint as it pertains to an organization's security policy. Posture
>may include knowledge that software installed to protect the machine
>(e.g. patch management software, anti-virus software, host firewall
>software,
>host intrusion protection software or any custom software) is enabled
>and up-to-date.
>On network access and while connected, an endpoint supporting NEA
>protocols can be
>queried for such posture information in either advisory or mandatory
>modes.

It is not clear how this is feasible.  Tying this to network access 
is not universally applicable (for instance, in cases where the 
endpoints are not owned by the organization performing the 
assessment; Vidya and others have pointed this out at various times 
on the NEA list and elsewhere), and it is not clear what the 
transport protocol is for assessment while connected.  I realize that 
the transport protocol is out of scope for NEA WG, but curious what 
other than EAP is on the table for this purpose.

>Since NEA involves many different components from different vendors,
>interoperation is highly desirable. The priority of the NEA working
>group is to
>standardize protocols at the higher layers in the architectures:
>the Posture Attribute protocol (PA) and the Posture Broker protocol (PB).
>PA and PB will be designed to support a variety of lower layer protocols.
>When used with standards for lower layers, these new protocols will allow
>interoperability between an NEA Client from one vendor and an NEA
>Server from another.
>
>Since there are already several non-standard protocols at these higher
>layers, the NEA working group will consider these existing protocols
>as candidates for standardization. A requirements document will be
>written and used as a basis for evaluating the candidate protocols.
>The working group may decide to standardize one of the candidate
>protocols, use one of them as a basis for a new or revised protocol,
>or decide that a new protocol is needed.
>
>The NEA Requirements document will include a problem statement,
>definition of terms, requirements for the PA and PB protocols, and an
>overall
>security analysis. It will also include generic requirements for the
>protocol
>transporting PA, PB: the Posture Transport protocol (PT). PT protocols may
>be
>standardized in other WGs since these protocols may not be specific
>to NEA. The NEA WG
>will identify one mandatory to implement PT protocol to ensure
>interoperability.
>
>PA, the Posture Attribute protocol, consists of posture attributes
>that are carried between a particular Posture Collector in a NEA
>client and a particular Posture Validator in a NEA Server. The PA
>protocol is carried inside the PB protocol. Certain posture attributes
>will be standardized to ensure interoperability but vendor-specific
>attributes will also be supported. Vendor-specific attributes must
>be documented in an RFC.
>
>The PB (Posture Broker) protocol aggregates posture attributes
>from one or more Posture Collectors in an NEA client and sends them to
>the NEA server for assessment by one or more Posture Validators.
>
>The PT (Posture Transport) protocol (or stack of protocols) is
>suitable for carrying
>the PB protocol at the time of network connection, or shortly after.

The phrase "shortly after" is ambiguous.  Once again my question is 
what is the transport protocol in mind here, one that can be used at 
the time of network connection and one that can be used "shortly after."

>The NEA working group will not specify protocols other than PA and PB at
>this
>time. The expectation is that an existing protocol can be used for the PT.
>
>
>
>One commonly discussed issue with NEA systems is how to handle
>compromised endpoints, whose reports of their own posture may not be
>accurate.

Actually this goes one step further.  How does an NEA system know 
whether an endpoint is compromised or not?  It does not.  So, all 
endpoints must be assumed to have been compromised.

>Detecting or handling such endpoints is out of scope of
>the NEA WG. Work on PA will focus on attributes useful for assessing
>posture of those endpoints reporting accurate information. However,
>the protocols developed by the NEA WG must be designed to accommodate
>emerging technologies for identifying and dealing with lying endpoints.
>
>Note that NEA is not chartered to standardize protocols for remediation.
>NEA is intended to be used with new or existing tools that can be used in
>the absence of NEA.

This statement is not clear.

>There is an open issue with respect to NEA
>applicability
>in deployment scenarios where the endpoint is owned by a party that
>is different
>from the organization providing network access.

Instead of this let us write an applicability statement for NEA 
work.  "NEA is applicable to networks where endpoints accessing the 
network are owned and tightly controlled by the organization that 
owns and operates the network.  In all other cases, NEA and 
associated procedures and protocols are ineffective."

>Further work in the NEA WG will be considered via the standard
>rechartering
>process after the completion of these milestones.
>
>Milestones:
>
>June 2006:
>* Submit first version of NEA Requirements I-D
>
>July 2006:
>* Agree on charter and milestones at IETF 66

I presume the above will be revised.

><snip>
>December 2006:
>* Deadline for submission of candidate specs for PA and PB
>* Submit first version of NEA Evaluation I-D
>
>January 2007:
>* WG Last Call on NEA Evaluation I-D

The December and January deadlines seem too tight.  Perhaps those can 
be revised based on the WG's pace.

><snip>
>September 2007:
>* Decide how to address MTI PT, recharter if needed

What's MTI?

thanks,
Lakshminath

>_______________________________________________
>New-work mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/new-work
>_______________________________________________
>secdir mailing list
>[email-masked]
>https://mailman.mit.edu/mailman/listinfo/secdir

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 9 Oct 2006 09:29:37 -0700

Hi Darrly, 

<snip>

> >> 
> >> It appears that the NEA charter is completely misleading to some 
> >> people from what is stated in this email. As the NEA 
> charter alludes 
> >> to, NEA does nothing to protect against compromised 
> devices. Also, as 
> >> has been agreed, NEA is not a protection mechanism for the 
> network - 
> >> it is meant to be a protection mechanism for compliant, 
> truthful and 
> >> as yet uncompromised end hosts against known vulnerabilities.
> 
> True the NEA doesn't "do" anything to protect against 
> compromised devices but it does assist in limiting the known 
> compromises on endpoint devices by being a mechanism for the 
> checking and reporting on compliance to what ever network 
> policy is in place including virus and patch levels.  

I'm not sure what you mean by "known compromises" - did you mean known
vulnerabilities? If so, yes - I was not questioning the role of NEA in
dealing with known vulnerabilities on truthful endpoints. 

The discussion was about using NEA as a protection mechanism for the
network and that doesn't make sense to me and as I understand from
Susan, that is not the intention of the charter either. 

> As a 
> network administrator I already deploy mechanisms for doing 
> just this, but at a higher level than the NEA charter 
> indicates.  To me the difference is between being reactive or 
> proactive.  Compliance testing I already run occurs after an 
> end node has joined the network, with NEA the possibility is 
> for compliance checking before being allowed onto the network 
> so isolation and immediate remediation is possible.
> 
> >> Any network, in its own best interests, must assume that 
> it has lying 
> >> and compromised endpoints connecting to it and that there 
> are unknown 
> >> vulnerabilities on any NEA-compliant devices connecting to it. Any 
> >> kind of protection that addresses these general threats that the 
> >> network may be exposed to at any time will simply obviate the need 
> >> for NEA from the network perspective.
> 
> Reliance on one protection or reporting mechanism is not 
> enough.  We need a lot of varied tools to cover all the bases 
> and minimise risk.
> 

This is repitition at this point - but, when a network has mechanisms to
protect itself against lying endpoints and unknown vulnerabilites, that
should cover protection against truthful ones with known
vulnerabilities. Otherwise, the network is obviously not adequately
protected against the broader set of threats. So, one would employ NEA
in their networks to protect the end hosts attaching to the network, not
the network itself. 

> >> A network operator that thinks the network is getting any 
> protection 
> >> by employing NEA is clearly ignoring the obvious real threats that 
> >> the network is exposed to at any time.
> 
> No, NEA would just be one more tool used to improve overall 
> security and minimise risk.  It would be at a different level 
> to the tools some of already deploy.
> 
> >> 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.
> 

That is a terrible approach to take, given how misleading the charter
obviously has been to many. The charter must be clear about what the WG
is doing and what is out of scope. 

Vidya

---

From: "Gray, Eric" <[email-masked]>
Date: Wed, 11 Oct 2006 11:37:53 -0400

I completely agree with Noel on every detail of these comments.

And, no, I was not one of the complainers either.  :-)

--
Eric 

--> -----Original Message-----
--> From: [email-masked] [mailto:[email-masked]] 
--> Sent: Wednesday, October 11, 2006 11:26 AM
--> To: [email-masked]
--> Cc: [email-masked]
--> Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea)
--> 
-->     > From: "Steven M. Bellovin" <[email-masked]>
--> 
-->     >> it is better that we aren't copied because to do so 
--> would be unfair to
-->     >> the complainer(s).
--> 
-->     > As much as I've sparred with Glassey in the past ... 
--> I think he's right
-->     > in this case. In my opinion, any sort of disciplinary 
--> action needs to
-->     > be *perceived* as fair. ... I think we do need to 
--> follow due process.
--> 
--> I'm going to disagree with you on this. My reasoning is 
--> that the decision of
--> whether or not to suspend should be based almost entirely 
--> on the target
--> person's posts, so the identity (and, indeed, the number) of people
--> complaining is basically irrelevant.
--> 
--> The whole concept of "facing your accuser" came about 
--> because the accusers
--> usually made factual claims ("I saw Joe steal Frank's 
--> car"). Traditionally,
--> people wanted to be able to weigh the truthfulness of such claims by
--> observing the person making the assertion, and observing 
--> their response to
--> questioning. In addition, the target might know of some 
--> grudge that led the
--> accuser to make a false accusation. In this case, however, there is
--> absolutely no probative value coming from knowing *who* complained.
--> 
--> To put it another way, I would hope if several people 
--> complained about some
--> reasonable post, the SaA(s) would independently review the 
--> post, and if they
--> thought it was reasonable, would take no action, the number 
--> or identity of
--> the complainers notwithstanding. The issue is not who 
--> complained - the issue
--> is the content of the posts - and that's all.
--> 
--> Indeed, any miniscule probative value in knowing who 
--> complained is entire
--> outweighed, IMO, by the possibility that making their 
--> identities public would
--> result in a campaign of harrassment against them.
--> 
--> And no, I was not one of the people who complained privately.
--> 
--> 
-->     > I do agree that the Sergeants-at-Arms can act on 
--> their own volition,
-->     > but if they do they should say so
--> 
--> I have no probem with the SaA(s) disclosing whether or not 
--> they acted
--> entirely on their own bat, in response to complaints, or 
--> both. In addition, I
--> have no problem with them disclosing the number (if any) of 
--> complainters.
--> 
--> However, I strenuously oppose making the names public, 
--> because the potential
--> harm in that (possibility for harassment, and also the 
--> possibility that
--> less-forthcoming people will sit on their hands rather than 
--> complain, if
--> their names have to be made public) far outweighs any 
--> possible value in in
--> mking them public. Indeed, it turns out that most police 
--> departments actually
--> have anonymous tip lines, for precisely these reasons (and others).
--> 
--> 
--> If the community decides to do elsewise, I offer myself up 
--> as an anonymizing
--> agent for any complaints to the SaA(s); i.e. I will forward 
--> any complaints
--> sent to me, as if they were my own, after removing the 
--> identity of the
--> former. If I can recruit a few other people to do the same, 
--> that will suffice
--> to avoid any issue with one person not being able to 
--> complain more than once.
--> 
--> 	Noel
--> 
--> _______________________________________________
--> Ietf mailing list
--> [email-masked]
--> https://www1.ietf.org/mailman/listinfo/ietf
-->

---

From: Frank Yeh Jr <[email-masked]>
Date: Thu, 12 Oct 2006 15:32:47 -0700

Greetings,

      Both of the existing flavors of NEA-type protocols (Cisco NAC and
TNC) provide some mechanisms for integrity checking after the admission
process has completed and removing an endpoint's privileged access if it
falls out of compliance. So IMHO, support for post-admission integrity
checking willbe expected in NEA.

      Collector/Verifier pairs can use NEA for pre-admission integrity
checking and some other protocol for post-admission checking but if a
post-admission violation is found, there should be a mechanism to terminate
the user's current admission session and restart the admission process.

Regards,
Frank Yeh
Corporate Security Strategy Team
IBM
Tivoli Software

             "Darryl \(Dassa\)                                             
             Lynch"                                                        
             <[email-masked]>                                            To 
                                       <[email-masked]>                      
             10/12/2006 02:27                                           cc 
             PM                        [email-masked]                       
                                                                   Subject 
                                       RE: [Nea] Re: WG Review: Network    
             Please respond to         Endpoint Assessment (nea)           
               [email-masked]                                               

Douglas Otis wrote:
>>
>> If an application happens to be malware, it seems it would
>> be unlikely stop these applications.  How about:
>>
>> vi)   Provide application level advisory information pertaining to
>> available services.
>>
>> Points that seem to be missing are:
>>
>> vii)  Notification of non-compliance. (Perhaps this could become a
>> restatement of i.)
>>
>> viii) Time or sequence sensitive compliance certificates provided
>>       following a remediation process or service.
>>
>>
>> Often bad behavior is detected, such as scanning or sending
>> spam which may violate AUPs.  These violations may trigger a
>> requirement for the endpoint to use a service that offers
>> remedies the en.com>

From: Frank Yeh Jr <[email-masked]>
Date: Thu, 12 Oct 2006 15:32:47 -0700
Cc: [email-masked], [email-masked]
Subject: RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)

Greetings,

      Both of the existing flavors of NEA-type protocols (Cisco NAC and
TNC) provide some mechanisms for integrity checking after the admission
process has completed and removing an endpoint's privileged access if it
falls out of compliance. So IMHO, support for post-admission integrity
checking willbe expected in NEA.

      Collector/Verifier pairs can use NEA for pre-admission integrity
checking and some other protocol for post-admission checking but if a
post-admission violation is found, there should be a mechanism to terminate
the user's current admission session and restart the admission process.

Regards,
Frank Yeh
Corporate Security Strategy Team
IBM
Tivoli Software

             "Darryl \(Dassa\)                                             
             Lynch"                                                        
             <[email-masked]>                                            To 
                                       <[email-masked]>                      
             10/12/2006 02:27                                           cc 
             PM                        [email-masked]                       
                                                                   Subject 
                                       RE: [Nea] Re: WG Review: Network    
             Please respond to         Endpoint Assessment (nea)           
               [email-masked]                                               

Douglas Otis wrote:
>>
>> If an application happens to be malware, it seems it would
>> be unlikely stop these applications.  How about:
>>
>> vi)   Provide application level advisory information pertaining to
>> available services.
>>
>> Points that seem to be missing are:
>>
>> vii)  Notification of non-compliance. (Perhaps this could become a
>> restatement of i.)
>>
>> viii) Time or sequence sensitive compliance certificates provided
>>       following a remediation process or service.
>>
>>
>> Often bad behavior is detected, such as scanning or sending
>> spam which may violate AUPs.  These violations may trigger a
>> requirement for the endpoint to use a service that offers
>> remedies the endpoint might use.
>> There could then be a time-sensitive certificate of
>> compliance offered following completion of a check-list and
>> an agreement to comply with the recommendations.
>>
>> Those that remain infected after remediation, or that ignore
>> the AUPs and are again detected, may find this process a
>> reason to correct the situation or their behavior, or the
>> provider may wish to permanently disable the account.

Am I mistaken or is NEA intended to be a compliance check before a node is
allowed onto the network?  As such, observed behaviour and application
abuse
would seem to be issues that would be dealt with by other tools.  NEA may
be
used to ensure certain applications are installed and some other
characteristics of the node but actual behaviour may not be evident until
such time as the node has joined the network and would be beyond the scope
of detection by NEA IMHO.  NEA may be used to assist in limiting the risk
of
such behaviour but that is about the extent of it that I see.

My reading of the charter gives me the impression NEA is only intended for
a
specific task and some of what we have been discussing seems to extend well
beyond the limited scope proposed.

Darryl (Dassa) Lynch

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

---

From: yinhan 34728 <[email-masked]>
Date: Tue, 10 Oct 2006 11:27:07 +0800

> 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-
> specificstrings.  
> 
> 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 
> redundantand may add measurable latency; it seems far more likely 
> that 6 08:16:46 -0400
Date: Tue, 10 Oct 2006 11:27:07 +0800
From: yinhan 34728 <[email-masked]>
To: Ted Hardie <[email-masked]>
Priority: normal
Cc: [email-masked], [email-masked]
Subject: Re:[Nea] WG Review: Network Endpoint Assessment (nea)

> 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-
> specificstrings.  
> 
> 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 
> redundantand may add measurable latency; it seems far more likely 
> that 
> step one would simply be skipped if there were a vendor-specific 
> stringand 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 
> vulnerabilitiesare 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.

  I think that most function should  be completed through vendor-specific attributes and 
  standard attributes are only basic information.

> step one would simply be skipped if there were a vendor-specific 
> stringand 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 
> vulnerabilitiesare 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.

  I think that most function should  be completed through vendor-specific attributes and 
  standard attributes are only basic information.

---

From: Frank Yeh Jr <[email-masked]>
Date: Fri, 13 Oct 2006 10:35:29 -0700

Greetings,

"todd glassey" <[email-masked]> wrote on 10/13/2006 05:56:42 AM:

> So then this is an attempt by Cisco and IBM and several others to
> qualify a "SOX reporting and compliance tool" - get real.
>
> Todd Glassey

      I'm not sure I follow how you can infer that post-admission status
checks are Cisco and IBM's attempt to qualify a "SOX reporting and
compliance tool". That's one of the wildest leaps of (il)logic I have seen.

      While my comments here do not represent IBM in any official capacity
I can say that IMHO, a Sox compliance and reporting tool based solely on
NEA (or Cisco NAC or TNC) would be woefully inadequate. Could the data
collected for an NEA posture check be stored as part of an audit trail and
would this data be useful? Absolutely! Does that make this a Sox compliance
and reporting tool? No way! It would just become another trail of
interesting information that would be aggregated in a REAL compliance and
reporting tool.

      One might also consider that the original post concerned
post-admission integrity checking as opposed to checking at admission only.
The data collected during the admission process would be just as suitable
for compliance and reporting as post-admission data. So why does the
addition of post-admission checking suddenly make this a compliance and
reporting tool?

      While logic can sometimes be dangerous ("my logic is undeniable"), I
tend to rely on it in the absence of anything better. I don't understand
the logic behind your statement.

Regards,
Frank Yeh

> ----- Original Message -----
> From: Frank Yeh Jr
> To: [email-masked]
> Cc: [email-masked] ; [email-masked]
> Sent: Thursday, October 12, 2006 3:32 PM
> TNC) provide some mechanisms for integrity checking after the
> admission process has completed and removing an endpoint's
> privileged access if it falls out of compliance. So IMHO, support
> for post-admission integrity checking willbe expected in NEA.
>
> checking and some other protocol for post-admission checking but if
> a post-admission violation is found, there should be a mechanism to
> terminate the user's current admission session and restart the
> admission process.
>
> Regards,
> Frank Yeh
> [image removed] "Darryl \(Dassa\) Lynch" <[email-masked]>
>

>
> "Darryl \(Dassa\) Lynch" <[email-masked]>
> 10/12/2006 02:27 PM
>
> Please respond to
> [email-masked]
>
> [image removed]
> To
>
> [image removed]
> <[email-masked]>
>
> [image removed]
> cc
>
> [image removed]
> [email-masked]
>
> [image removed]
> Subject
>
> [image removed]
> RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
>
> [image removed]
>
> [image removed]
>
>
> Douglas Otis wrote:
> >>
abuse
be
of
> My reading of the charter gives me the impression NEA is only intended
for a

---

From: "Stephen Hanna" <[email-masked]>
Date: Tue, 17 Oct 2006 09:30:13 -0400

Ted,

As I understand your concerns expressed below, you are concerned
that standardizing attributes for NEA would be redundant and
pointless: redundant because vendor-specific attributes will
cover the same information in more detail and pointless because
remediation will not be possible given the limited information
available through the standardized attributes. Is that right?

If so, maybe it would help to explain why we want to have
standardized attributes. The goal is to ensure that any NEA
endpoint and server can interoperate in a meaningful manner
without making the assumption that endpoint and server have
the same vendor "plug-ins" installed. For this to be true,
we must ensure that every NEA endpoint provides a basic set
of information to the NEA server. That basic set of information
will be the standardized attributes. If the endpoint and server
both understand vendor-specific attributes that provide more
information, that's great. But we want to ensure a base level
of interoperability.

Yes, remediation may be difficult using only the information
in the standardized attributes. But a captive portal technique
can be used to provide information to the endpoint user about
how to remediate.

Thanks,

Steve

Ted Hardie wrote:
> 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 
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.  
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
> 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
> attributes cover the standard attributes, then this is largely
redundant
> and may add measurable latency; it seems far more likely that 
string
> and an available plug-in. Since there has to be an assessor, the first
> I suppose there is some chance that you will trust and act based on
the standard
> pretty slight in those circumstances.  Especially when many
vulnerabilities
> are a combination of conditions, (Browser version Foo on OS patch
level Bar) 
> acting on the attributes which could be standardized seems of very,
very