Subject: [Nea] 03 comments - IDS as Posture Collecotr

From: Leif Johansson <[email-masked]>
Date: Mon, 23 Jul 2007 21:14:42 +0200

>From section 5.1.1.1:

 5.1.1.1 Posture Collector
    
    The Posture Collector is the component that is responsible for
    responding to requests for posture information in Request
    Attributes from the NEA Server.  The Posture Collector is also
    responsible for handling assessment decisions in Result
    Attributes and remediation instructions in Remediation
    Attributes.  A single NEA Client can have several Posture
    Collectors capable of collecting standard and/or vendor-specific
    Posture Attributes for particular endpoint components.  Typical
    examples include Posture Collectors that provide information
    about Operating System (OS) patch levels, anti-virus software,
    and security mechanisms on the endpoint such as host firewall or
    an Intrusion Detection System (IDS).

Typically IDSen are _not_ part of the endpoint but rather systems which
are part of the overall network infrastructure, eg active scanners such
as "nessus" or passive scanners such as "snort".

I am convinced that information from IDSen will be an important part of
the data collected and processed by a NEA deployment.

I think the text in this section needs clarification wrt Posture Collectors
which report on endpoints which are different from the one the NEA
Client (which the PC is part of) is running on. Section 5.1.1 has text
which uses the NAT-box as an example of a case when a network entity
is _not_ responsible for reporting on the entities behind it. I think the
section needs text exemplifying the reverse - eg an IDS reporting on
the posture of endpoints within its scope.

    Cheers Leif

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

---

From: "Paul Sangster" <[email-masked]>
Date: Mon, 23 Jul 2007 13:29:38 -0700

Comments below... 

> -----Original Message-----
> From: Leif Johansson [mailto:[email-masked]] 
> Sent: Monday, July 23, 2007 12:15 PM
> To: [email-masked]
> Subject: [Nea] 03 comments - IDS as Posture Collecotr

Curious about the topic, I presume your referring to IDS being used as a
NEA Client for other systems?  In Prague we discussed whether the NEA
Client could exist on non-endpoints such as an IDS reporting posture for
other endpoints.  The consensus (as we reported today) was this was
likely out of scope for NEA's current charter and that using the planned
protocols might not make sense when talking to an IDS.

I presume this is the thread your highlighting (since the Posture
Collector co-exists with the NEA Client components).

> Typically IDSen are _not_ part of the endpoint but rather 
> systems which are part of the overall network infrastructure, 
> eg active scanners such as "nessus" or passive scanners such 
> as "snort".
> 
> I am convinced that information from IDSen will be an 
> important part of the data collected and processed by a NEA 
> deployment.

I agree that the IDS will play an important role for detecting potential
mis-behaviour on the network and potentially interacting with the NEA
Server or enforcement devices on the network (or endpoint).  However the
posture the IDS can learn by observing traffic is likely a subset of the
posture a local Posture Collector can learn (e.g. version of RPMs
installed).  Its also not clear the PA, PB and PT are the right
protocols for the NEA Server to detect the existance, redirect NEA
Client requests and communicate with an IDS.  We probably need a
protocol more specific to this environment and this protocol could be
something for later specification by the WG once we re-charter after
successful definition of PA and PB.

> 
> I think the text in this section needs clarification wrt 
> Posture Collectors which report on endpoints which are 
> different from the one the NEA Client (which the PC is part 
> of) is running on. Section 5.1.1 has text which uses the 
> NAT-box as an example of a case when a network entity is 
> _not_ responsible for reporting on the entities behind it. I 
> think the section needs text exemplifying the reverse - eg an 
> IDS reporting on the posture of endpoints within its scope.

The NAT box analogy worked because it was the endpoint of assessment
where the IDS is not if I understand your comment.  Also as you noted
the NAT box only reports on its own internal posture, not other devices.
The IDS box could report its own posture using NEA, but believe this
isn't what your requesting.

Did I miss your point?

Paul

---

From: Robert Bird <[email-masked]>
Date: Mon, 23 Jul 2007 16:42:00 -0400 (EDT)

My instinct is that if an IDS provides NEA client functionality, then it should not be considered part of the IDS itself. If an IDS is acting as a collector/validator, that functionality should also be considered separate from its functionality as an IDS. I believe we're risking running afoul of complications if we blur these lines. 

----- Original Message ----- 
From: Paul Sangster <[email-masked]> 
To: Leif Johansson <[email-masked]>, [email-masked] 
Sent: Monday, July 23, 2007 4:29:38 PM GMT-0500 US/Eastern 
Subject: RE: [Nea] 03 comments - IDS as Posture Collecotr 

Comments below... 

Did I miss your point? 

Paul

---

From: Leif Johansson <[email-masked]>
Date: Tue, 24 Jul 2007 01:07:30 +0200

> protocols might not make sense when talking to an IDS.
That is partially why I bring this up again. Either the reference to
IDS should go and be replaced with a very strong statement to the
fact that the external posture collector is explicitly out of scope (or
even forbidden) or the text should accurately reflect how IDSen
actually work. Currently the text is confusing.

I remember the discussion in Prague but don't remember that there
was a strong consensus for keeping external PC out of scope. Having
read the requirements draft I don't really see how this would really
make the model that much more complex and I think there are very
good reasons for keeping that use-case in the model.

> posture the IDS can learn by observing traffic is likely a subset of the
Absolutely not. An active scanner can detect actual vulnerabilities
while listing installed software detects what vulnerabilities *should*
exist on the endpoint. Both are interesting.
> where the IDS is not if I understand your comment.  Also as you noted
Yes that is part of it.
> isn't what your requesting.
No, I'm interested in the case when a posture broker can request
postures from entities not necessarily on the client (eg an IDS).

    Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Tue, 24 Jul 2007 01:10:16 +0200

Robert Bird wrote:
> My instinct is that if an IDS provides NEA client functionality, then
> it should not be considered part of the IDS itself. If an IDS is
> acting as a collector/validator, that functionality should also be
> considered separate from its functionality as an IDS. I believe we're
> risking running afoul of complications if we blur these lines.
>
I still don't understand. Here is the question: An active vulnerability
scanner (eg nessus)
running on an IDS server knows things about the client (from doing a
scan). How is this
information folded into the process of evaluating the posture of the client?

    Cheers Leif

---

From: Alan DeKok <[email-masked]>
Date: Mon, 23 Jul 2007 19:24:22 -0400

> postures from entities not necessarily on the client (eg an IDS).

  i.e. The client says it's at update level X.  You then ask the update
manager if the client has downloaded update X.  If not, the client *may*
be lying to you.

  Alan DeKok.

---

From: Robert Bird <[email-masked]>
Date: Mon, 23 Jul 2007 20:04:27 -0400 (EDT)

You raise an interesting point. In that situation, where you have combined an IDS with vulnerability assessment, we would love to have that information correlated with the information collected from the endpoint. Why? Because we cannot safely assume that the endpoint can be trusted. I'm a big fan of doublechecking assumptions when it comes to security, and a whole lot of historical work ignores this issue. 

That problem, however, is not what I envision the NEA protocols solving. I agree with you 100% that this information is important, but I believe it is outside the charter for NEA. 

Intervendor security interoperability is the elephant in the room. But it's still not why we're in the room :) 
Take care, 
Rob 

----- Original Message ----- 
From: Leif Johansson <[email-masked]> 
To: Robert Bird <[email-masked]> 
Cc: [email-masked] 
Sent: Monday, July 23, 2007 7:10:16 PM GMT-0500 US/Eastern 
Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr 

Cheers Leif

---

From: Robert Bird <[email-masked]>
Date: Mon, 23 Jul 2007 20:05:39 -0400 (EDT)

But can we trust the update manager? :) 

----- Original Message ----- 
From: Alan DeKok <[email-masked]> 
To: Leif Johansson <[email-masked]> 
Cc: [email-masked], Paul Sangster <[email-masked]> 
Sent: Monday, July 23, 2007 7:24:22 PM GMT-0500 US/Eastern 
Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr 

Alan DeKok.

---

From: Leif Johansson <[email-masked]>
Date: Tue, 24 Jul 2007 02:25:58 +0200

Robert Bird wrote:
> You raise an interesting point. In that situation, where you have
> combined an IDS with vulnerability assessment, we would love to have
> that information correlated with the information collected from the
> endpoint. Why? Because we cannot safely assume that the endpoint can
> be trusted. I'm a big fan of doublechecking assumptions when it comes
> to security, and a whole lot of historical work ignores this issue.
>
> That problem, however, is not what I envision the NEA protocols
> solving. I agree with you 100% that this information is important, but
> I believe it is outside the charter for NEA.
>
I agree.

My question is this: How does adding this seriously affect the model?

    Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Tue, 24 Jul 2007 02:30:24 +0200

> manager if the client has downloaded update X.  If not, the client *may*
That is yet another example. Good!

I don't want to make this about lying or not. That is a big rat-
hole. Its about different sources of information providing a
better view of the client together than separately.

I really don't see how taking the requirement that "the
client is at the endpoint" out of the specification makes
things that much more complex.

    Cheers Leif

---

From: "Paul Sangster" <[email-masked]>
Date: Mon, 23 Jul 2007 17:49:45 -0700

Comments below... 

> Sent: Monday, July 23, 2007 5:30 PM
> To: Alan DeKok
> Cc: Paul Sangster; [email-masked]
> >   i.e. The client says it's at update level X.  You then ask the 
> > update manager if the client has downloaded update X.  If not, the 
> > client *may* be lying to you.
> >
> >   Alan DeKok.
> >
> >   
> I don't want to make this about lying or not. That is a big 
> rat- hole. Its about different sources of information 
> providing a better view of the client together than separately.
> 

Are you proposing that the entire NEA Client would exist on the
non-endpoint (IDS system)?  I suspect not, but you might be thinking of
the Posture Broker Client and Posture Collectors.  If the Posture
Transport Client is separate from the Posture Broker Client this changes
some assumptions including the security requirements for PB (which we
lowered since it was stated these co-exist and PT has manditory to
implement security features).  This also means the PB layer wouldn't sit
on the endpoints PT so some other assumptions/text would need to be
revised.

Some of the other requirements are also impacted as the IDS would need
to have a way to support an assessment as the endpoint in joining the
network so we would need to talk about how this would work since the IDS
might not be involved in that process or know in real-time that its
occurring.

I also believe that an IDS can not provide the same level of detailed
posture information that an endpoint collector so this might impact our
standard attributes.

There is also a lot of text in the spec that would need to change
including in the security and privacy considerations sections.  So there
are a lot of changes needed but its feasible.

I believe we heard that a new protocol to support properly interacting
with an IDS is outside our currently approved charter.  If we think this
is very important, we could try to address this after we meet at least
our initial chartered milestone (reqs spec) and start the future
milestone discussion.  

Do we believe that PA and PB could be used to talk to the IDS?  What
transport protocol would sit below them and that may also be outside of
charter.

All interesting questions, but I do think adding this causes lots of
changes of varying sizes throughout the spec.  *If* this is deemed
within our charter, we should see what that WG wishes to do here.

---

From: Frank Yeh Jr <[email-masked]>
Date: Mon, 23 Jul 2007 18:04:54 -0700

Greetings,

      I've been lurking on this thread because I don't really get the point
of asking a third party for a state of the client as part of the protocol.
I was hoping to learn something from watching the conversation but so far I
still do not see the value of doing this and I also believe that
theadditional complexity of the client not being at the endpoint might be a
little more than trivial.

      So right now the protocol essentially instantiates a tunnel between
the endpoint and the validator, and also gives the validator a way to
direct the network how to treat the client. Building more than these basic
interfaces does complicate the issue... Right now there is a single
supplicant on the tunnel and this client is the one that is either granted
or denied network access. If you add in third party (EG IDS) into the mix,
now you have to have a protocol and an interface to talk to an IDS or any
other conceivable 3rd party and the 3rd patry has to be able to associate
the client with the right network port so that its access can be
controlled. This would then have to be built into the protocol.
      Why is this better than just having the validator check with the IDS
for whatever it is you want checked? The client can simply submit a unique
client id and the validator can then do whatever is desired on the other
end of the tunnel, including checking with IDS systems or registration
systems or update managers. This can all be done on the validator side
AFTER the client data has been passed down the tunnel.

      An alternative is to make the IDS a validator and then have the
client send it's state and have the IDS validate that it is not spoofing.
Doesn't this support the desired scenario without having to change the
protocol? Add that in as a separate validator and let the client and
servers do the brokering. IMHO this is how the protocol was designed to
work.

      My basic concern is that if we try to build too many external
interfaces into the protocol it will become a never-ending battle. We want
levels of abstraction so that things can change external to the protocol.
My preference is to make it a secure tunnel for passing state data over the
network with specific functions between the client/server and the network
to control requesting/granting/denying access. As to the decision making
process, this should be left outside the protocol per se, and handled  by
the validators outside of the tunnel.

      PLEASE NOTE nothing I say here precludes any of the scenarios that
have been discussed being supported outside of the protocol by the
validators. My fundamental argument is that we need to limit the scope of
what the protocol is and does. People will always find uses for a
technology that is outside of its intended function. trying to anticipate
everything people will try to do and building it in is a fool's errand. The
best thing we can do is to make the standard as generic and flexible as
possible.  A good analogy would be RISC VS CISC processors. I like the
protocol to be lean and mean like RISC_ adding in separate interfaces for
an IDS to report on the state of the client is a huge complicator.

Frank Yeh
Sr. Security & Privacy Integration Architect
IBM Global Technology Services
Security & Privacy Technology Integration Team

Second Life: Yehoo Newall

---

From: Kaushik Narayan <[email-masked]>
Date: Tue, 24 Jul 2007 06:13:02 -0700

I agree with Frank. The scenario being discussed can addressed by treating
an IDS system (and scanners) as validators or in many cases the IDS system
might be a component that validators can acquire attributes from since the
IDS system natively might not evaluate an endpoint compliance policy. The
interaction between NEA and the IDS system would be part of the vertical
protocol stack on the NEA server which is currently out-of-scope.

On 7/23/07 6:04 PM, "Frank Yeh Jr" <[email-masked]> wrote:

> Greetings,
> 
> I've been lurking on this thread because I don't really get the point of
> asking a third party for a state of the client as part of the protocol. I was
> hoping to learn something from watching the conversation but so far I still do
> not see the value of doing this and I also believe that theadditional
> complexity of the client not being at the endpoint might be a little more than
> trivial.
> 
> So right now the protocol essentially instantiates a tunnel between the
> endpoint and the validator, and also gives the validator a way to direct the
> network how to treat the client. Building more than these basic interfaces
> does complicate the issue... Right now there is a single supplicant on the
> tunnel and this client is the one that is either granted or denied network
> access. If you add in third party (EG IDS) into the mix, now you have to have
> a protocol and an interface to talk to an IDS or any other conceivable 3rd
> party and the 3rd patry has to be able to associate the client with the right
> network port so that its access can be controlled. This would then have to be
> built into the protocol.
> Why is this better than just having the validator check with the IDS for
> whatever it is you want checked? The client can simply submit a unique client
> id and the validator can then do whatever is desired on the other end of the
> tunnel, including checking with IDS systems or registration systems or update
> managers. This can all be done on the validator side AFTER the client data has
> been passed down the tunnel.
> 
> An alternative is to make the IDS a validator and then have the client send
> it's state and have the IDS validate that it is not spoofing. Doesn't this
> support the desired scenario without having to change the protocol? Add that
> in as a separate validator and let the client and servers do the brokering.
> IMHO this is how the protocol was designed to work.
> 
> My basic concern is that if we try to build too many external interfaces into
> the protocol it will become a never-ending battle. We want levels of
> abstraction so that things can change external to the protocol. My preference
> is to make it a secure tunnel for passing state data over the network with
> specific functions between the client/server and the network to control
> requesting/granting/denying access. As to the decision making process, this
> should be left outside the protocol per se, and handled  by the validators
> outside of the tunnel.
> 
> PLEASE NOTE nothing I say here precludes any of the scenarios that have been
> discussed being supported outside of the protocol by the validators. My
> fundamental argument is that we need to limit the scope of what the protocol
> is and does. People will always find uses for a technology that is outside of
> its intended function. trying to anticipate everything people will try to do
> and building it in is a fool's errand. The best thing we can do is to make the
> standard as generic and flexible as possible.  A good analogy would be RISC VS
> CISC processors. I like the protocol to be lean and mean like RISC_ adding in
> separate interfaces for an IDS to report on the state of the client is a huge
> complicator.
> 
> 
> Frank Yeh

---

From: Alan DeKok <[email-masked]>
Date: Tue, 24 Jul 2007 10:33:16 -0400

Frank Yeh Jr wrote:
> asking a third party for a state of the client /as part of the
> protocol/. I was hoping to learn something from watching the
> conversation but so far I still do not see the value of doing this and I
> also believe that theadditional complexity of the client not being at
> the endpoint might be a little more than trivial.

  I discussed this with Paul last night.  My view is that it may be
useful to obtain posture assessment from multiple devices.  Generally,
devices will be endpoints.  However, other devices can act as "taps" on
the network, and can give additional information about endpoint posture.

  NEA should be focussed on endpoint assessment.  However, it should
permit NEA servers to obtain posture assessments from other devices.

> ... If you add in third party (EG IDS)
> into the mix, now you have to have a protocol and an interface to talk
> to an IDS

  PA protocol + other transport.

> or any other conceivable 3rd party and the 3rd patry has to be
> able to associate the client with the right network port so that its
> access can be controlled. This would then have to be built into the
> protocol.

  No.  This exact same issue has come up in RADEXT recently.  IDS
devices can not associate the client with the "right" network port.
They should not be expected to do that.  Instead, they can inform
another server (NEA or AAA) of the devices posture.  That other server
can use that information to instruct the switch how to deal with the
endpoint.

  In RADIUS, the AAA server can send a request to the switch,
instructing it to disconnect the non-compliant device.  People have
deployed this today.  It's a model that is useful, and it works.

  NEA should permit the same behavior.

> whatever it is you want checked?

  The client may not engage in non-compliant behavior until after it has
obtained network access.  The client may claim it's compliant, but later
analysis may show that it is not, in fact, compliant.  The IDS
determines this, and informs the NEA server.  The NEA server has a
relationship with the switch, and informs the switch to modify it's
treatment of the endpoint.

> An alternative is to make the IDS a validator and then have the client
> send it's state and have the IDS validate that it is not spoofing.

  That is possible.  We do not want to *require* such behavior, though.
 This means requiring an NEA server, and optionally permitting an IDS.

> PLEASE NOTE nothing I say here precludes any of the scenarios that have
> been discussed being supported outside of the protocol by the
> validators. My fundamental argument is that we need to limit the scope
> of what the protocol is and does.

  Yes.  We should also permit behavior that people find useful.

  Alan DeKok.

---

From: "todd glassey" <[email-masked]>
Date: Tue, 24 Jul 2007 07:53:51 -0700

Alan - and Frank - the key issue is in creating a USE MODEL for the actual 
NEA package and its components which performs the collection and 
dissemination processes. Without these end-user guidance models we wont know 
what functions are critical and what are not.

I propose that NEA actually put forth the effort to build these rather than 
spending thousands of the collectives hours designing 'yet another solution 
in search of a problem' which most other IETF initiatives are shackled down 
by.

Just my two cents
Todd Glassey

---

From: "todd glassey" <[email-masked]>
Date: Tue, 24 Jul 2007 08:12:53 -0700

Robert - I agree with you  about most of your posting - but for the purpose of this mailing let me play the Devil's Advocate here...
  ----- Original Message ----- 
  From: Robert Bird 
  To: Leif Johansson 
  Cc: [email-masked] 
  Sent: Monday, July 23, 2007 5:04 PM
  Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr

  You raise an interesting point. In that situation, 

Robert - you mean "in that specific use model"... right? 

  where you have combined an IDS with vulnerability assessment, we would love to have that information correlated with the information collected from the endpoint. Why? Because we cannot safely assume that the endpoint can be trusted. 

Why not?

  I'm a big fan of doublechecking assumptions when it comes to security, and a whole lot of historical work ignores this issue.

I am too but in some use scenario's it wont be necessary so the use model and its assurance levels will be what constrains and provides this info.

Again - "I envision solving" is a statement that "your vision is different from others" and the reason for that is that there is NO COMMON USE MODEL that has been agreed upon...

  Intervendor security interoperability is the elephant in the room. 

No actually the issue is in defining Intervendor Functionality across a common use model... again its the USE MODEL which is missing here still.

  But it's still not why we're in the room :)
  Take care,
  Rob

  ----- Original Message -----
  From: Leif Johansson <[email-masked]>
  To: Robert Bird <[email-masked]>
  Cc: [email-masked]
  Sent: Monday, July 23, 2007 7:10:16 PM GMT-0500 US/Eastern
  Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr

      Cheers Leif

------------------------------------------------------------------------------

---

From: Robert Bird <[email-masked]>
Date: Tue, 24 Jul 2007 11:36:17 -0400 (EDT)

Todd, thanks for the clarity regarding "use model" ...we are in agreement on this issue. Other comments inline. 

----- Original Message ----- 
From: Robert Bird 
To: Leif Johansson 
Cc: [email-masked] 
Sent: Monday, July 23, 2007 5:04 PM 
Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr 

Yes. Specifically, the use model that he was referring to: leveraging vulnerability assessment and/or IDS information to double check posture claims. 

Why not? 

Why can we :p? Seriously, though, your point is well taken. There will be certain use models predicated on the assumption that endpoints can be trusted. Other use models will not. I still believe that posture is at best a claim made by the client. It may be factual, but only the use model will determine if those claims need to be validated by another source. 

Agreed. 

Agreed. In fact, it's painfully obvious now that a use model needs to be defined. 

The horse is dead, and I'm still riding it :) 

----- Original Message ----- 
From: Leif Johansson <[email-masked]> 
To: Robert Bird <[email-masked]> 
Cc: [email-masked] 
Sent: Monday, July 23, 2007 7:10:16 PM GMT-0500 US/Eastern 
Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr 

Cheers Leif

---

From: "todd glassey" <[email-masked]>
Date: Tue, 24 Jul 2007 08:37:00 -0700

Robert - I also to illustrate also that MANY of the existing IETF Protocols suffer from this 'gerrymandering set of functionalities' in trying to meet the desires of the committee that is working on them at any given instant. What this means is that the functionality of the Standard's or proposed Standards is a moving target and that is what needs to be nailed down in my opinion... (humble or otherwise).

What NEA needs to have is a set of pre-defined specific use and functionality models which will define the specific features and constraints for each of those end-use models. It will also allow Auditor's to use NEA models more readily which will be a key value to the Industry in implementing the IETF's vision and guidance from this WG as to its use.

2 more cents. 

Todd
  ----- Original Message ----- 
  From: Robert Bird 
  To: todd glassey 
  Cc: [email-masked] ; Leif Johansson 
  Sent: Tuesday, July 24, 2007 8:36 AM
  Subject: Re: [Nea] 03 comments - IDS as Posture Collector

  Todd, thanks for the clarity regarding "use model"...we are in agreement on this issue. Other comments inline.

    ----- Original Message ----- 
    From: Robert Bird 
    To: Leif Johansson 
    Cc: [email-masked] 
    Sent: Monday, July 23, 2007 5:04 PM
    Subject: Re: [Nea] 03 comments - IDS as Posture Collector

  Why not?

  Agreed.

    ----- Original Message -----
    From: Leif Johansson <[email-masked]>
    To: Robert Bird <[email-masked]>
    Cc: [email-masked]
    Sent: Monday, July 23, 2007 7:10:16 PM GMT-0500 US/Eastern
    Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr

        Cheers Leif

----------------------------------------------------------------------------

---

From: Alan DeKok <[email-masked]>
Date: Tue, 24 Jul 2007 11:40:43 -0400

todd glassey wrote:
> Alan - and Frank - the key issue is in creating a USE MODEL for the
> actual NEA package and its components which performs the collection and
> dissemination processes. Without these end-user guidance models we wont
> know what functions are critical and what are not.

  The requirements document does a good job of describing many use
models.  The discussion here is about additional use models that should
be permitted under NEA.  Those additional use models are being deployed
*now* using existing protocols, precisely because administrators see
those functions as being critical.

  My proposal is that the NEA WG recognize that other use models exist,
and that those use models should not be prevented by the NEA design.  I
do NOT want to spend time standardizing them in NEA, as I see them as
being out of scope of the charter.  We should concentrate on endpoints,
rather than additional posture collection points.

> I propose that NEA actually put forth the effort to build these rather
> than spending thousands of the collectives hours designing 'yet another
> solution in search of a problem' which most other IETF initiatives are
> shackled down by.

  I'm not sure what you mean by that.  All of the use models discussed
here are:

  * requested by network administrators
  * deployed today in non-standard protocols
  * deployed today in non-NEA protocols.

  Alan DeKok.

---

From: Frank Yeh Jr <[email-masked]>
Date: Tue, 24 Jul 2007 09:20:22 -0700

Greetings,

      I may have missed something as the NEA work and the CNAC/TNC
protocols are starting to get a little blended in my head, but I was under
the impression that we had well-defined use cases for the protocol.

      Much of the discussions about IDS or other third parties being able
to terminate a client's connectivity are focused on post-admission checking
rather than pre-admission checking and these two cases are the only
realistic split.

      For pre-admission, I believe the existing discussions are fine and it
has been pointed out that there is nothing precluding the use of an IDS as
a validator that provides an admission decision to the server.

      For post-admission I am not convinced we need to give an external
entity the ability to initiate a conversation with the NEA components. All
current definitions allow the validator or the client to perform periodic
or triggered revalidations and terminate the connection if non-compliant
state is found. This gives the collectors and validators the freedom to do
whatever post-admission checking they desire.

      Now for post-admission decisions coming from say and IDS server, the
implication is that the IDS server reaches a decision as to the
non-compliant state of a client independently of the NEA protocols. There
is then nothing to preclude such an IDS server from terminating the
client's connectiovity using a RADIUS command to the network device. While,
this is how the CNAC and TNC servers communicate with the network devices,
they do not have a monopoly on this.

      For my money, I would want the IDS operating independently from the
NEA stuff. Tighter integration leads to tainting. If you want the IDS to be
a watchdog, do not associate it with the protocol, make it a completely
independent observer with the ability to cut off a client's access
independent of NEA. Now what I might see as viable would be a way for the
IDS to perform a second check while the client is in "quarantine" so that
it can validate that the non-compliant state that it detected in the first
place has been remediated. This is why I favor the IDS as an actual
validator on the server side of the NEA protocol, talking to the NEA server
as all validators do. This would allow the IDS to be a part of the
pre-admission decision and to terminate a client's access post-admission,
and to independently reinitiate a revalidation of the client. All of this
would operate within the current definitions of the procotol.

Regards,
Frank Yeh

                                                                           
             "todd glassey"                                                
             <tglassey@earthli                                             
             nk.net>                                                    To 
                                       "Robert Bird" <[email-masked]> 
             07/24/2007 08:37                                           cc 
             AM                        [email-masked]                        
                                                                   Subject 
                                       Re: [Nea] 03 comments - IDS as      
                                       Posture Collecotr                   

                                                                           

Robert - I also to illustrate also that MANY of the existing IETF Protocols
suffer from this 'gerrymandering set of functionalities' in trying to meet
the desires of the committee that is working on them at any given instant.
What this means is that the functionality of the Standard's or proposed
Standards is a moving target and that is what needs to be nailed down in my
opinion... (humble or otherwise).

What NEA needs to have is a set of pre-defined specific use and
functionality models which will define the specific features and
constraints for each of those end-use models. It will also allow Auditor's
to use NEA models more readily which will be a key value to the Industry in
implementing the IETF's vision and guidance from this WG as to its use.

2 more cents.

Todd
 ----- Original Message -----
 From: Robert Bird
 To: todd glassey
 Cc: [email-masked] ; Leif Johansson
 Sent: Tuesday, July 24, 2007 8:36 AM
 Subject: Re: [Nea] 03 comments - IDS as Posture Collector

 Todd, thanks for the clarity regarding "use model"...we are in agreement
 on this issue. Other comments inline.

 ----- Original Message -----
 From: todd glassey <[email-masked]>
 To: Robert Bird <[email-masked]>, Leif Johansson <[email-masked]>
 Cc: [email-masked]
 Sent: Tuesday, July 24, 2007 11:12:53 AM GMT-0500 US/Eastern
 Subject: Re: [Nea] 03 comments - IDS as Posture Collector

 Robert - I agree with you  about most of your posting - but for the
 purpose of this mailing let me play the Devil's Advocate here...
 ----- Original Message -----
 From: Robert Bird
 To: Leif Johansson
 Cc: [email-masked]
 Sent: Monday, July 23, 2007 5:04 PM
 Subject: Re: [Nea] 03 comments - IDS as Posture Collector

 Yes. Specifically, the use model that he was referring to: leveraging
 vulnerability assessment and/or IDS information to double check posture
 claims.

 where you have combined an IDS with vulnerability assessment, we would
 love to have that information correlated with the information collected
 from the endpoint. Why? Because we cannot safely assume that the endpoint
 can be trusted.

 Why not?

 Why can we :p? Seriously, though, your point is well taken. There will be
 certain use models predicated on the assumption that endpoints can be
 trusted. Other use models will not. I still believe that posture is at
 best a claim made by the client. It may be factual, but only the use model
 will determine if those claims need to be validated by another source.

 I'm a big fan of doublechecking assumptions when it comes to security, and
 a whole lot of historical work ignores this issue.

 I am too but in some use scenario's it wont be necessary so the use model
 and its assurance levels will be what constrains and provides this info.

 Agreed.

 That problem, however, is not what I envision the NEA protocols solving. I
 agree with you 100% that this information is important, but I believe it
 is outside the charter for NEA.

 Again - "I envision solving" is a statement that "your vision is different
 from others" and the reason for that is that there is NO COMMON USE MODEL
 that has been agreed upon...

 Agreed. In fact, it's painfully obvious now that a use model needs to be
 defined.

 No actually the issue is in defining Intervendor Functionality across a
 common use model... again its the USE MODEL which is missing here still.

 ----- Original Message -----
 From: Leif Johansson <[email-masked]>
 To: Robert Bird <[email-masked]>
 Cc: [email-masked]
 Sent: Monday, July 23, 2007 7:10:16 PM GMT-0500 US/Eastern
 Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr

 I still don't understand. Here is the question: An active vulnerability
 scanner (eg nessus)
 running on an IDS server knows things about the client (from doing a
 scan). How is this
 information folded into the process of evaluating the posture of the
 client?

     Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Tue, 24 Jul 2007 18:25:32 +0200

> those functions as being critical.
Yes! Exactly. As a network manager I worry that my existing
solution for admissions control won't be able to coexist with
a deployed NEA framework which I'm pretty sure I will have
since (for instance) I also deploy commercial anti-virus software.
> rather than additional posture collection points.
I'm fine with this allowing for individual work which provides
alternative profiles of NEA (using the word profile very loosly
here).

    Cheers Leif

---

From: "todd glassey" <[email-masked]>
Date: Tue, 24 Jul 2007 11:14:41 -0700

----- Original Message ----- 
From: "Leif Johansson" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: "todd glassey" <[email-masked]>; <[email-masked]>; "Paul Sangster" 
<[email-masked]>
Sent: Tuesday, July 24, 2007 9:25 AM
Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr

> alternative profiles of NEA (using the word profile very loosly

I am not per se. NEA functionality is NOT something that should be left to 
anyone to make ad-hoc changes to and still be able to claim compliance to 
the NEA standards. Likewise the use models need to be tied to compliance 
processes either in Network Security or Platform/Device Integtrity 
Management directly IMHO.

T

---

From: Alan DeKok <[email-masked]>
Date: Tue, 24 Jul 2007 14:39:22 -0400

Frank Yeh Jr wrote:
> has been pointed out that there is nothing precluding the use of an IDS
> as a validator that provides an admission decision to the server.

  I'm not sure how an IDS provides information about an endpoint that
doesn't yet have network access... but OK.

> For post-admission I am not convinced we need to give an external entity
> the ability to initiate a conversation with the NEA components.

  They will be in the same network.  They will have the capability to
communicate.  We can't pretend otherwise.

> non-compliant state of a client independently of the NEA protocols.

  Yes.  This is what people do today.  The IDS may determine that the
device is not compliant to IDS policy.  The user on an NEA-compliant
endpoint can still run software unknown to NEA that attacks the network.
 The IDS can detect this.  Existing application servers can detect
things like "3 failed login attempts", and inform the administrator.

> For my money, I would want the IDS operating independently from the NEA
> stuff. Tighter integration leads to tainting. If you want the IDS to be
> independent of NEA.

  How?  NEA is already defined to be able to trigger re-assessment, and
to block / filter user traffic.  Why would the IDS (or other) not use
that functionality?

  Again, this is not to make IDS a core component of NEA.  But we can't
realistically pretend that administrators won't integrate the two.

  Alan DeKok.

---

From: Kaushik Narayan <[email-masked]>
Date: Tue, 24 Jul 2007 12:21:40 -0700

Hi Leif,

Please my reply inline.

<snipped>

> since (for instance) I also deploy commercial anti-virus software.

I don't think that the NEA framework makes co-existence difficult. The
integration of additional sources of endpoint posture (other than the
endpoint itself) can be achieved completely within the realm of NEA server
and does not require any interaction between NEA client and NEA server which
is the scope of the NEA protocols.

There are a variety of implementation specific mechanisms which range from
standard attribute assertion protocols such as SAML to specific interfaces
such as web services that can be used by the NEA server implementations to
acquire endpoint posture attributes from systems such as IDS systems.

regards,
  kaushik

---

From: Frank Yeh Jr <[email-masked]>
Date: Tue, 24 Jul 2007 14:37:12 -0700

Greetings,

      Thanks, Kaushik. You seem to be able to say what I am thinking in
less words and with greater clarity_ maybe I can get you to just write all
my posts. ;-)

      Just to address a couple of disconnected comments:

      I want to make sure that it is Brutally clear to people that:

1)    The protocol does support using a traditional IDS as a Posture
Validator. So saying that people will integrate IDS and NEA is a given, but
they already have an interface to do so within the current scope.

2)    There might be state about a client known to an IDS before the client
actually tries to connect to the network being defended by NEA.

      In a reasonably typical scenario, you might have both a "public"
network that is not secure and not admission controlled and  a "private"
network to which admission is controlled and within which different rules
apply. A network-attached IDS could be monitoring clients' activities in
the public space and if a client were to then attempt access to the private
space, a posture validator could query the client for its MAC address and
then pass that to the IDS asking if there were any violations detected for
that MAC Address. So if the client had been detected doing illicit
activities in the public space, this could be cause for denial of access to
the private space. This would be a case where the IDS could be queried for
state of a client that is attempting to conect to "the network" but is not
yet attached to it.

Regards,
Frank Yeh

                                                                           
             Kaushik Narayan                                               
             <[email-masked]                                             
             m>                                                         To 
                                       Leif Johansson <[email-masked]>,    
             07/24/2007 12:21          Alan DeKok                          
             PM                        <[email-masked]>         
                                                                        cc 
                                       [email-masked], Paul Sangster         
                                       <[email-masked]>        
                                                                   Subject 
                                       Re: [Nea] 03 comments - IDS as      
                                       Posture Collecotr                   

                                                                           

Hi Leif,

Please my reply inline.

<snipped>

and does not require any interaction between NEA client and NEA server
which

regards,
  kaushik