[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

SACM                                                           C. Coffin
Internet-Draft                                                 D. Haynes
Intended status: Informational                                C. Schmidt
Expires: July 7, 2016                              The MITRE Corporation
                                                     J. Fitzgerald-McKay
                                                   Department of Defense
                                                         January 4, 2016

                            SACM ECP Mapping


   This document builds upon
   [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 [RFC7632].

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 July 7, 2016.

Copyright Notice

   Copyright (c) 2016 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
   (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

Coffin, et al.            Expires July 7, 2016                  [Page 1]

Internet-Draft              SACM ECP Mapping                January 2016

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Endpoint Identification and Assessment Planning . . . . . . .   4
   3.  Endpoint Posture Attribute Value Collection . . . . . . . . .   6
   4.  Posture Attribute Evaluation  . . . . . . . . . . . . . . . .   7
   5.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  -00 to -01  . . . . . . . . . . . . . . . . . . . . . . .   9
   9.  Informative References  . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   In [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) [TNC]
   workgroup.  The NEA architecture [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.

   At the heart of this proposal is the Endpoint Compliance Profile
   (ECP) [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
   [I-D.fitzgeraldmckay-sacm-endpointcompliance], namely IF-IMC

Coffin, et al.            Expires July 7, 2016                  [Page 2]

Internet-Draft              SACM ECP Mapping                January 2016

   [IF-IMC], IF-IMV [IF-IMV], SWID Message and Attributes for IF-M
   [SWID-Messages], and Server Discovery and Validation.  (The latter is
   referred to as PDP Discovery and Validation [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.

   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

       |            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) |
       |                 TNC                  |   NEA (RFC 5209)  |
       |                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

Coffin, et al.            Expires July 7, 2016                  [Page 3]

Internet-Draft              SACM ECP Mapping                January 2016

   |      TCG Terminology       |           IETF Terminology           |
   |      Access Requestor      |              NEA Client              |
   |   Policy Decision Point    |    NEA Server + added enforcement    |
   |                            |             capabilities             |
   |   Integrity Measurement    |          Posture Collector           |
   |         Collector          |                                      |
   |   Integrity Measurement    |          Posture Validator           |
   |         Validator          |                                      |
   |         TNC Client         |        Posture Broker Client         |
   |         TNC Server         |        Posture Broker Server         |
   |  Network Access Requestor  |       Posture Transport Client       |
   |  Network Access Authority  |       Posture Transport Server       |

           Table 2: Mapping Between TNC and NEA Functional Units

   The following sections describe where each of the standards mentioned
   in the ECP fit into use cases 2, 3, and 4 of [RFC7632].  Use case 1
   is a much higher-level set of capabilities and requirements and so is
   not treated separately.

2.  Endpoint Identification and Assessment Planning

   The Endpoint Identification and Assessment Planning use case (section
   2.1.2 of [RFC7632]) 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

   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

   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

Coffin, et al.            Expires July 7, 2016                  [Page 4]

Internet-Draft              SACM ECP Mapping                January 2016

   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)
   [RFC5792], PB-TNC (NEA "routing" layer) [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 [RFC6876]
   and PT-EAP [RFC7171] protocols both support certificate-based
   authentication of the client.

   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.

   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.

Coffin, et al.            Expires July 7, 2016                  [Page 5]

Internet-Draft              SACM ECP Mapping                January 2016

3.  Endpoint Posture Attribute Value Collection

   The Endpoint Posture Attribute Value Collection use case (section
   2.1.3 of [RFC7632]) 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.

   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.

   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.

   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.

Coffin, et al.            Expires July 7, 2016                  [Page 6]

Internet-Draft              SACM ECP Mapping                January 2016

   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

4.  Posture Attribute Evaluation

   The Posture Attribute Evaluation use case (section 2.1.4 of
   [RFC7632]) 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.

   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

   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.

   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

Coffin, et al.            Expires July 7, 2016                  [Page 7]

Internet-Draft              SACM ECP Mapping                January 2016

   administrator, or something as proactive as removal of the NEA Client
   from the enterprise network.

5.  Conclusion

   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.

   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.

6.  IANA Considerations

   This memo includes no request to IANA.

   All drafts are required to have an IANA considerations section (see
   the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis]
   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.

7.  Security Considerations

   All drafts are required to have a security considerations section.
   See RFC 3552 [RFC3552] for a guide.

Coffin, et al.            Expires July 7, 2016                  [Page 8]

Internet-Draft              SACM ECP Mapping                January 2016

8.  Change Log

8.1.  -00 to -01

   There are no textual changes associated with this revision except for
   updated references to the Endpoint Security Posture Assessment:
   Enterprise Use Cases document given that it was recently published as
   an RFC.  This revision primarily reflects a resubmission of the
   document so that it goes back into active status.  The document
   expired on January 7, 2016.

9.  Informative References

              Trusted Computing Group, "TNC Endpoint Compliance Profile
              Specification, Version 1.0", December 2014.

              Fitzgerald-McKay, J., "Endpoint Compliance Standard",
              draft-fitzgeraldmckay-sacm-endpointcompliance-01 (work in
              progress), November 2015.

              Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", draft-narten-iana-
              considerations-rfc2434bis-09 (work in progress), March

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

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552, DOI
              10.17487/RFC3552, July 2003,

   [RFC5209]  Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
              Tardo, "Network Endpoint Assessment (NEA): Overview and
              Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008,

   [RFC5792]  Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute
              (PA) Protocol Compatible with Trusted Network Connect
              (TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010,

Coffin, et al.            Expires July 7, 2016                  [Page 9]

Internet-Draft              SACM ECP Mapping                January 2016

   [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,

   [RFC7171]  Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport
              (PT) Protocol for Extensible Authentication Protocol (EAP)
              Tunnel Methods", RFC 7171, DOI 10.17487/RFC7171, May 2014,

   [RFC7632]  Waltermire, D. and D. Harrington, "Endpoint Security
              Posture Assessment: Enterprise Use Cases", RFC 7632, DOI
              10.17487/RFC7632, September 2015,

              Trusted Computing Group, "DRAFT: TCG Trusted Network
              Connect PDP Discovery and Validation, Version 1.0", August

              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 Connect TNC
              Architecture for Interoperability, Version 1.5", February

Authors' Addresses

   Chris Coffin
   The MITRE Corporation
   202 Burlington Road
   Bedford, MA  01730

   Email: ccoffin@mitre.org

Coffin, et al.            Expires July 7, 2016                 [Page 10]

Internet-Draft              SACM ECP Mapping                January 2016

   Daniel Haynes
   The MITRE Corporation
   202 Burlington Road
   Bedford, MA  01730

   Email: dhaynes@mitre.org

   Charles Schmidt
   The MITRE Corporation
   202 Burlington Road
   Bedford, MA  01730

   Email: cmschmidt@mitre.org

   Jessica Fitzgerald-McKay
   Department of Defense
   9800 Savage Road
   Ft. Meade, Maryland

   Email: jmfitz2@nsa.gov

Coffin, et al.            Expires July 7, 2016                 [Page 11]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/