One document matched: draft-haynes-sacm-ecp-recommendations-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC5209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5209.xml">
<!ENTITY RFC5792 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5792.xml">
<!ENTITY RFC5793 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5793.xml">
<!ENTITY RFC6876 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6876.xml">
<!ENTITY RFC7171 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7171.xml">
<!ENTITY RFC7632 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7632.xml">
<!ENTITY I-D.ietf-sacm-information-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sacm-information-model.xml">
<!ENTITY I-D.fitzgeraldmckay-sacm-endpointcompliance SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.fitzgeraldmckay-sacm-endpointcompliance.xml">
<!ENTITY I-D.haynes-sacm-ecp-mapping SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-haynes-sacm-ecp-mapping-00.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="no" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-haynes-sacm-ecp-recommendations-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="SACM ECP Recommendations">SACM ECP Recommendations</title>
<!-- Another author who claims to be an editor -->
<author fullname="Daniel Haynes" initials="D.H." surname="Haynes">
<organization>The MITRE Corporation</organization>
<address>
<postal>
<street>202 Burlington Road</street>
<!-- Reorder these if your country does things differently -->
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>USA</country>
</postal>
<phone/>
<email>dhaynes@mitre.org</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<!-- Another author who claims to be an editor -->
<author fullname="Charles Schmidt" initials="C.S." surname="Schmidt">
<organization>The MITRE Corporation</organization>
<address>
<postal>
<street>202 Burlington Road</street>
<!-- Reorder these if your country does things differently -->
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>USA</country>
</postal>
<phone/>
<email>cmschmidt@mitre.org</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Jessica Fitzgerald-McKay" initials="J.M." surname="Fitzgerald-McKay">
<organization>Department of Defense</organization>
<address>
<postal>
<street>9800 Savage Road</street>
<city>Ft. Meade</city>
<region>Maryland</region>
<country>USA</country>
</postal>
<email>jmfitz2@nsa.gov</email>
</address>
</author>
<date month="October" year="2015"/>
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>SACM</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>todo</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document builds off of <xref target="I-D.fitzgeraldmckay-sacm-endpointcompliance"/>
and <xref target="I-D.haynes-sacm-ecp-mapping"/> to provide high-level recommendations for
which Trusted Computing Group [TCG] Endpoint Compliance Profile <xref
target="Endpoint-Compliance-Profile"/> specifications might be most productively brought
into the IETF SACM Working Group (WG). Each section considers the alignment of an ECP
specification with SACM, how the specification could be leveraged by SACM as well as
potential modifications, and suggests a prioritization of specifications for submission to
the SACM WG.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The TCG Endpoint Compliance Profile describes the application of extensible IETF NEA and
TCG Trusted Network Communications (TNC) <xref target="TNC"/> protocols and interfaces for
endpoints to monitor and self-report their endpoint posture information using a secure
communication channel. Specifically, the ECP ensures network-connected endpoints are known
and authorized; applications on these endpoints are known and authorized; all applications
are patched and up-to-date; and applications with vulnerabilities can be located and
patched; all of which are critical to addressing the vulnerability management, software
asset management, and hardware asset management needs of SACM. The following table lists the
TCG standards as well as the corresponding IETF standards that are discussed in this
document.</t>
<texttable anchor="tcg_ietf_standards_mapping_table"
title="Mapping Between TNC and NEA Standards">
<ttcol align="center">TCG Standards</ttcol>
<ttcol align="center">IETF Standards</ttcol>
<c>IF-T TLS</c>
<c>PT-TLS (RFC 6876)</c>
<c>IF-T EAP</c>
<c>PT-EAP (RFC 7171)</c>
<c>IF-TNCCS</c>
<c>PB-TNC (RFC 5793)</c>
<c>IF-M</c>
<c>PA-TNC (RFC 5792)</c>
<c>IF-IMC</c>
<c>-</c>
<c>IF-IMV</c>
<c>-</c>
<c>SWID Message and Attributes for IF-M</c>
<c>-</c>
<c>Server Discovery and Validation</c>
<c>-</c>
<c>Endpoint Compliance Profile</c>
<c>-</c>
</texttable>
<t>Additionally, this document uses IETF NEA terminology where possible. The table below
indicates how the IETF terminology maps to the TCG terminology and SACM terminology.</t>
<texttable anchor="tcg_ietf_functional_units_mapping_table"
title="Mapping Between TNC and NEA Functional Units">
<ttcol align="center">IETF Terminology</ttcol>
<ttcol align="center">TCG Terminology</ttcol>
<ttcol align="center">SACM Terminology</ttcol>
<c>NEA Client</c>
<c>Access Requestor</c>
<c>SACM Endpoint</c>
<c>NEA Server + added enforcement capabilities</c>
<c>Policy Decision Point</c>
<c>SACM Server</c>
<c>Posture Collector</c>
<c>Integrity Measurement Collector</c>
<c>SACM Internal Collector</c>
<c>Posture Validator</c>
<c>Integrity Measurement Validator</c>
<c>SACM Evaluator</c>
<c>Posture Broker Client</c>
<c>TNC Client</c>
<c>SACM Controller</c>
<c>Posture Broker Server</c>
<c>TNC Server</c>
<c>SACM Controller</c>
<c>Posture Transport Client</c>
<c>Network Access Requestor</c>
<c>-</c>
<c>Posture Transport Server</c>
<c>Network Access Authority</c>
<c>-</c>
</texttable>
<t>Where <xref target="I-D.fitzgeraldmckay-sacm-endpointcompliance"/> introduced ECP to SACM
and <xref target="I-D.haynes-sacm-ecp-mapping"/> demonstrated how ECP can be used to
accomplish the use cases outlined in <xref target="RFC7632"/>, this paper provides
high-level recommendations for which ECP specifications should be brought into the IETF SACM
Working Group. The recommendations are based on the following criteria.</t>
<t>
<list style="symbols">
<t>Alignment with SACM (scale from 1 to 3)<list style="symbols">
<t>1: Poor alignment with SACM (requires extensive modifications)</t>
<t>2: Good alignment with SACM (requires some modifications)</t>
<t>3: Strong alignment with SACM (requires minor modifications)</t>
</list>
</t>
<t>How the specification may be used in SACM as well as potential modifications</t>
<t>Priority for sending the specification to SACM based on the need for a capability
(scale from LOW to HIGH)<list style="symbols">
<t>Low: Not critical to SACM</t>
<t>Medium: Somewhat critical to SACM</t>
<t>High: Very critical to SACM</t>
</list>
</t>
</list>
</t>
<t>The following sections evaluate each of the ECP specifications, using the above criteria,
and provide a recommendation for SACM. Each specification is listed based on its alignment
with SACM (strongest alignment first). The following table lists each specification and the
recommendation to the SACM WG.</t>
<texttable anchor="tcg_ecp_recommendations_table"
title="ECP Specification Recommendations to the SACM WG">
<ttcol align="center">Specification</ttcol>
<ttcol align="center">Recommendation</ttcol>
<c>IETF NEA PA-TNC (RFC 5792)</c>
<c>Adopt</c>
<c>IETF NEA PB-TNC (RFC 5793)</c>
<c>Adopt</c>
<c>IETF NEA PT-TLS (RFC 6876)</c>
<c>Adopt</c>
<c>TCG TNC SWID Message and Attributes for IF-M</c>
<c>Adopt if PA-TNC is adopted</c>
<c>TCG TNC IF-IMC / IF-IMV</c>
<c>Adopt if PA-TNC and PB-TNC are adopted</c>
<c>TCG TNC Server Discovery and Validation</c>
<c>Adopt if PB-TNC is adopted</c>
<c>TCG NEA PT-EAP (RFC 7171)</c>
<c>Do not adopt</c>
</texttable>
</section>
<section title="NEA PA-TNC">
<t>PA-TNC <xref target="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.</t>
<section title="Alignment with SACM">
<t>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 <xref target="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 <xref
target="SWID-Messages"/> specification demonstrates how PA-TNC can be extended to
support data like Software Identification (SWID) tag data <xref target="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.</t>
<t>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 <xref target="I-D.ietf-sacm-information-model"/>). To expand
further on this: <list style="symbols">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list>
</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Potential Use in SACM">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Priority">
<t>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.</t>
</section>
<section title="Recommendation">
<t>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.</t>
</section>
</section>
<section title="NEA PB-TNC">
<t>PB-TNC <xref target="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.</t>
<section title="Alignment with SACM">
<t>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 <xref target="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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Potential Use in SACM">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Priority">
<t>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.</t>
</section>
<section title="Recommendation">
<t>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.</t>
</section>
</section>
<section title="NEA PT-TLS">
<t>PT-TLS <xref target="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.</t>
<section title="Alignment with SACM">
<t>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 <xref target="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 <xref target="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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Potential Use in SACM">
<t>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.</t>
</section>
<section title="Priority">
<t>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.</t>
</section>
<section title="Recommendation">
<t>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.</t>
</section>
</section>
<section title="TCG TNC SWID Message and Attributes for IF-M">
<t>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.</t>
<section title="Alignment with SACM">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Potential Use in SACM">
<t>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.</t>
<t>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.</t>
</section>
<section title="Priority">
<t>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.</t>
</section>
<section title="Recommendation">
<t>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.</t>
</section>
</section>
<section title="TCG TNC IF-IMC / IF-IMV">
<t>TNC IF-IMC <xref target="IF-IMC"/> and IF-IMV <xref target="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.</t>
<section title="Alignment with SACM">
<t>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).</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Potential Use in SACM">
<t>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.</t>
<t>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.</t>
</section>
<section title="Priority">
<t>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.</t>
</section>
<section title="Recommendation">
<t>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.</t>
</section>
</section>
<section title="TCG TNC Server Discovery and Validation">
<t>TNC Server Discovery and Validation <xref target="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.</t>
<section title="Alignment with SACM">
<t>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).</t>
<t>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.</t>
</section>
<section title="Potential Use in SACM">
<t>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.</t>
<t>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.</t>
<t>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 <xref target="I-D.ietf-sacm-information-model"/>. Once <xref
target="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.</t>
<t>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.).</t>
</section>
<section title="Priority">
<t>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.</t>
</section>
<section title="Recommendation">
<t>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.</t>
</section>
</section>
<section title="IETF NEA PT-EAP">
<t>PT-EAP <xref target="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.</t>
<section title="Alignment with SACM">
<t>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 <xref
target="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.</t>
<t>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.</t>
</section>
<section title="Potential Use in SACM">
<t>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.</t>
</section>
<section title="Priority">
<t>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.</t>
</section>
<section title="Recommendation">
<t>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.</t>
</section>
</section>
<section title="Conclusion">
<t>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.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>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.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<!--&RFC2629;--> &RFC5209; &RFC5792; &RFC5793; &RFC6876; &RFC7171; &RFC7632;
&I-D.ietf-sacm-information-model; &I-D.fitzgeraldmckay-sacm-endpointcompliance;
&I-D.haynes-sacm-ecp-mapping; <!-- A reference written by by an organization not a person. -->
<reference anchor="Endpoint-Compliance-Profile">
<front>
<title abbrev="Endpoint Compliance Profile">TNC Endpoint Compliance Profile Specification,
Version 1.0</title>
<author>
<organization abbrev="TCG">Trusted Computing Group</organization>
</author>
<date month="December" year="2014"/>
</front>
</reference>
<reference anchor="IF-IMC">
<front>
<title abbrev="IF-IMC">TCG Trusted Network Connect TNC IF-IMC, Version 1.3</title>
<author>
<organization abbrev="TCG">Trusted Computing Group</organization>
</author>
<date month="February" year="2013"/>
</front>
</reference>
<reference anchor="IF-IMV">
<front>
<title abbrev="IF-IMV">TCG Trusted Network Connect TNC IF-IMV, Version 1.4</title>
<author>
<organization abbrev="TCG">Trusted Computing Group</organization>
</author>
<date month="December" year="2014"/>
</front>
</reference>
<reference anchor="ISO.19770-2">
<front>
<title abbrev="ISO/IEC 19770-2:2009">Information Technology -- Software Asset Management
-- Part 2: Software identification tag</title>
<author/>
<date year="2009"/>
</front>
<seriesInfo name="ISO/IEC" value="19770-2"/>
</reference>
<reference anchor="SWID-Messages">
<front>
<title abbrev="SWID Messages">DRAFT: TCG Trusted Network Connect SWID Message and
Attributes for IF-M, Version 1.0</title>
<author>
<organization abbrev="TCG">Trusted Computing Group</organization>
</author>
<date month="March" year="2015"/>
</front>
</reference>
<reference anchor="Server-Discovery">
<front>
<title abbrev="Server Discovery">DRAFT: TCG Trusted Network Connect PDP Discovery and
Validation, Version 1.0</title>
<author>
<organization abbrev="TCG">Trusted Computing Group</organization>
</author>
<date month="August" year="2013"/>
</front>
</reference>
<reference anchor="TNC">
<front>
<title abbrev="TNC">TCG Trusted Network Communications TNC Architecture for
Interoperability, Version 1.5</title>
<author>
<organization abbrev="TCG">Trusted Computing Group</organization>
</author>
<date month="February" year="2012"/>
</front>
</reference>
<reference anchor="TNC-FAQ">
<front>
<title abbrev="TNC FAQ">TCG Trusted Network Communications FAQ</title>
<author>
<organization abbrev="TCG">Trusted Computing Group</organization>
</author>
<date month="October" year="2015"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 15:57:20 |