Subject: [Nea] comments on requirements

From: "Chris Salter" <[email-masked]>
Date: Fri, 10 Aug 2007 13:43:26 -0400

We thought that overall the document was very clear and well written and we
have no strong criticisms of the requirements. We do have one concern,
however.

As we were reviewing, one thing we tried to keep in our minds is what would
be needed in order to provide maximal interoperability between vendors.  To
us, this would mean something along the lines of being able to support a
variety of operating systems on our network, being able to use a different
NEA client for each OS, and having them all talk to the same NEA server.  We
would like to be able to use an access policy such as "Must have a firewall
turned on, an anti-virus program running, and signatures must have been
updated within the last 24 hours" without specifying which firewall or
antivirus program the clients must use.

It seems to us that the use of a standard PA protocol, combined with a set
of basic, standardized posture attributes that every NEA client and server
understands, will make it possible to use a generic policy as described
above.  The use of a standard PB protocol that every NEA client and server
understands will allow each client to package its integrity measurements in
a format that the server will understand, parse and distribute responses
from the server, and vice versa.  

The NEA document defined these protocols clearly, and we're happy to see the
emphasis on standardizing them.  Our concern is the lack of emphasis on
standardizing PT.  The document's scope section says that, when PA and PB
are used with standard lower layer protocols, they provide interoperability.
This may be true, but what lower layer protocols will be used?  

Even if an EAP method for transport of measurements is standardized and
supported by all NEA components, a client and server must additionally
support the same tunneled EAP method for authentication in order to be
interoperable. There are examples today of different vendors who use the
same access protocol (802.1x/RADIUS), but different tunneled EAP methods,
and thus cannot interoperate.  We would like to see language clearly stating
that standardization of both an authentication protocol and a measurement
transport protocol is required for true interoperability.

Lauren Giroux

Chris Salter

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

---

From: "todd glassey" <[email-masked]>
Date: Fri, 10 Aug 2007 11:19:53 -0700

----- Original Message ----- 
  From: Chris Salter 
  To: [email-masked] 
  Sent: Friday, August 10, 2007 10:43 AM
  Subject: [Nea] comments on requirements

  We thought that overall the document was very clear and well written and we have no strong criticisms of the requirements. We do have one concern, however.

  As we were reviewing, one thing we tried to keep in our minds is what would be needed in order to provide maximal interoperability between vendors.  To us, this would mean something along the lines of being able to support a variety of operating systems on our network, being able to use a different NEA client for each OS, and having them all talk to the same NEA server.  

You are of course speaking of different vendor's NEA Client's interoperating with different vendors NEA Servers... and that seems to be the whole point of doing a standard, so I dont get how this was missed.

  We would like to be able to use an access policy such as "Must have a firewall turned on, an anti-virus program running, and signatures must have been updated within the last 24 hours" without specifying which firewall or antivirus program the clients must use.

The define those objects as 'RESOURCES' and allow under policy the NEA environment to create policy matrices that indicate acceptable policy and control rules are implemented at runtime by those vendor's NEA Client's. You will also need a uniform RESOURCE definition process, and one for resource lookup...

I suggested this with a PKI negotiation type sub-protocol to layer other event or result-driven protocols on top of once several years ago but it went no where. The key was to create a POLICY LANGUAGE and OBJECTS that can be selected through that policy language and its implementing nodes.

  It seems to us that the use of a standard PA protocol, combined with a set of basic, standardized posture attributes that every NEA client and server understands, will make it possible to use a generic policy as described above.  The use of a standard PB protocol that every NEA client and server understands will allow each client to package its integrity measurements in a format that the server will understand, parse and distribute responses from the server, and vice versa.  

  The NEA document defined these protocols clearly, and we're happy to see the emphasis on standardizing them.  Our concern is the lack of emphasis on standardizing PT.  The document's scope section says that, when PA and PB are used with standard lower layer protocols, they provide interoperability.  This may be true, but what lower layer protocols will be used?  

The end-use models are once again key to this. Without specific use models in place this is still a solution in search of a problem... 

  Even if an EAP method for transport of measurements is standardized and supported by all NEA components, a client and server must additionally support the same tunneled EAP method for authentication in order to be interoperable. There are examples today of different vendors who use the same access protocol (802.1x/RADIUS), but different tunneled EAP methods, and thus cannot interoperate.  We would like to see language clearly stating that standardization of both an authentication protocol and a measurement transport protocol is required for true interoperability.

  Lauren Giroux

  Chris Salter

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

---

From: "Paul Sangster" <[email-masked]>
Date: Mon, 13 Aug 2007 10:54:35 -0700

Chris/Lauren,
 
Thanks for the comments.   With respect to your concern, its certainly
in our charter to identify and specify the use of a standards based PT
protocol (which is why we're defining PT protocol requirements).  We'll
add some text to the scope section to make this more clear as this is
critical to having an interoperable protocol stack for NEA.
 
Paul

________________________________

	From: Chris Salter [mailto:[email-masked]] 
	Sent: Friday, August 10, 2007 10:43 AM
	To: [email-masked]
	Subject: [Nea] comments on requirements

	We thought that overall the document was very clear and well
written and we have no strong criticisms of the requirements. We do have
one concern, however.

	As we were reviewing, one thing we tried to keep in our minds is
what would be needed in order to provide maximal interoperability
between vendors.  To us, this would mean something along the lines of
being able to support a variety of operating systems on our network,
being able to use a different NEA client for each OS, and having them
all talk to the same NEA server.  We would like to be able to use an
access policy such as "Must have a firewall turned on, an anti-virus
program running, and signatures must have been updated within the last
24 hours" without specifying which firewall or antivirus program the
clients must use.

	It seems to us that the use of a standard PA protocol, combined
with a set of basic, standardized posture attributes that every NEA
client and server understands, will make it possible to use a generic
policy as described above.  The use of a standard PB protocol that every
NEA client and server understands will allow each client to package its
integrity measurements in a format that the server will understand,
parse and distribute responses from the server, and vice versa.  

	The NEA document defined these protocols clearly, and we're
happy to see the emphasis on standardizing them.  Our concern is the
lack of emphasis on standardizing PT.  The document's scope section says
that, when PA and PB are used with standard lower layer protocols, they
provide interoperability.  This may be true, but what lower layer
protocols will be used?  

	Even if an EAP method for transport of measurements is
standardized and supported by all NEA components, a client and server
must additionally support the same tunneled EAP method for
authentication in order to be interoperable. There are examples today of
different vendors who use the same access protocol (802.1x/RADIUS), but
different tunneled EAP methods, and thus cannot interoperate.  We would
like to see language clearly stating that standardization of both an
authentication protocol and a measurement transport protocol is required
for true interoperability.

	Lauren Giroux

	Chris Salter