Subject: [Nea] What's the relationship betweetn vendor-specific attributes and interoprability?

From: Yin Han <[email-masked]>
Date: Thu, 19 Oct 2006 16:46:28 +0800

Hi
  What's the relationship betweetn vendor-specific attributes and interoprability?
  In NEA architecture, more than one Posture Collector(PC) will be installed on one NEA client. Centainly, the different PC will collect informaiton about different area on the NEA client. Since NEA WG is expected to realize the interoperability between the PC and Posture Validators(PV) from dfifferent vendor, a NEA client that complies with the security policy of a network owner should get the access to the network no matter what PC is installed on it. Is it ture? 
  On the other words, a NEA client that installed PC provided by corporation_a can get the access to network of Corporation_a ,corporation_b or corporation_c if it is compliant to their policies. My question is whether this scenario is practical? Will a corpration grant the NEA client installing another corporation PC the access to its own network? 
  In my opinion, every corporation can have its own policy. So, the corporation may consider that only the PC developed by itself can provide the information it take care. In NEA Architecture,these particular informations should be classified as vendor-specific attributes. I am apprehensive that most functions would be completed through vendor-specific attributes and standard attributes are only basic information. If NEA allows too much flexibility originated from vendor-specific attributes, could we realize the interoprability between "an NEA Client from one vendor and an NEA Server from another"? 
  If a PV can not make  assessment without its own vendor-specific attributes, the NEA client must install the PC from the same vendor that provides the PV. Because there would be no such a PC that can support all kinds of vendor-specific attributes if these vendor-specific attributes are major in PA-level. Thearefore, as the the figure in requirement doccument, the PC and PV always appear in pair. Additionally, whether an endpoint could access the corporation network lies on whether the endpoint installed the PC provided by the corporation but not whether the endpoint is compliant to the corporation secutiry policy.
  Therefore, the statment should be added into the charter:"To realize interoperability, the most attributes are standard in PA-level and PV must be able to make such assessment that NEA server can permit the NEA cllient to access the network even though the PC could not provide the vendor-specific attributes." If we can not reach it, the interoperability will be impractical.
_______________________________________________
Nea mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea

---

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

>   Therefore, the statment should be added into the charter:"To realize
> interoperability, the most attributes are standard in PA-level and PV must
> be able to make such assessment that NEA server can permit the NEA cllient
> to access the network even though the PC could not provide the
> vendor-specific attributes." If we can not reach it, the interoperability
> will be impractical.

Yin, I think what your talking about is an implementation and local
policy issue, and not a interoperation issue, and therefore not really
an issue for standardization.

Whether a foreign computer is allowed to provide it's own posture
assessment is a matter of local policy for the trusting company.

That the posture collectors and posture validators can exchange
information is a matter of standardization to that point that the
formats are standardized for attribute exchange but not necessarily
the meaning of those attributes.

RADIUS attribute extensions work in a similar manner and probably
provides a decent model to work off of.

mike