draft-fitzgeraldmckay-sacm-endpointcompliance-00

Quick note about IPR There are intellectual property rights considerations associated with the Trusted Computing Group (TCG) Trusted Network Connect (TNC) specifications In the past, the TCG has been willing to donate their specification to the IETF It is important to note that the Trusted Computing Group (TCG) Trusted Network Connect (TNC) specifications has intellectual property rights (IPR) associated with them. As a result, these IPR considerations will need to be resolved prior to any specifications being submitted to the IETF. As a result, this Internet-Draft is informative in nature. With that said, in the past, the TCG has been willing to work with the IETF and contribute their specifications.

TNC Architecture Policy Enforcement Point Policy Decision Access Requestor Verifiers t Collector Integrity Measurement Collectors (IMC) Verifiers (IMV) IF-M IF-IMC IF-IMV TSS TPM Platform Trust Service (PTS) IF-PTS TNC Server (TNCS) TNC Client (TNCC) IF-TNCCS Network Access Requestor Policy Enforcement Point (PEP) Network Access Authority IF-T IF-PEP This represents the basic TNC architecture. Note that interfaces run both horizontally (between different endpoints) as well as vertically (connecting components within a single endpoint) http://www.trustedcomputinggroup.org/developers/trusted_network_connect/specifications

TNC Architecture PA-TNC PB-TNC PT-TLS PT-EAP Policy Enforcement Point Policy Decision Point Access Requestor PA-TNC Verifiers t Collector Integrity Measurement Collectors (IMC) Verifiers (IMV) IF-M IF-IMC IF-IMV TSS TPM Platform Trust Service (PTS) IF-PTS PB-TNC TNC Server (TNCS) TNC Client (TNCC) IF-TNCCS PT-TLS PT-EAP Network Access Requestor Policy Enforcement Point (PEP) Network Access Authority IF-T IF-PEP The NEA workgroup took three of the horizontal interfaces and developed compatible IETF interfaces for them http://www.trustedcomputinggroup.org/developers/trusted_network_connect/specifications

Posture Transport Client Posture Transport Server TNC Architecture Policy Enforcement Point NEA Client NEA Server PA-TNC Verifiers t Collector Integrity Measurement Collectors (IMC) Verifiers (IMV) IF-M IF-IMC IF-IMV Posture Collectors Posture Validators TSS TPM Platform Trust Service (PTS) IF-PTS PB-TNC TNC Server (TNCS) TNC Client (TNCC) IF-TNCCS Posture Broker Client Posture Broker Server PT-TLS PT-EAP Network Access Requestor Policy Enforcement Point (PEP) Network Access Authority IF-T IF-PEP Posture Transport Client Posture Transport Server It also defined NEA components compatible with the TNC components http://www.trustedcomputinggroup.org/developers/trusted_network_connect/specifications

The TNC Architecture provides the following capabilities for SACM Collection of posture attributes from an endpoint Evaluation of posture attributes against network policy or guidance A secure channel for exchanging of posture assessment information

TNC Architecture in SACM Policy Enforcement Point NEA Client NEA Server Secure Exchange of Posture Assessment Information Between Providers and Consumers SACM Evaluator (Provider/Consumer) PA-TNC Verifiers t Collector Integrity Measurement Collectors (IMC) Verifiers (IMV) IF-M IF-IMC IF-IMV Posture Collectors Posture Validators TSS TPM Platform Trust Service (PTS) IF-PTS PB-TNC TNC Server (TNCS) TNC Client (TNCC) IF-TNCCS Posture Broker Client Posture Broker Server PT-TLS PT-EAP SACM Internal Collector (Provider/Consumer) SACM Controllers Network Access Requestor Policy Enforcement Point (PEP) Network Access Authority IF-T IF-PEP Posture Transport Client Posture Transport Server This shows how the NEA components, compatible with the TNC Architecture, map to the SACM Architecture. In the SACM Architecture, NEA Posture Collectors are SACM Internal Collectors which can be either Posture Assessment Information Consumers (Cs) or Posture Assessment Information Providers (P). NEA Posture Validators are SACM Evaluators which can also be Posture Assessment Information Consumers (Cs) or Posture Assessment Information Providers (P) depending on the context in which they are used. The NEA Posture Broker Client and Posture Broker Server both facilitate the sharing of information between the client and server and provider Controller (Cr) capabilities. Lastly, the PA-TNC, PB-TNC, and PT-TLS/PT-EAP protocols provide management capabilities and a secure communication channel between Posture Assessment Providers and Posture Assessment Consumers in which to exchange Posture Assessment Information. http://www.trustedcomputinggroup.org/developers/trusted_network_connect/specifications

Still many places where additional standardization could be helpful Standardize intra-endpoint/inter-component interfaces Standardize collections and transmission of specific types of attributes Standardize bootstrap activities

TNC has standards towards these ends Standardize intra-endpoint/inter-component interfaces IF-IMC – standard interface between IMC (Posture Collector) and TNCC (Posture Broker Client) IF-IMV – standard interface between IMV (Posture Verifier) and TNCS (Posture Broker Server) Standardize collections and transmission of specific types of attributes SWID Message and Attributes for IF-M – standard behaviors for exposing endpoint SWID tag collection Standardize bootstrap activities Server Discovery and Validation – located and verify appropriate TNC (NEA) Servers

Why pull standards from TNC? xkcd: ©2011 Randal Munroe We want to avoid this!

Why pull standards from TNC? TNC already defines many parts of a security automation solution Solution is aligned with NEA… … which is aligned with SACM We don’t want to (or need to) re-invent wheels With TNC’s permission, we can extend relevant TNC specs to meet SACM needs Unification rather than bifurcation The running code is there – use what has been proven to work and fix what doesn’t There is prior art here. TNC’s security automation solution has existed for many years and been implemented in multiple tools. NEA already agreed on the utility and created a unification spec with TNC’s blessing – the NEA specs are compatible with TNC while moving the relevant capabilities forward. TNC has agreed that future evolution of the relevant standards should happen in IETF. IETF NEA codified useful standards without re-inventing TNC’s solution. Instead, the two development paths (IETF and TNC) are now unified. SACM already closely aligns with NEA. It makes sense, as SACM develops a larger security automation/continuous monitoring solution to continue on a path of unification when the opportunity exists to incorporate useful, demonstrated standards.

Proposal Request TNC submit relevant standards to SACM TNC membership appears to be receptive Within SACM, adapt the TNC standards to support aligned SACM requirements But retain compatibility with TNC to the extent appropriate Result will be significant progress towards the standards needed by the SACM architecture while unifying (rather than further bifurcating) practices