1. draft-fitzgeraldmckay-sacm-endpointcompliance-00

2. 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.

3. 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)

4. 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

5. 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

6. 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

7. 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.

8. 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

9. 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

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

11. 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.

12. 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