Subject: Re: [Nea] PA-subtypes

From: "Paul Sangster" <[email-masked]>
Date: Mon, 6 Oct 2008 15:09:22 -0700

Sorry for the delay, comments in-lined below. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Randy Turner
> Sent: Tuesday, September 30, 2008 9:59 PM
> To: NEA
> Subject: [Nea] PA-subtypes
> 
> 
> Hi All,
> 
> I wasn't sure if the topic of PA subtypes was still open, but I was  
> curious if anyone on the list had brought up the topic of device- 
> drivers or "kernel extensions" as a way to indicate one way of sub- 
> dividing the monolithic term "operating system".  It seems 
> reasonable  
> to assume that someone might want to update a PKCS-11 driver or some  
> other security-related kernel extension/module without 
> updating the OS  
> (from the perspective of remediation).  Would not "kernel extension"  
> be a good subtype designator for any type of uniquely identifiable/ 
> upgradeable module in a system?
> 
> At the moment, if there was a request for kernel extension  
> information, the request would have to target the "operating system"  
> subtype, which would be potentially a problem.

The idea of PA Subtypes (AKA component types) was to identify a
particular type of component on the endpoint for which a Posture
Validator might wish to assess.  These types identify a particular type
of component (e.g. anti-virus) and tried hard to stay out of how it was
implemented.  If we include something like kernel extension, this is
more oriented towards how the component was architected rather then the
function or purpose of the component.  For example, an anti-virus
component is sometimes written as a kernel module or sometimes as a
privileged user-level software or sometimes as a mixture of both.  

We would like the component type enumeration to focus on functional
components that might make sense to be included in a security assessment
of the endpoint.  If there is a type of component (you mention a PKCS 11
module - which BTW normally are implemented as user-level libraries)
this sounds closer to how we intended to use component types.  Its very
easy for us to add component types in the future so let us know if you
see the need for additional ones.

We won't be able to get additional attributes or component types in the
next revision of the PA-TNC spec as that's now complete (to be submitted
tomorrow).  Feel free to suggest additional component types for the next
revision if necessary keeping in mind the idea is functional
security-related mechanisms.

> Thanks!
> Randy
_______________________________________________
Nea mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nea

---

From: Randy Turner <[email-masked]>
Date: Mon, 6 Oct 2008 16:13:07 -0700

Ok, so what you are saying is that if we have a component type (pa- 
subtype) called "kernel-extension", then that implies how the  
"operating system" is implemented (i.e., a base image + one or more  
kernel extensions).  In other words (my words), "kernel extension"  
might be considered too "concrete" a term, or not abstract enough?

I do think that a posture validator could assess a device driver (as  
an example of a kernel module or extension).

However, if we're saying that only terminology at a sufficient level  
of abstraction should be used to identify component types, and that  
the introduction of "kernel extension" would look out of place with  
our existing documented set of component types, then I think I  
understand.

I'm wondering if I could achieve a similar support for kernel- 
extensions by requesting a list of "packages" from the "operating  
system" component type.  Would it be ok for an implementation to  
return an operating system image, and one or more kernel-extension  
names and versions as a response? Or did I misunderstand the idea of  
"packages" from the existing document?

Thanks for the reply!
Randy

---

From: "Paul Sangster" <[email-masked]>
Date: Mon, 6 Oct 2008 16:22:22 -0700

Correct, if a Posture Validator wanted to do a detailed assessment of
the Operating System it could request the Installed Packages attribute
for the Operating System component.  Of course this is likely to
generate a lot of traffic so your PT would need to be able to handle
this amount of data (something like TLS session could clearly handle
it). 

> Sent: Monday, October 06, 2008 4:13 PM
> To: NEA
> Subject: Re: [Nea] PA-subtypes
> 
> 
> > of component (e.g. anti-virus) and tried hard to stay out 
> of how it  
> > was
> > more oriented towards how the component was architected 
> rather then  
> > the
> > We won't be able to get additional attributes or component 
> types in  
> > the
> > tomorrow).  Feel free to suggest additional component types 
> for the  
> > next