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]