One document matched: draft-haynes-sacm-ecp-mapping-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 RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.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 I-D.fitzgeraldmckay-sacm-endpointcompliance SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.fitzgeraldmckay-sacm-endpointcompliance.xml">
<!ENTITY I-D.ietf-sacm-use-cases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sacm-use-cases.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.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="yes" ?>
<!-- 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-mapping-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 Mapping">SACM ECP Mapping</title>
<!-- Another author who claims to be an editor -->
<author fullname="Chris Coffin" initials="C.C." surname="Coffin">
<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>ccoffin@mitre.org</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<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>
<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="July" 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 upon <xref target="I-D.fitzgeraldmckay-sacm-endpointcompliance"/>
to demonstrate how published IETF, ISO, and TCG standards, available today, can be used to
accomplish the use cases outlined in <xref target="I-D.ietf-sacm-use-cases"/>.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>In <xref target="I-D.fitzgeraldmckay-sacm-endpointcompliance"/>, several existing
standards are identified as aligning with the needs of SACM and are suggested for possible
incorporation, either by reference or by adoption, into the set of solutions in the SACM
architecture. These standards include the suite of network interfaces defined in the IETF
Network Endpoint Assessment (NEA) workgroup, and some additional specifications from the
Trusted Computing Group's (TCG's) Trusted Network Communications (formerly Trusted Network
Connect) (TNC) <xref target="TNC"/> workgroup. The NEA architecture <xref target="RFC5209"/>
is based on the TNC architecture and both are interoperable. The NEA/TNC architecture
provide standards-based mechanisms to collect endpoint state and configuration information
and securely transmit it to some authority where the information is evaluated against
criteria. This aligns closely with the overall SACM goals of "...an architecture to enable
standardized collection, acquisition, and verification of Posture and Posture Assessments."
This document provides a more detailed mapping of the NEA specifications, as well as some
additional TNC specifications that standardize additional behaviors within the NEA/TNC
architecture, to the use cases defined for SACM.</t>
<t> At the heart of this proposal is the Endpoint Compliance Profile (ECP) <xref
target="Endpoint-Compliance-Profile"/>. The ECP is a high-level standard describing a
specific combination and application of NEA and TNC protocols and interfaces specifically
designed to support ongoing monitoring of endpoint state and the controlled exposure of
collected information to appropriate security applications. The ECP uses the components
specified in the NEA/TNC architecture and also defines roles for the additional TNC
specifications mentioned in <xref target="I-D.fitzgeraldmckay-sacm-endpointcompliance"
/>, namely IF-IMC <xref target="IF-IMC"/>, IF-IMV <xref target="IF-IMV"/>, SWID Message and
Attributes for IF-M <xref target="SWID-Messages"/>, and Server Discovery and Validation.
(The latter is referred to as PDP Discovery and Validation <xref target="Server-Discovery"/>
in the ECP as the ECP predated the expansion of that specification's scope.) The ECP
dictates the use of specific standards and also clarifies requirements for optional features
in order to better standardize assessment practices. The following sections outline how the
use of standards in accordance with the ECP can also meet SACM's use cases. </t>
<t>In the descriptions below, IETF NEA terminology is used where possible. The table below
indicates TNC and NEA terms for corresponding standards and functional units. TCG terms that
do not have a NEA counterpart but which are mentioned in the ECP are also identified.</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>TNC</c>
<c>NEA (RFC 5209)</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>
<texttable anchor="tcg_ietf_functional_units_mapping_table"
title="Mapping Between TNC and NEA Functional Units">
<ttcol align="center">TCG Terminology</ttcol>
<ttcol align="center">IETF Terminology</ttcol>
<c>Access Requestor</c>
<c>NEA Client</c>
<c>Policy Decision Point</c>
<c>NEA Server + added enforcement capabilities</c>
<c>Integrity Measurement Collector</c>
<c>Posture Collector</c>
<c>Integrity Measurement Validator</c>
<c>Posture Validator</c>
<c>TNC Client</c>
<c>Posture Broker Client</c>
<c>TNC Server</c>
<c>Posture Broker Server</c>
<c>Network Access Requestor</c>
<c>Posture Transport Client</c>
<c>Network Access Authority</c>
<c>Posture Transport Server</c>
</texttable>
<t>The following sections describe where each of the standards mentioned in the ECP fit into
use cases 2, 3, and 4 of <xref target="I-D.ietf-sacm-use-cases"/>. Use case 1 is a much
higher-level set of capabilities and requirements and so is not treated separately.</t>
</section>
<section title="Endpoint Identification and Assessment Planning">
<t>The Endpoint Identification and Assessment Planning use case (section 2.1.2 of <xref
target="I-D.ietf-sacm-use-cases"/>) involves "discovery of endpoints, understanding their
composition, identifying the desired state to assess against, and calculating what posture
attributes to collect to enable evaluation." Several of the TNC specifications and
architectural components identified in the ECP are directly applicable to these
activities.</t>
<t>The first step in the assessment process is to discover the endpoints on the network. The
NEA Architecture allows enterprises to enforce a policy where endpoints (a.k.a., NEA
Clients) are only allowed onto the network if they contact a NEA Server and provide
measurements to demonstrate their compliance with enterprise policy. In such an enterprise,
this would ensure that all endpoints on the network were known. Added security and
flexibility for this activity can be provided by the Server Discovery and Validation
specification, which can be leveraged to ensure that NEA Clients are connecting to trusted
servers before they register themselves and send sensitive information.</t>
<t>When a NEA Client first connects to a NEA Server, and on an as-needed basis after that, it
can be required to provide posture information that helps to identify the endpoint on the
network and characterize its nature, which is critical in determining if an endpoint
qualifies as the target of an assessment. Posture information is collected by Posture
Collectors on the NEA Client. Once collected, the Posture Collectors securely transmit the
attributes back to the Posture Validators on the NEA Server via the PA-TNC (NEA
"application" layer) <xref target="RFC5792"/>, PB-TNC (NEA "routing" layer) <xref
target="RFC5793"/> and either PT-TLS or PT-EAP (NEA "transport" layer) protocols. The
collected posture information may also be stored in a CMDB or data repository for later use
in assessment targeting and evaluation. Beyond any identifying information collected by the
Posture Collectors, the PT-TLS <xref target="RFC6876"/> and PT-EAP <xref target="RFC7171"/>
protocols both support certificate-based authentication of the client. </t>
<t>The NEA/TNC architecture is designed to be highly flexible and extensible. The IF-IMC
(connecting Posture Collectors to Posture Broker Clients) and IF-IMV (connecting Posture
Validators to Posture Broker Servers) interfaces allow a range of Posture Collectors and
Posture Validators, respectively, to be employed. The standard interfaces mean that new
Collector/Validator pairs supporting different types of posture information can be easily
added to the assessment infrastructure to meet the needs of individual enterprises. For
example, SWID Message and Attributes for IF-M defines a standard way to collect and
transport a NEA Client's SWID tag inventory information, which can be very useful in
understanding a NEA Client's role and its exposure to software vulnerabilities. </t>
<t>Once posture information has been collected, the Posture Validators evaluate the
information. Based on this evaluation, the Validators can suggest access control decisions,
recommend further assessment of the NEA Client, or take other actions. For example, a NEA
Client can be required to provide a SWID tag inventory (using the SWID Message and
Attributes for IF-M protocol) when it initially seeks to connect to an enterprise, when a
Posture Collector detects a change to the SWID tag inventory, or when it is requested by the
NEA Server. The Posture Validator that receives this information might examine the SWID tags
of a particular NEA Client and discover that the NEA Client is running a web server. Based
on this, the NEA Client may be subject to additional assessment in its role as a web server
for the enterprise. Another NEA Client may submit a SWID tag for a piece of software with a
known vulnerability. Based on this, the Posture Validator may determine that this NEA Client
requires further examination to determine whether mitigating steps have been taken to
protect it from the vulnerability.</t>
</section>
<section title="Endpoint Posture Attribute Value Collection">
<t>The Endpoint Posture Attribute Value Collection use case (section 2.1.3 of <xref
target="I-D.ietf-sacm-use-cases"/>) follows from the previous use case. The overall goal
of this use case is to determine which additional endpoint posture attribute values are
needed and then perform the collection. The use case that follows (2.1.4 Posture Attribute
Evaluation) uses the attribute values to perform an evaluation of the attributes and their
values as part of an overall assessment.</t>
<t>In the current use case, the NEA Client(s) in question have already been authenticated and
have been granted access to the network. The NEA Client(s) have also been identified and
characterized (i.e., OS type and version, hardware platform, etc.) based on the collected
information. Some attribute and attribute values from this step may be cached or stored in a
CMDB or data repository and may be used within the current use case.</t>
<t>Now that the NEA Client is part of the network, a more extensive assessment and/or periodic
reassessments can be performed in order to ensure detailed, ongoing compliance with
policies. The data collected during this activity could include additional or updated
identification and characterization attributes or information to support assessment against
checklists or other guidance. Depending on the needs of the enterprise and the nature of the
guidance it uses, different Posture Collector/Validator pairs can be employed to gather and
transmit this information. As mentioned earlier, the IF-IMV and IF-IMC standards allow these
Collectors/Validators to be added to the assessment infrastructure seamlessly. If different
information needs to be delivered to different NEA Servers for assessment, the Server
Discovery and Validation can help NEA Clients identify and validate the authenticity of
those servers.</t>
<t>Multiple events could trigger a posture attribute value collection. Some of those events
could be triggered on the NEA Client, such as the detection of a change in posture. Other
events could trigger the NEA Server to collect attributes, such as the detection of specific
network events or net flows, the receipt of new guidance, requirements for periodic
reassessment, or a manually triggered assessment by an administrator. All such triggers are
supported by the NEA architecture. In particular, Posture Collectors can be instructed to
monitor for changes in their attribute set of interest and automatically report events of
interest to Posture Validators. Similarly, Posture Validators can be triggered to gather
information from a NEA Client in a variety of ways. The process of attribute exchange uses
the same set of NEA protocols here as outlined in the preceding use case, namely PA-TNC,
PB-TNC, and PT-TLS or PT-EAP.</t>
<t>The SWID Message and Attributes for IF-M specification provides an excellent example of
this capability. The SWID IMV (a Posture Validator) can request a variety of types of
information about an endpoint's SWID tag collection based on guidance, a periodic trigger,
and/or manual requests. The SWID IMC (a Posture Collector) can also be instructed to monitor
the NEA Client's SWID tag collection for changes, and can be instructed to report certain
types of changes to the NEA Server automatically. The former capability allows on-demand
updates of a NEA Client's SWID tag collection, while the latter allows the NEA Server to be
automatically informed of any changes to the NEA Client's SWID tag collection (or subsets
thereof) in real time.</t>
</section>
<section title="Posture Attribute Evaluation">
<t>The Posture Attribute Evaluation use case (section 2.1.4 of <xref
target="I-D.ietf-sacm-use-cases"/>) involves the analysis of posture attribute values,
collected from the NEA Client, against the expected values of the posture attributes in
order to determine a result. This result can be used to initiate follow up actions. The NEA
architecture provides a framework in which this use case can be achieved.</t>
<t>Once a NEA Client resides on the network, the NEA architecture supports a number of
triggers that can result in the reassessment of that NEA Client. These triggers and the
resulting attribute collection are discussed in more detail in the Endpoint Posture
Attribute Value Collection use case described in the preceding section.</t>
<t>This SACM use case emphasizes posture change detection on an endpoint as a triggering
condition. As noted earlier, NEA supports this by allowing Posture Collectors to monitor the
NEA Client and automatically push information about changes of interest. Such Posture
Collectors may be configurable to be selective in what they report in order to ensure NEA
Servers are not deluged by irrelevant data. For example, the SWID Message and Attributes for
IF-M specification supports configuring SWID IMCs with lists of specific tags to monitor
and/or can be configured only to report how a NEA Client's SWID tag collection has changed
since the last update.</t>
<t>Once the Posture Validator has the required inputs to carry out the evaluation, it can
perform this evaluation and return a result. The result of this evaluation is passed to the
Posture Broker Server which then initiates any necessary response. For example, upon
evaluation of a NEA Client's SWID tag collection, it might be determined that a newly
installed piece of software is not on the organization's whitelist of authorized software.
Depending on enterprise policy, this may result in a simple alert to an administrator, or
something as proactive as removal of the NEA Client from the enterprise network.</t>
</section>
<section title="Conclusion">
<t>Several years ago, the Trusted Computing Group offered several of their TNC standards to
the IETF and these eventually became the NEA standards. If SACM feels that the additional
TNC standards discussed here have value, it is hoped that TCG will again be willing to offer
them for IETF adoption. Doing this does more than just provide a shortcut to the publication
of useful, tested IETF RFCs - it helps unify the approaches of TCG and IETF rather than
creating multiple separate solutions to the challenges of automated cyber defense.
Consolidating standards around a proven approach not only accelerates standards development
but aids consumers by avoiding a multiplicity of competing standards.</t>
<t>More generally, this document shows that the described TNC and NEA standards align well
with SACM use cases. While they do not address every identified building block of these use
cases, they address a large number of them, and the NEA/TNC architecture supports extension
points where other standards can be applied to address any missing capabilities. By the same
token, because the NEA/TNC architecture so closely aligns with SACM needs, developing a new
solution would lead to redundant, competing solutions for many of the activities that SACM
seeks to support. For these reasons, the authors urge SACM to consider use of NEA/TNC
standards in general, and the ECP in particular, in the development of the SACM
architecture.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
<t>All drafts are required to have an IANA considerations section (see <xref
target="I-D.narten-iana-considerations-rfc2434bis">the update of RFC 2434</xref> for a
guide). If the draft does not require IANA to do anything, the section contains an explicit
statement that this is the case (as above). If there are no requirements for IANA, the
section will be removed during conversion into an RFC by the RFC Editor.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>All drafts are required to have a security considerations section. See <xref
target="RFC3552">RFC 3552</xref> for a guide.</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;--> &RFC3552; &RFC5209; &RFC5792; &RFC5793; &RFC6876; &RFC7171;
&I-D.narten-iana-considerations-rfc2434bis; &I-D.ietf-sacm-use-cases;
&I-D.fitzgeraldmckay-sacm-endpointcompliance;
<!-- 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="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 Connect TNC Architecture for Interoperability,
Version 1.5</title>
<author>
<organization abbrev="TCG">Trusted Computing Group</organization>
</author>
<date month="February" year="2012"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 17:20:10 |