Internet DRAFT - draft-haynes-sacm-ecp-recommendations
draft-haynes-sacm-ecp-recommendations
SACM D. Haynes
Internet-Draft C. Schmidt
Intended status: Informational The MITRE Corporation
Expires: April 20, 2016 J. Fitzgerald-McKay
Department of Defense
October 18, 2015
SACM ECP Recommendations
draft-haynes-sacm-ecp-recommendations-00
Abstract
This document builds off of
[I-D.fitzgeraldmckay-sacm-endpointcompliance] and
[I-D.haynes-sacm-ecp-mapping] to provide high-level recommendations
for which Trusted Computing Group [TCG] Endpoint Compliance Profile
[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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 20, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Haynes, et al. Expires April 20, 2016 [Page 1]
Internet-Draft SACM ECP Recommendations October 2015
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. NEA PA-TNC . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Alignment with SACM . . . . . . . . . . . . . . . . . . . 6
2.2. Potential Use in SACM . . . . . . . . . . . . . . . . . . 7
2.3. Priority . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Recommendation . . . . . . . . . . . . . . . . . . . . . 8
3. NEA PB-TNC . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Alignment with SACM . . . . . . . . . . . . . . . . . . . 8
3.2. Potential Use in SACM . . . . . . . . . . . . . . . . . . 9
3.3. Priority . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4. Recommendation . . . . . . . . . . . . . . . . . . . . . 10
4. NEA PT-TLS . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Alignment with SACM . . . . . . . . . . . . . . . . . . . 10
4.2. Potential Use in SACM . . . . . . . . . . . . . . . . . . 11
4.3. Priority . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4. Recommendation . . . . . . . . . . . . . . . . . . . . . 12
5. TCG TNC SWID Message and Attributes for IF-M . . . . . . . . 12
5.1. Alignment with SACM . . . . . . . . . . . . . . . . . . . 12
5.2. Potential Use in SACM . . . . . . . . . . . . . . . . . . 13
5.3. Priority . . . . . . . . . . . . . . . . . . . . . . . . 13
5.4. Recommendation . . . . . . . . . . . . . . . . . . . . . 13
6. TCG TNC IF-IMC / IF-IMV . . . . . . . . . . . . . . . . . . . 13
6.1. Alignment with SACM . . . . . . . . . . . . . . . . . . . 14
6.2. Potential Use in SACM . . . . . . . . . . . . . . . . . . 14
6.3. Priority . . . . . . . . . . . . . . . . . . . . . . . . 15
6.4. Recommendation . . . . . . . . . . . . . . . . . . . . . 15
7. TCG TNC Server Discovery and Validation . . . . . . . . . . . 15
7.1. Alignment with SACM . . . . . . . . . . . . . . . . . . . 15
7.2. Potential Use in SACM . . . . . . . . . . . . . . . . . . 16
7.3. Priority . . . . . . . . . . . . . . . . . . . . . . . . 17
7.4. Recommendation . . . . . . . . . . . . . . . . . . . . . 17
8. IETF NEA PT-EAP . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Alignment with SACM . . . . . . . . . . . . . . . . . . . 17
8.2. Potential Use in SACM . . . . . . . . . . . . . . . . . . 18
8.3. Priority . . . . . . . . . . . . . . . . . . . . . . . . 18
8.4. Recommendation . . . . . . . . . . . . . . . . . . . . . 18
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 18
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
Haynes, et al. Expires April 20, 2016 [Page 2]
Internet-Draft SACM ECP Recommendations October 2015
11. Security Considerations . . . . . . . . . . . . . . . . . . . 19
12. Informative References . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
The TCG Endpoint Compliance Profile describes the application of
extensible IETF NEA and TCG Trusted Network Communications (TNC)
[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.
+--------------------------------------+-------------------+
| TCG Standards | IETF Standards |
+--------------------------------------+-------------------+
| IF-T TLS | PT-TLS (RFC 6876) |
| | |
| IF-T EAP | PT-EAP (RFC 7171) |
| | |
| IF-TNCCS | PB-TNC (RFC 5793) |
| | |
| IF-M | PA-TNC (RFC 5792) |
| | |
| IF-IMC | - |
| | |
| IF-IMV | - |
| | |
| SWID Message and Attributes for IF-M | - |
| | |
| Server Discovery and Validation | - |
| | |
| Endpoint Compliance Profile | - |
+--------------------------------------+-------------------+
Table 1: Mapping Between TNC and NEA Standards
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.
Haynes, et al. Expires April 20, 2016 [Page 3]
Internet-Draft SACM ECP Recommendations October 2015
+----------------------------+---------------------+----------------+
| IETF Terminology | TCG Terminology | SACM |
| | | Terminology |
+----------------------------+---------------------+----------------+
| NEA Client | Access Requestor | SACM Endpoint |
| | | |
| NEA Server + added | Policy Decision | SACM Server |
| enforcement capabilities | Point | |
| | | |
| Posture Collector | Integrity | SACM Internal |
| | Measurement | Collector |
| | Collector | |
| | | |
| Posture Validator | Integrity | SACM Evaluator |
| | Measurement | |
| | Validator | |
| | | |
| Posture Broker Client | TNC Client | SACM |
| | | Controller |
| | | |
| Posture Broker Server | TNC Server | SACM |
| | | Controller |
| | | |
| Posture Transport Client | Network Access | - |
| | Requestor | |
| | | |
| Posture Transport Server | Network Access | - |
| | Authority | |
+----------------------------+---------------------+----------------+
Table 2: Mapping Between TNC and NEA Functional Units
Where [I-D.fitzgeraldmckay-sacm-endpointcompliance] introduced ECP to
SACM and [I-D.haynes-sacm-ecp-mapping] demonstrated how ECP can be
used to accomplish the use cases outlined in [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.
o Alignment with SACM (scale from 1 to 3)
* 1: Poor alignment with SACM (requires extensive modifications)
* 2: Good alignment with SACM (requires some modifications)
* 3: Strong alignment with SACM (requires minor modifications)
Haynes, et al. Expires April 20, 2016 [Page 4]
Internet-Draft SACM ECP Recommendations October 2015
o How the specification may be used in SACM as well as potential
modifications
o Priority for sending the specification to SACM based on the need
for a capability (scale from LOW to HIGH)
* Low: Not critical to SACM
* Medium: Somewhat critical to SACM
* High: Very critical to SACM
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.
+-----------------------------------+-------------------------------+
| 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 | Adopt if PA-TNC is adopted |
| Attributes for IF-M | |
| | |
| TCG TNC IF-IMC / IF-IMV | Adopt if PA-TNC and PB-TNC |
| | are adopted |
| | |
| TCG TNC Server Discovery and | Adopt if PB-TNC is adopted |
| Validation | |
| | |
| TCG NEA PT-EAP (RFC 7171) | Do not adopt |
+-----------------------------------+-------------------------------+
Table 3: ECP Specification Recommendations to the SACM WG
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.
Haynes, et al. Expires April 20, 2016 [Page 5]
Internet-Draft SACM ECP Recommendations October 2015
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:
o 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.
o 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.
o 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
Haynes, et al. Expires April 20, 2016 [Page 6]
Internet-Draft SACM ECP Recommendations October 2015
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.
Haynes, et al. Expires April 20, 2016 [Page 7]
Internet-Draft SACM ECP Recommendations October 2015
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.
Haynes, et al. Expires April 20, 2016 [Page 8]
Internet-Draft SACM ECP Recommendations October 2015
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
Haynes, et al. Expires April 20, 2016 [Page 9]
Internet-Draft SACM ECP Recommendations October 2015
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
Haynes, et al. Expires April 20, 2016 [Page 10]
Internet-Draft SACM ECP Recommendations October 2015
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.
Haynes, et al. Expires April 20, 2016 [Page 11]
Internet-Draft SACM ECP Recommendations October 2015
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
Haynes, et al. Expires April 20, 2016 [Page 12]
Internet-Draft SACM ECP Recommendations October 2015
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.
Haynes, et al. Expires April 20, 2016 [Page 13]
Internet-Draft SACM ECP Recommendations October 2015
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.
Haynes, et al. Expires April 20, 2016 [Page 14]
Internet-Draft SACM ECP Recommendations October 2015
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
Haynes, et al. Expires April 20, 2016 [Page 15]
Internet-Draft SACM ECP Recommendations October 2015
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.).
Haynes, et al. Expires April 20, 2016 [Page 16]
Internet-Draft SACM ECP Recommendations October 2015
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.
Haynes, et al. Expires April 20, 2016 [Page 17]
Internet-Draft SACM ECP Recommendations October 2015
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
Haynes, et al. Expires April 20, 2016 [Page 18]
Internet-Draft SACM ECP Recommendations October 2015
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",
draft-fitzgeraldmckay-sacm-endpointcompliance-00 (work in
progress), May 2015.
[I-D.haynes-sacm-ecp-mapping]
Coffin, C., Haynes, D., Schmidt, C., and J. Fitzgerald-
McKay, "SACM ECP Mapping", draft-haynes-sacm-ecp-
mapping-00 (work in progress), July 2015.
[I-D.ietf-sacm-information-model]
Waltermire, D., Watson, K., Kahn, C., and L. Lorenzin,
"SACM Information Model", draft-ietf-sacm-information-
model-02 (work in progress), 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.
Haynes, et al. Expires April 20, 2016 [Page 19]
Internet-Draft SACM ECP Recommendations October 2015
[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,
<http://www.rfc-editor.org/info/rfc5209>.
[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,
<http://www.rfc-editor.org/info/rfc5792>.
[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, <http://www.rfc-editor.org/info/rfc5793>.
[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,
<http://www.rfc-editor.org/info/rfc6876>.
[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,
<http://www.rfc-editor.org/info/rfc7171>.
[RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security
Posture Assessment: Enterprise Use Cases", RFC 7632, DOI
10.17487/RFC7632, September 2015,
<http://www.rfc-editor.org/info/rfc7632>.
[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.
Haynes, et al. Expires April 20, 2016 [Page 20]
Internet-Draft SACM ECP Recommendations October 2015
Authors' Addresses
Daniel Haynes
The MITRE Corporation
202 Burlington Road
Bedford, MA 01730
USA
Email: dhaynes@mitre.org
Charles Schmidt
The MITRE Corporation
202 Burlington Road
Bedford, MA 01730
USA
Email: cmschmidt@mitre.org
Jessica Fitzgerald-McKay
Department of Defense
9800 Savage Road
Ft. Meade, Maryland
USA
Email: jmfitz2@nsa.gov
Haynes, et al. Expires April 20, 2016 [Page 21]
