Re: [sacm] ECP, SWID M&A for PA-TNC, and OVAL Internet-Drafts Now Available

["Haynes, Dan" <[e-mail]>]

Hi Everyone,



You may recall that the planned roadmap for work in IETF SACM (see below) includes the submission of the TNC IF-IMC [1] and IF-IMV [2] specifications. While we continue to feel that IF-IMC and IF-IMV are valuable components in the overall SACM solution, in light of the recent deluge of I-Ds we unloaded on the WG :), we thought it might make sense to delay the release of those specifications until the group has had more time to make progress on the current set of I-Ds. To support this, we are proposing that we remove normative requirements to IF-IMC and IF-IMV from the ECP [3] and SWID Message and Attributes for PA-TNC [4] specifications to avoid references to non-existing I-Ds.



In ECP, this removes general requirements to "conform to IF-IMC and IF-IMV". The only specific functionality cited in either of these specs is the procedure for extracting an endpoint ID from a machine certificate sent via PT-TLS or PT-EAP. (Section 5.1.2) In SWID Message and Attributes for PA-TNC, IF-IMV/IF-IMC are referenced with regard for requirements for the use of unique identifiers for Posture Collectors and Posture Validators. In fact, PB-TNC specifies rules regarding the creation and conveyance of these identifiers. The only role of IF-IMC and IF-IMV is to specify the functions by which those identifiers are conveyed from the PB layer to the PA layer on a client or server, respectively.



In both cases, we feel that dropping the normative requirements to use IF-IMV and IF-IMC does not have any impact on interoperability between devices. (Not surprising since IF-IMV and IF-IMC as written standardize intra-device communication.)



Does this seem like a reasonable approach?  Are there any concerns with this approach?  Please let me know if you have any questions.



Thanks,



Danny



[1] http://www.trustedcomputinggroup.org/resources/tnc_ifimc_specification

[2] http://www.trustedcomputinggroup.org/resources/tnc_ifimv_specification

[3] https://datatracker.ietf.org/doc/draft-haynes-sacm-ecp/

[4] https://datatracker.ietf.org/doc/draft-coffin-sacm-nea-swid-patnc/


From: sacm [mailto:[e-mail]] On Behalf Of Haynes, Dan
Sent: Monday, March 07, 2016 2:47 PM
To: [e-mail]
Subject: [sacm] ECP, SWID M&A for PA-TNC, and OVAL Internet-Drafts Now Available

Internet-Drafts (I-Ds) for the Endpoint Compliance Profile (ECP) [1], SWID Message and Attributes for PA-TNC [2], and the Open Vulnerability and Assessment Language (OVAL)[3-10] have just been submitted to SACM.
These I-Ds represent the first round of protocols and data models necessary to repurpose the Network Endpoint Assessment (NEA) architecture [11] from its original comply-to-connect focus to an extensible framework for collecting, communicating, and evaluating endpoint information as described in the Endpoint Compliance Standard [12]. Furthermore, these I-Ds support critical functionality in the SACM Vulnerability Assessment Scenario [13] and the "Endpoint Posture Attribute Value Collection" and "Define, Publish, Query, and Retrieve Security Automation Data" use cases from the SACM Endpoint Security Posture Assessment: Enterprise Use Cases [14].
Additional I-Ds based on existing work in the Trusted Computing Group's (TCG) Trusted Network Communications (TNC) subgroup, and which build upon the IETF's Network Endpoint Assessment (NEA) standards are currently being converted to I-Ds and will be submitted as soon as they are ready. The specific I-Ds and expected submission dates are as follows.

*         PC-TNC: An interface between NEA Posture Collectors and a NEA Posture Broker Client based on the TCG TNC IF-IMC specification [15] (Virtual Interim after IETF 95)

*         PV-TNC: An interface between NEA Posture Validators and a NEA Posture Broker Server based on the TCG TNC IF-IMV specification [16] (IETF 96)

*         Server Discovery and Validation: A protocol that enables endpoints to discover servers and ensure that they are trusted based on the TCG TNC PDP Discovery and Validation specification [17] (Virtual Interim after IETF 96)
The ECP describes how the NEA architecture can be used to collect software inventory from endpoints and make it available for later use by other security tools. These steps play a critical role in the operations described in the SACM Vulnerability Assessment Scenario. The ECP identifies specific Network Endpoint Assessment (NEA) capabilities that are used in support of these actions.
The SWID Message and Attributes for PA-TNC I-D is an extension to PA-TNC that describes a specific data-gathering capability that supports monitoring and collection of SWID tags on an endpoint. This capability is referenced in the ECP. The SWID Message and Attributes for PA-TNC I-D not only fulfills the role of standardizing the collection and delivery of this type of endpoint information, but it also provides a concrete example of the flexible collection capabilities supported by the NEA architecture. NEA provides an extensible framework for collectors on an endpoint. As new types of information are needed from an endpoint, new collectors and data models can be incorporated into the existing NEA collection protocol framework. This allows a single framework by which all endpoint information of interest can be delivered, instead of the current practice of requiring multiple endpoint agents, each responsible for their own types of data.
The OVAL I-Ds provide data models that support the assessment of endpoint posture attributes. More specifically, it provides concepts and lessons learned to inform the development of simpler, more scalable data models critical to SACM including: guidance to drive collectors; posture attributes to represent endpoint configuration information; guidance to drive evaluators; and results to express the outcome of the analysis between collected endpoint information and evaluation guidance. While not explicitly referenced in the ECP, the data models that evolve out of OVAL are complementary and simply represent another type of information that can be transported via PA-TNC and the NEA architecture, although full integration would require a new extension to PA-TNC.
In summary, the recent submissions:

-          Provide standardized means to meet important SACM use cases and scenarios

-          Support functionality through the use of existing IETF standards rather than through the creation of new, duplicative capabilities

-          Demonstrate the critical NEA feature of extensible collection capabilities
Please consider this message as a formal request for the WG to review these I-Ds, provide feedback, and help us develop them to address SACM's needs. Given the number of I-Ds that have been submitted, we would suggest reviewing them in the following order.

1.       Endpoint Compliance Profile

2.       SWID Message and Attributes for PA-TNC

3.       OVAL and the SACM Information Model Mapping

4.       OVAL Definitions Model

5.       OVAL System Characteristics Model

6.       OVAL Processing Model

7.       OVAL Common Model and OVAL Variables Model

8.       OVAL Results Model and OVAL Directives Model
Please let me know if you have any questions.
Thanks,

Danny

[1] https://datatracker.ietf.org/doc/draft-haynes-sacm-ecp/
[2] https://datatracker.ietf.org/doc/draft-coffin-sacm-nea-swid-patnc/
[3] https://datatracker.ietf.org/doc/draft-hansbury-sacm-oval-info-model-mapping/
[4] https://datatracker.ietf.org/doc/draft-cokus-sacm-oval-common-model/
[5] https://datatracker.ietf.org/doc/draft-haynes-sacm-oval-definitions-model/
[6] https://datatracker.ietf.org/doc/draft-rothenberg-sacm-oval-sys-char-model/
[7] https://datatracker.ietf.org/doc/draft-cokus-sacm-oval-results-model/
[8] https://datatracker.ietf.org/doc/draft-haynes-sacm-oval-variables-model/
[9] https://datatracker.ietf.org/doc/draft-rothenberg-sacm-oval-directives-model/
[10] https://datatracker.ietf.org/doc/draft-haynes-sacm-oval-processing-model/
[11] https://datatracker.ietf.org/doc/rfc5209/
[12] https://datatracker.ietf.org/doc/draft-fitzgeraldmckay-sacm-endpointcompliance/
[13] https://datatracker.ietf.org/doc/draft-coffin-sacm-vuln-scenario/
[14] https://datatracker.ietf.org/doc/rfc7632/
[15] http://www.trustedcomputinggroup.org/resources/tnc_ifimc_specification
[16] http://www.trustedcomputinggroup.org/resources/tnc_ifimv_specification
[17] http://www.trustedcomputinggroup.org/files/resource_files/3D59FB5E-1A4B-B294-D0F322A08B48E02E/Server_Discovery_And_Validation_v1_0r19-PUBLIC%20REVIEW.pdf