ECP Specification Recommendations to the SACM WG

Specification	Recommendation
IETF NEA PA-TNC (RFC 5792)	Adopt
IETF NEA PB-TNC (RFC 5793)	Adopt
IETF NEA PT-TLS (RFC 6876)	Adopt
TCG TNC SWID Message and Attributes for IF-M	Adopt if PA-TNC is adopted
TCG TNC IF-IMC / IF-IMV	Adopt if PA-TNC and PB-TNC are adopted
TCG TNC Server Discovery and Validation	Adopt if PB-TNC is adopted
TCG NEA PT-EAP (RFC 7171)	Do not adopt

2. NEA PA-TNC

PA-TNC [RFC5792] is a Posture Attribute (PA) protocol that is part of the NEA specifications and compatible with TNC, and which carries attributes between Posture Collectors and their corresponding Posture Validators.

2.1. Alignment with SACM

The PA-TNC protocol is a highly-extensible, lightweight protocol that is free of intellectual property rights concerns and compatible with the TNC IF-M protocol, which has been adopted by members of industry [TNC-FAQ]. It carries attributes between Posture Collectors on an endpoint and their corresponding Posture Validators on a server. Designed with extensibility in mind, PA-TNC supports the development of standard and vendor-specific extensions to carry new types of messages and attributes. This is critical for SACM as it enables the standardization of common messages and attributes as well as provides vendors with opportunities to add value and differentiate their products from other vendors. Furthermore, the TCG TNC SWID Messages and Attributes for IF-M [SWID-Messages] specification demonstrates how PA-TNC can be extended to support data like Software Identification (SWID) tag data [ISO.19770-2]. Lastly, the PA-TNC protocol utilizes a type-length-value (TLV) based encoding to support low-power and low-bandwidth networks which are in scope for SACM.

With that said, the PA-TNC protocol likely needs some enhancements to satisfy the level of detail required for SACM. Most notably, PA-TNC provides a basic data model for collection guidance, posture attributes, and assessment results which need to be enhanced to provide the level of detail needed by SACM (caveat: guidance, attributes, and results are not fully specified in [I-D.ietf-sacm-information-model]). To expand further on this:

• PA-TNC provides a data model for collection guidance via the PA subtypes. This is simple and elegant especially if vendors continue to define how to collect the particular information off of their platforms and define what the data looks like. However, it must also be considered how this guidance might be modified, if at all, to support remote data collection.
• PA-TNC provides a data model for attributes via its "posture attribute" TLV format which includes the posture attribute type, length, and value among other fields. It must be considered whether or not this format contains all the metadata SACM cares about to enable an organization to make assertions about the provenance of that data.
• PA-TNC provides a data model by which to express the results of an assessment via the "assessment result" attribute. Specifically, it provides results based on one of five values (expressed as a 32-bit value) which indicate whether or not the endpoint was compliant or if a Posture Validator was unable to carry out the assessment for a particular reason. While this provides a basic, high-level result of the assessment, SACM also wants the ability support detailed results (e.g. what failed and why, etc.) as well as metadata about the results so that it can drive follow-up actions.

Lastly, PA-TNC includes capabilities for remediation and network access control that are currently out-of-scope for SACM and likely need to be removed. Fortunately, due to the modular nature of this protocol, these capabilities can be easily removed without requiring significant changes to the specification or impacting other capabilities.

Most of the noted issues represent relatively minor modifications to the PA-TNC specification. On the other hand, PA-TNC directly aligns closely with many of the core requirements and provides one of the central SACM capabilities, namely the ability to gather and deliver endpoint attributes. Therefore, the PA-TNC protocol is given a rating of 3.

2.2. Potential Use in SACM

PA-TNC provides a protocol that can satisfy the need of SACM to exchange posture assessment information between its architectural components. However, unlike NEA which restricts the communication to just Posture Collectors and Posture Validators and vise-versa, SACM supports both direct and indirect (via a SACM Controller) communication between any SACM Component which could violate this restriction. As a result, this restriction would likely need to be removed if the WG decides to use the NEA protocols beyond supporting the endpoint self-reporting use case.

Furthermore, SACM likely needs to extend the list of attribute types to support other types of posture assessment information and their respective data models. For example, the policy used by Posture Validators to evaluate posture attributes, collected from an endpoint, is left as an implementation detail. SACM may want to define a data model for evaluation guidance and transport it via PA-TNC (e.g. from a guidance repository) so that this process could be handled in a standardized way.

In the event that SACM wants to use PA-TNC as a standalone protocol (i.e. without the rest of the NEA protocol stack), it would require the selection of another protocol to route messages between SACM Components as well as another protocol to secure the exchange of those messages over the wire.

2.3. Priority

The SACM charter states that the working group will produce "a standards-track document specifying a protocol and data format for collecting actual endpoint posture". Given that the PA-TNC protocol satisfies this SACM deliverable and provides a mechanism for collecting and reporting attributes which is critical to SACM, the priority for sending the protocol to the SACM WG is HIGH. Furthermore, without such a protocol, the interoperability between vendor products will be severely limited and likely result in end-to-end, single-vendor solutions.

2.4. Recommendation

Given the extensible nature of the PA-TNC protocol to support new data models including those previously discussed in SACM (SWID, etc.) and the fact it could be used with only minor modifications, the SACM WG should at a minimum adopt the protocol for carrying posture assessment information from a SACM Internal Collector to a SACM Evaluator.

3. NEA PB-TNC

PB-TNC [RFC5793] is a Posture Broker (PB) protocol that is part of the NEA specifications and compatible with TNC, and which routes the exchange of posture assessment information messages between an endpoint and a server.

3.1. Alignment with SACM

PB-TNC is a highly-extensible, lightweight protocol that is free of intellectual property rights concerns and is compatible with the TNC IF-TNCCS protocol which has been adopted by members of industry [TNC-FAQ]. It provides a standard mechanism by which to route messages between Posture Collectors and Posture Validators independently of the message contents. Specifically, Posture Collectors and Posture Validators can subscribe to the Posture Broker Client and Posture Broker Server respectively and register to receive messages of a particular type. As a result, it is very easy to extend PA-TNC and dynamically add new Posture Collectors and Posture Validators without having to modify PB-TNC. Direct communication between a specific Posture Collector and Posture Validator is also supported. The PB-TNC protocol also utilizes a type-length-value (TLV) based encoding as well as both half and full duplex communications which is useful to support low-power and low-bandwidth networks which are in scope for SACM.

Similar to PA-TNC, PB-TNC also includes capabilities such as remediation and network access control that are currently out-of-scope for SACM. Again, due to the modular nature of the protocol, these capabilities can be easily removed without significant changes to the specification or impacting other capabilities. Given that PB-TNC is largely content-agnostic and focuses on data routing, it does not come into conflict with most SACM requirements which tend to be focused the data itself. As a result, this specification requires very little modification.

Since the PB-TNC protocol directly aligns with SACM in that it is extensible, provides a key capability in routing messages between an endpoint and server, and requires only a very minor modification in the form of removing some out-of-scope capabilities, it is given a rating of 3.

3.2. Potential Use in SACM

Currently, PB-TNC only routes messages between Posture Collectors and Posture Validators which satisfies the endpoint self-reporting use case. However, if SACM plans to use PB-TNC beyond this use case, the protocol will need to be extended to route messages to other types of SACM Components. It may be possible to just leverage the Posture Collector and Posture Validator Identifier fields in some type of source and destination fashion.

In addition to the general routing of messages between Posture Collectors and Posture Validators, PB-TNC is responsible for transporting the global assessment result computed by the Posture Broker Server to the Posture Broker Client for further action. Furthermore, the global assessment result is potentially computed using the assessment results from the applicable Posture Validators. In SACM, the computation of assessment results should at a minimum be delegated to an evaluation function and possibly standardized to ensure consistent assessment results across different products. Additionally, further action based on the assessment results should be left as an implementation detail for vendors as it is out-of-scope for SACM. That is, the expectation for the Posture Collector to handle assessment results and remediation instructions should not be enforced.

The PB-TNC protocol also assumes a very specific state machine regarding the transmission of messages. This should be reviewed to ensure it aligns with the needs of SACM.

Lastly, if SACM decides to use PB-TNC outside of the NEA protocol stack, new protocols and data formats are necessary to exchange posture assessment information between SACM Components as well as provide a secure communication channel between them.

3.3. Priority

The SACM charter states that the working group will produce "a standards-track document specifying a protocol and data format for collecting actual endpoint posture". While PB-TNC does not directly share posture assessment information, it does facilitate the transfer of posture assessment information by carrying protocols such as PA-TNC between endpoints and routing the messages to the appropriate Posture Collectors and Posture Validators. Given that the PB-TNC protocol supports this deliverable and the routing of messages between an endpoint and a server which is essential for SACM, the priority for sending the protocol to the SACM WG is HIGH. Like PA-TNC, without such a protocol, the interoperability between vendor products will be severely limited as Posture Collectors and Posture Validators will not have a common way to communicate with each other.

3.4. Recommendation

Given the extensible nature of the PB-TNC protocol to support new protocols to communicate posture assessment information between Posture Collectors and Posture Validators and the fact it can operate independently of the underlying protocol used to ensure a secure communication channel, the SACM WG should at a minimum adopt the PB-TNC protocol for routing posture assessment information messages between a SACM Internal Collector to a SACM Evaluator.

4. NEA PT-TLS

PT-TLS [RFC6876] is a Posture Transport (PT) protocol that carries posture assessment messages over a Transport Layer Security (TLS) tunnel. It is part of the NEA specifications and is compatible with the TNC PT-TLS specification.

4.1. Alignment with SACM

PT-TLS is an extensible, lightweight protocol to securely exchange posture assessment information between a NEA Client and NEA Server after the NEA Client has gained access to a network. It is free of intellectual property rights concerns and is compatible with the TNC IF-T Binding to TLS protocol which is adopted by industry [TNC-FAQ]. PT-TLS provides authentication, integrity, and confidentiality of data communicated over the PB-TNC protocol. To do so, PT-TLS leverages the existing TLS protocol, which is already widely adopted. It also operates independently of the protocol it carries (e.g. PB-TNC) and can be extended to support message types used by other protocols. With regards to authentication, PT-TLS provides an authenticated endpoint identity which enables other components in the NEA architecture [RFC5209] to know which component they are communicating with. Lastly, PT-TLS uses a type-length-value encoding which supports low-power endpoints and low-bandwidth networks which are in scope for SACM as well as high-bandwidth, bi-directional communication, and large messages.

Since the PT-TLS protocol provides a secure communication channel that satisfies the needs of SACM and is agnostic to the data it is carrying, there are no points of divergence with respect to the alignment with SACM.

Given the PA-TNC protocol directly aligns with SACM by providing an extensible mechanism by which to securely exchange posture assessment messages and does not require any modifications, it is given a rating of 3.

4.2. Potential Use in SACM

PT-TLS provides SACM with a protocol that can be used to secure the exchange of posture assessment information. SACM can decide to leverage PT-TLS with or without the PA-TNC and PB-TNC protocols. In the absence of the using the PA-TNC and PB-TNC protocols, new protocols would need to be specified or PT-TLS would need to carry the data directly and the PT-TLS protocol would need to be extended to support new messages types. For example, there is currently a PB-TNC Batch message type for PB-TNC batches. If a new Protocol-XYZ is used, a Protocol-XYZ message type would be required.

4.3. Priority

The SACM charter states that the working group will produce a deliverable that is "a standards-track document specifying a protocol and data format for collecting actual endpoint posture". While PT-TLS does not directly share posture assessment information, it does ensure posture assessment information carried over protocols such as PA-TNC and PB-TNC is done so over a secure communication channel. Specifically, it does so by providing mechanisms that ensure authentication, integrity, and confidentially of the data being shared. Since it supports this SACM deliverable, satisfies the need to securely exchange posture assessment information, and provides a mechanism for endpoint identity, all of which are critical for SACM, the priority for sending the PT-TLS protocol to SACM is HIGH. Without such a protocol, the interoperability between vendor products will be severely limited and sensitive posture information sent over a network may not be adequately protected.

4.4. Recommendation

Given the extensible nature of the PT-TLS protocol and its ability to carry other protocols such as PA-TNC and PB-TNC over a secure communication channel, the SACM WG should at a minimum adopt the PT-TLS protocol for securing the exchange of posture assessment information messages between a SACM Internal Collector and a SACM Evaluator.

5. TCG TNC SWID Message and Attributes for IF-M

TNC SWID Message and Attributes for IF-M is an extension of the IF-M protocol to support the exchange of ISO Software Identification (SWID) tags. It is compatible with the NEA architecture, but is not itself part of the NEA specifications.

5.1. Alignment with SACM

TNC SWID Message and Attributes for IF-M is an extension of the IF-M protocol to support the exchange of ISO Software Identification (SWID) tags and the events involving those tags. Unlike the IETF NEA specifications, TNC SWID Message and Attributes for IF-M is not free of intellectual property rights concerns as it is owned by the TCG. With that said, in the past, the TCG has been willing to allow interested parties to create compatible specifications in the IETF and commit to update their specifications to align with the IETF specifications (e.g. IF-M, IF-TNCCS, IF-T TLS/EAP). Since PA-TNC and IF-M are compatible specifications, the SWID Message and Attributes for IF-M specification should be straightforward for PA-TNC to support SWID tags if not a drop-in extension.

Furthermore, the TNC SWID Message and Attributes for IF-M specification satisfies key SACM use cases (software inventory, endpoint characterization, vulnerability management, etc.) by providing a standard protocol for exchanging detailed software inventory data that is expressed using a standard data model (ISO SWID tag). It also mandates that a SWID Posture Collector, in near real-time, detect changes in the software inventory of an endpoint (creation of tags, deletion of tags and alteration of tags). These detected changes can then be sent to the appropriate destination whether it be a SWID Posture Validator or a central repository. Change detection on an endpoint is a critical capability for SACM. Given the focus of this specification on change detection on the endpoint, it best supports the endpoint self-reporting use case of SACM.

Since TNC SWID Message and Attributes for IF-M addresses key SACM use cases including software inventory, endpoint characterization, and vulnerability management using a standard data model in SWID tags and without modification, it is given a rating of 3.

5.2. Potential Use in SACM

For the most part, SACM should be able to leverage the SWID Message and Attributes for IF-M specification as-is to support its software asset management use case as it supports the use of either a central repository or federated repositories. However, like PA-TNC, SACM needs to determine if the specification contains all the metadata needed to enable an organization to make assertions about the provenance of that data.

SACM could also decide to use the SWID Message and Attributes for IF-M as a standalone protocol (i.e. without PB-TNC, PT-TLS, or PT-EAP), however, it would require the selection of another protocol to route messages between SACM Components as well as a protocol to secure the exchange of those messages over the wire. Of course, in this situation, PA-TNC is required as SWID Message and Attributes for IF-M is an extension for it.

5.3. Priority

Software inventory data is critical to achieving SACM's use cases. The ability to share this software inventory data using a standard data format over a standard protocol enables interoperability among vendor products. Furthermore, it serves as a model for future extensions to PA-TNC to support other data models. As a result of these capabilities, the priority for sending the TNC SWID Message and Attributes for IF-M specification to SACM is HIGH.

5.4. Recommendation

Given the SWID Message and Attributes for IF-M specification is compatible with PA-TNC and utilizes SWID tags in a way that enables the monitoring of software inventory events in a standardized way, it should be adopted by the SACM WG if PA-TNC is also adopted by the SACM WG.

6. TCG TNC IF-IMC / IF-IMV

TNC IF-IMC [IF-IMC] and IF-IMV [IF-IMV] provide standard interfaces by which Posture Collectors can interact with a Posture Broker Client and Posture Validators can interact with a Posture Broker Server. IF-IMC and IF-IMV are not part of the NEA standards, but are compatible with the NEA architecture.

6.1. Alignment with SACM

TNC IF-IMC and IF-IMV provide standard, extensible interfaces by which Posture Collectors can interact with a Posture Broker Client and a Posture Validator can interact with a Posture Broker Server . Specifically, these interfaces support the passing and routing of attributes between the PA-TNC layer of the TNC/NEA architecture, and the PB-TNC layer within a single endpoint or server. This allows flexibility in the addition of Posture Collectors and Posture Validators, allowing easy addition or removal of such components. These specifications are extensible through the definition of vendor-specific functions and are both programming language and platform independent, which aligns with SACM's desire to support all types of endpoints. TNC IF-IMC and IF-IMV also support batching of endpoint attribute transmission, which is ideal for low-power endpoints and low-bandwidth networks which are in scope for SACM. Unlike the IETF NEA specifications, TNC IF-IMC and IF-IMV are not free of intellectual property rights concerns as they are owned by the TCG. With that said, in the past, the TCG has been willing to allow interested parties to create compatible specifications in the IETF and commit to update their specifications to align with the IETF specifications (e.g. IF-M, IF-TNCCS, IF-T TLS/EAP).

TNC IF-IMC and IF-IMV also include capabilities such as remediation and network access control that are out-of-scope for SACM. Again, due to the modular nature of the protocol, these capabilities can be easily removed without significant changes to the specification or impacting other capabilities.

Given that the TNC IF-IMC and IF-IMV interfaces directly align with SACM in that they provide a mechanism by which Posture Collectors and Posture Validators can easily be added to the assessment infrastructure and can do so with relatively minor modifications, these specifications are given a rating of 3.

6.2. Potential Use in SACM

The TNC IF-IMC and IF-IMV interfaces should plug into the SACM architecture with little change assuming PA-TNC, PB-TNC, and PT-TLS/PT-EAP are adopted by SACM. These interfaces should remain stable as new data models are supported (vendor-specific functions notwithstanding) as these extensions impact the higher level protocols and the messages are not interpreted by the interfaces.

The TNC IF-IMC and IF-IMV interfaces also assume a very specific state machine regarding the transmission of messages. This should be reviewed to ensure it aligns with the needs of SACM.

6.3. Priority

SACM wants to standardize the interfaces between SACM Components to ensure interoperable communication. These interfaces provide standard interfaces between Posture Collectors and a Posture Broker Client and Posture Validators and a Posture Broker Server which is currently left as an implementation detail in NEA. Most importantly, these standard interfaces reduce the level-of-effort needed to develop and deploy new Posture Collectors and Posture Validators which is vital to keep pace with the rapidly changing platforms and ever-evolving security landscape. As a result, the priority for submitting these specifications the SACM WG is HIGH.

6.4. Recommendation

The SACM WG should adopt the TNC IF-IMC and IF-IMV specifications if they adopt the PA-TNC and PB-TNC protocols as they standardize the interfaces between the Posture Collector and the Posture Broker Client and the Posture Validator and the Posture Broker Server. By doing so, they promote additional opportunity for interoperability among vendor products which would otherwise resort to proprietary solutions.

7. TCG TNC Server Discovery and Validation

TNC Server Discovery and Validation [Server-Discovery] provides endpoints with a mechanism by which an endpoint can discover the presence of servers on the network and determine if they can be trusted. Server Discovery and Validation is not part of the NEA specifications, but is compatible with the NEA architecture.

7.1. Alignment with SACM

TNC Server Discovery and Validation is an extensible specification that is currently under development in the TCG. At the time of this document, the specification is in the public comment phase of the development lifecycle. The specification provides endpoints with a mechanism to locate servers (TNC Policy Decision Points, NEA Servers, vendor-specific, etc.) and ensure that they are trusted before sending sensitive posture information to them. Discovery can occur either through the use of DNS SRV records or through a specific PB-TNC message type. Furthermore, it can be extended to support different types of servers, server identifiers, and trust parameters. By leveraging existing protocols such as PB-TNC, DNS, etc., TNC Server Discovery and Validation increases the likelihood of adoption when the final version is published. Similar to other TCG specifications, TNC Server Discovery and Validation is not free of intellectual property rights concerns. However, in the past, the TCG has been willing to allow interested parties to create compatible specifications in the IETF and commit to update their specifications to align with the IETF specifications (e.g. IF-M, IF-TNCCS, IF-T TLS/EAP).

While the ability to discover and validate servers is well supported for the use case where endpoints self-report their posture assessment information, it will take some work to support SACM use case beyond this such as where on the network a SACM Component should go to retrieve a specific piece of information. As a result, this specification is given a rating of 2.

7.2. Potential Use in SACM

TNC Server Discovery and Validation provides an excellent starting point, however, SACM may want to consider extending the specification in a few ways to address its needs. First, there is no standard interface for sharing the referral information obtained via server discovery with the component on the endpoint that is responsible for actually establishing a connection to the server that it was referred to. SACM may want to develop this interface so it is not left as an implementation detail.

Second, SACM may want to support additional server types which is easily done via the extensible nature of the server type field. Given that SACM follows more of a peer-to-peer model where each SACM Component can communicate with each other, it probably makes sense to include a server type for each type of SACM Component.

The specification also uses IPv4, IPv6, and FQDN to identify servers. SACM supports these identifiers (now called designation attributes) although FQDN is no longer mandatory-to-implement in [I-D.ietf-sacm-information-model]. Once [I-D.ietf-sacm-information-model] is complete, the mandatory-to-implement list of identifiers in TNC Server Discovery and Validation should be brought into alignment.

Lastly, the specification permits the development of more complex server validation trust computations that go beyond a simple binary result (i.e., "trusted" or "not trusted"). SACM may want to extend the trust parameters, in a standard way, to carry out role and context based authorizations of SACM Components (i.e., "trusted for purpose X", "trusted for purpose Y", etc.).

7.3. Priority

SACM needs a mechanism for SACM Components to locate other SACM Components and ensure they are trusted prior to requesting or providing posture assessment information. In the long term, hard-coded discovery and validation capabilities are not scalable, but given the scope and progress of SACM, it might make sense to start with hard-coded discovery and validation capabilities until a basic set of data formats and protocols, for exchanging posture assessment information, are adopted. Once a few data formats and protocols are supported, this specification provides a great starting point by which SACM can further develop these discovery and validation capabilities in a standardized way. As a result, this specification is given a priority of MEDIUM.

7.4. Recommendation

The SACM WG should adopt the TNC Server Discovery and Validation if PB-TNC is adopted by SACM for the endpoint self-reporting use case after protocols for securely exchange posture assessment information have been adopted.

8. IETF NEA PT-EAP

PT-EAP [RFC7171] is a Posture Transport (PT) protocol that carries posture assessment messages over an Extensible Authentication Protocol (EAP) tunnel. It is part of the NEA specifications and is compatible with the TNC architecture.

8.1. Alignment with SACM

PT-EAP is an extensible, lightweight protocol to securely exchange posture assessment information between a NEA Client and NEA Server prior to assignment of an IP address. It is free of intellectual property rights concerns and is compatible with the TNC IF-T Protocol Bindings for Tunneled EAP Methods protocol which is adopted by industry [TNC-FAQ]. PT-EAP provides authentication, integrity, and confidentiality of data communicated over the PB-TNC protocol. To do so, PT-EAP leverages existing EAP tunnels such as EAP-FAST and EAP-TTLS. It also operates independently of the protocol it carries (e.g. PB-TNC) and can be extended to support message types used by other protocols. With regards to authentication, like PT-TLS, PT-EAP provides an authenticated endpoint identity which enables other components in the NEA architecture to know which component they are communicating with. Lastly, PT-EAP uses a type-length-value encoding which supports low-power endpoints and low-bandwidth networks which are in scope for SACM as well as high-bandwidth, bi-directional communication, and large messages.

While the PT-EAP protocol aligns with SACM by providing an extensible mechanism by which to securely exchange posture assessment messages, it focuses on the communication prior to an endpoint joining a network which is out-of-scope for SACM. As a result, it is given a rating of 1.

8.2. Potential Use in SACM

PT-EAP provides SACM with a protocol that can be used to secure the exchange of posture assessment information prior to an endpoint joining a network. SACM can decide to leverage PT-EAP with or without the PA-TNC and PB-TNC protocols. In the absence of using the PA-TNC and PB-TNC protocols, new protocols would need to be specified or PT-EAP would need to directly carry the data.

8.3. Priority

The SACM charter states that the working group will produce "a standards-track document specifying a protocol and data format for collecting actual endpoint posture". While PT-EAP provides mechanisms that ensure authentication, integrity, and confidentially of the posture assessment information being shared, it primary use is for prior to an endpoint gaining access to he a network. This is a useful for network access control capabilities, however, network access control is not something that SACM plans to standardize at this time. As a result, the priority for this protocol is LOW.

8.4. Recommendation

Although the PT-EAP protocol provides a mechanism to securely exchange posture assessment information, SACM is not currently addressing the scenario involving endpoints prior to joining the network. As a result, the PT-EAP protocol should not be adopted by SACM at this time. However, if SACM decides to address this scenario in the future, the PT-EAP protocol should definitely be considered for inclusion.

9. Conclusion

The TNC Endpoint Compliance Profile identifies several extensible specifications that are in use today and align with the many of the architectural and protocol needs of SACM. While these specifications do not provide a complete solution for SACM, this document shows how many of the specifications, sometimes with modifications, support the use case where an endpoint self-reports its posture assessment information to a server very well and would serve as an excellent starting point for SACM. Please consider these recommendations when deciding if the ECP specifications make sense for the SACM WG to adopt. If there is consensus around adopting these specifications, a formal request will be made to the TCG to resolve any relevant outstanding IPR concerns.

10. IANA Considerations

This memo includes no request to IANA.

11. Security Considerations

This memo documents high-level recommendations for which TCG ECP specifications might be most productively brought into the IETF SACM WG. It is for informational purposes only. As a result, there are no specific security considerations.

12. Informative References

, "

[Endpoint-Compliance-Profile]	Trusted Computing Group, "TNC Endpoint Compliance Profile Specification, Version 1.0", December 2014.
[I-D.fitzgeraldmckay-sacm-endpointcompliance]	Fitzgerald-McKay, J., "Endpoint Compliance Standard", Internet-Draft draft-fitzgeraldmckay-sacm-endpointcompliance-00, May 2015.
[I-D.haynes-sacm-ecp-mapping]	Coffin, C., Haynes, D., Schmidt, C. and J. Fitzgerald-McKay, "SACM ECP Mapping", Internet-Draft draft-haynes-sacm-ecp-mapping-00, July 2015.
[I-D.ietf-sacm-information-model]	Waltermire, D., Watson, K., Kahn, C. and L. Lorenzin, "SACM Information Model", Internet-Draft draft-ietf-sacm-information-model-02, July 2015.
[IF-IMC]	Trusted Computing Group, "TCG Trusted Network Connect TNC IF-IMC, Version 1.3", February 2013.
[IF-IMV]	Trusted Computing Group, TCG Trusted Network Connect TNC IF-IMV, Version 1.4", December 2014.
[ISO.19770-2]	Information Technology -- Software Asset Management -- Part 2: Software identification tag", ISO/IEC 19770-2, 2009.
[RFC5209]	Sangster, P., Khosravi, H., Mani, M., Narayan, K. and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008.
[RFC5792]	Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010.
[RFC5793]	Sahita, R., Hanna, S., Hurst, R. and K. Narayan, "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5793, DOI 10.17487/RFC5793, March 2010.
[RFC6876]	Sangster, P., Cam-Winget, N. and J. Salowey, "A Posture Transport Protocol over TLS (PT-TLS)", RFC 6876, DOI 10.17487/RFC6876, February 2013.
[RFC7171]	Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP) Tunnel Methods", RFC 7171, DOI 10.17487/RFC7171, May 2014.
[RFC7632]	Waltermire, D. and D. Harrington, "Endpoint Security Posture Assessment: Enterprise Use Cases", RFC 7632, DOI 10.17487/RFC7632, September 2015.
[Server-Discovery]	Trusted Computing Group, "DRAFT: TCG Trusted Network Connect PDP Discovery and Validation, Version 1.0", August 2013.
[SWID-Messages]	Trusted Computing Group, "DRAFT: TCG Trusted Network Connect SWID Message and Attributes for IF-M, Version 1.0", March 2015.
[TNC]	Trusted Computing Group, "TCG Trusted Network Communications TNC Architecture for Interoperability, Version 1.5", February 2012.
[TNC-FAQ]	Trusted Computing Group, "TCG Trusted Network Communications FAQ", October 2015.

Authors' Addresses