idnits 2.17.1 draft-haynes-sacm-ecp-recommendations-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.fitzgeraldmckay-sacm-endpointcompliance], [TCG], [I-D.haynes-sacm-ecp-mapping], [Endpoint-Compliance-Profile]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2015) is 3106 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TCG' is mentioned on line 17, but not defined == Outdated reference: A later version (-01) exists of draft-fitzgeraldmckay-sacm-endpointcompliance-00 == Outdated reference: A later version (-01) exists of draft-haynes-sacm-ecp-mapping-00 == Outdated reference: A later version (-10) exists of draft-ietf-sacm-information-model-02 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SACM D. Haynes 3 Internet-Draft C. Schmidt 4 Intended status: Informational The MITRE Corporation 5 Expires: April 20, 2016 J. Fitzgerald-McKay 6 Department of Defense 7 October 18, 2015 9 SACM ECP Recommendations 10 draft-haynes-sacm-ecp-recommendations-00 12 Abstract 14 This document builds off of 15 [I-D.fitzgeraldmckay-sacm-endpointcompliance] and 16 [I-D.haynes-sacm-ecp-mapping] to provide high-level recommendations 17 for which Trusted Computing Group [TCG] Endpoint Compliance Profile 18 [Endpoint-Compliance-Profile] specifications might be most 19 productively brought into the IETF SACM Working Group (WG). Each 20 section considers the alignment of an ECP specification with SACM, 21 how the specification could be leveraged by SACM as well as potential 22 modifications, and suggests a prioritization of specifications for 23 submission to the SACM WG. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 20, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. NEA PA-TNC . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.1. Alignment with SACM . . . . . . . . . . . . . . . . . . . 6 62 2.2. Potential Use in SACM . . . . . . . . . . . . . . . . . . 7 63 2.3. Priority . . . . . . . . . . . . . . . . . . . . . . . . 8 64 2.4. Recommendation . . . . . . . . . . . . . . . . . . . . . 8 65 3. NEA PB-TNC . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 3.1. Alignment with SACM . . . . . . . . . . . . . . . . . . . 8 67 3.2. Potential Use in SACM . . . . . . . . . . . . . . . . . . 9 68 3.3. Priority . . . . . . . . . . . . . . . . . . . . . . . . 10 69 3.4. Recommendation . . . . . . . . . . . . . . . . . . . . . 10 70 4. NEA PT-TLS . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 4.1. Alignment with SACM . . . . . . . . . . . . . . . . . . . 10 72 4.2. Potential Use in SACM . . . . . . . . . . . . . . . . . . 11 73 4.3. Priority . . . . . . . . . . . . . . . . . . . . . . . . 11 74 4.4. Recommendation . . . . . . . . . . . . . . . . . . . . . 12 75 5. TCG TNC SWID Message and Attributes for IF-M . . . . . . . . 12 76 5.1. Alignment with SACM . . . . . . . . . . . . . . . . . . . 12 77 5.2. Potential Use in SACM . . . . . . . . . . . . . . . . . . 13 78 5.3. Priority . . . . . . . . . . . . . . . . . . . . . . . . 13 79 5.4. Recommendation . . . . . . . . . . . . . . . . . . . . . 13 80 6. TCG TNC IF-IMC / IF-IMV . . . . . . . . . . . . . . . . . . . 13 81 6.1. Alignment with SACM . . . . . . . . . . . . . . . . . . . 14 82 6.2. Potential Use in SACM . . . . . . . . . . . . . . . . . . 14 83 6.3. Priority . . . . . . . . . . . . . . . . . . . . . . . . 15 84 6.4. Recommendation . . . . . . . . . . . . . . . . . . . . . 15 85 7. TCG TNC Server Discovery and Validation . . . . . . . . . . . 15 86 7.1. Alignment with SACM . . . . . . . . . . . . . . . . . . . 15 87 7.2. Potential Use in SACM . . . . . . . . . . . . . . . . . . 16 88 7.3. Priority . . . . . . . . . . . . . . . . . . . . . . . . 17 89 7.4. Recommendation . . . . . . . . . . . . . . . . . . . . . 17 90 8. IETF NEA PT-EAP . . . . . . . . . . . . . . . . . . . . . . . 17 91 8.1. Alignment with SACM . . . . . . . . . . . . . . . . . . . 17 92 8.2. Potential Use in SACM . . . . . . . . . . . . . . . . . . 18 93 8.3. Priority . . . . . . . . . . . . . . . . . . . . . . . . 18 94 8.4. Recommendation . . . . . . . . . . . . . . . . . . . . . 18 95 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 18 96 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 97 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 98 12. Informative References . . . . . . . . . . . . . . . . . . . 19 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 101 1. Introduction 103 The TCG Endpoint Compliance Profile describes the application of 104 extensible IETF NEA and TCG Trusted Network Communications (TNC) 105 [TNC] protocols and interfaces for endpoints to monitor and self- 106 report their endpoint posture information using a secure 107 communication channel. Specifically, the ECP ensures network- 108 connected endpoints are known and authorized; applications on these 109 endpoints are known and authorized; all applications are patched and 110 up-to-date; and applications with vulnerabilities can be located and 111 patched; all of which are critical to addressing the vulnerability 112 management, software asset management, and hardware asset management 113 needs of SACM. The following table lists the TCG standards as well 114 as the corresponding IETF standards that are discussed in this 115 document. 117 +--------------------------------------+-------------------+ 118 | TCG Standards | IETF Standards | 119 +--------------------------------------+-------------------+ 120 | IF-T TLS | PT-TLS (RFC 6876) | 121 | | | 122 | IF-T EAP | PT-EAP (RFC 7171) | 123 | | | 124 | IF-TNCCS | PB-TNC (RFC 5793) | 125 | | | 126 | IF-M | PA-TNC (RFC 5792) | 127 | | | 128 | IF-IMC | - | 129 | | | 130 | IF-IMV | - | 131 | | | 132 | SWID Message and Attributes for IF-M | - | 133 | | | 134 | Server Discovery and Validation | - | 135 | | | 136 | Endpoint Compliance Profile | - | 137 +--------------------------------------+-------------------+ 139 Table 1: Mapping Between TNC and NEA Standards 141 Additionally, this document uses IETF NEA terminology where possible. 142 The table below indicates how the IETF terminology maps to the TCG 143 terminology and SACM terminology. 145 +----------------------------+---------------------+----------------+ 146 | IETF Terminology | TCG Terminology | SACM | 147 | | | Terminology | 148 +----------------------------+---------------------+----------------+ 149 | NEA Client | Access Requestor | SACM Endpoint | 150 | | | | 151 | NEA Server + added | Policy Decision | SACM Server | 152 | enforcement capabilities | Point | | 153 | | | | 154 | Posture Collector | Integrity | SACM Internal | 155 | | Measurement | Collector | 156 | | Collector | | 157 | | | | 158 | Posture Validator | Integrity | SACM Evaluator | 159 | | Measurement | | 160 | | Validator | | 161 | | | | 162 | Posture Broker Client | TNC Client | SACM | 163 | | | Controller | 164 | | | | 165 | Posture Broker Server | TNC Server | SACM | 166 | | | Controller | 167 | | | | 168 | Posture Transport Client | Network Access | - | 169 | | Requestor | | 170 | | | | 171 | Posture Transport Server | Network Access | - | 172 | | Authority | | 173 +----------------------------+---------------------+----------------+ 175 Table 2: Mapping Between TNC and NEA Functional Units 177 Where [I-D.fitzgeraldmckay-sacm-endpointcompliance] introduced ECP to 178 SACM and [I-D.haynes-sacm-ecp-mapping] demonstrated how ECP can be 179 used to accomplish the use cases outlined in [RFC7632], this paper 180 provides high-level recommendations for which ECP specifications 181 should be brought into the IETF SACM Working Group. The 182 recommendations are based on the following criteria. 184 o Alignment with SACM (scale from 1 to 3) 186 * 1: Poor alignment with SACM (requires extensive modifications) 188 * 2: Good alignment with SACM (requires some modifications) 190 * 3: Strong alignment with SACM (requires minor modifications) 192 o How the specification may be used in SACM as well as potential 193 modifications 195 o Priority for sending the specification to SACM based on the need 196 for a capability (scale from LOW to HIGH) 198 * Low: Not critical to SACM 200 * Medium: Somewhat critical to SACM 202 * High: Very critical to SACM 204 The following sections evaluate each of the ECP specifications, using 205 the above criteria, and provide a recommendation for SACM. Each 206 specification is listed based on its alignment with SACM (strongest 207 alignment first). The following table lists each specification and 208 the recommendation to the SACM WG. 210 +-----------------------------------+-------------------------------+ 211 | Specification | Recommendation | 212 +-----------------------------------+-------------------------------+ 213 | IETF NEA PA-TNC (RFC 5792) | Adopt | 214 | | | 215 | IETF NEA PB-TNC (RFC 5793) | Adopt | 216 | | | 217 | IETF NEA PT-TLS (RFC 6876) | Adopt | 218 | | | 219 | TCG TNC SWID Message and | Adopt if PA-TNC is adopted | 220 | Attributes for IF-M | | 221 | | | 222 | TCG TNC IF-IMC / IF-IMV | Adopt if PA-TNC and PB-TNC | 223 | | are adopted | 224 | | | 225 | TCG TNC Server Discovery and | Adopt if PB-TNC is adopted | 226 | Validation | | 227 | | | 228 | TCG NEA PT-EAP (RFC 7171) | Do not adopt | 229 +-----------------------------------+-------------------------------+ 231 Table 3: ECP Specification Recommendations to the SACM WG 233 2. NEA PA-TNC 235 PA-TNC [RFC5792] is a Posture Attribute (PA) protocol that is part of 236 the NEA specifications and compatible with TNC, and which carries 237 attributes between Posture Collectors and their corresponding Posture 238 Validators. 240 2.1. Alignment with SACM 242 The PA-TNC protocol is a highly-extensible, lightweight protocol that 243 is free of intellectual property rights concerns and compatible with 244 the TNC IF-M protocol, which has been adopted by members of industry 245 [TNC-FAQ]. It carries attributes between Posture Collectors on an 246 endpoint and their corresponding Posture Validators on a server. 247 Designed with extensibility in mind, PA-TNC supports the development 248 of standard and vendor-specific extensions to carry new types of 249 messages and attributes. This is critical for SACM as it enables the 250 standardization of common messages and attributes as well as provides 251 vendors with opportunities to add value and differentiate their 252 products from other vendors. Furthermore, the TCG TNC SWID Messages 253 and Attributes for IF-M [SWID-Messages] specification demonstrates 254 how PA-TNC can be extended to support data like Software 255 Identification (SWID) tag data [ISO.19770-2]. Lastly, the PA-TNC 256 protocol utilizes a type-length-value (TLV) based encoding to support 257 low-power and low-bandwidth networks which are in scope for SACM. 259 With that said, the PA-TNC protocol likely needs some enhancements to 260 satisfy the level of detail required for SACM. Most notably, PA-TNC 261 provides a basic data model for collection guidance, posture 262 attributes, and assessment results which need to be enhanced to 263 provide the level of detail needed by SACM (caveat: guidance, 264 attributes, and results are not fully specified in 265 [I-D.ietf-sacm-information-model]). To expand further on this: 267 o PA-TNC provides a data model for collection guidance via the PA 268 subtypes. This is simple and elegant especially if vendors 269 continue to define how to collect the particular information off 270 of their platforms and define what the data looks like. However, 271 it must also be considered how this guidance might be modified, if 272 at all, to support remote data collection. 274 o PA-TNC provides a data model for attributes via its "posture 275 attribute" TLV format which includes the posture attribute type, 276 length, and value among other fields. It must be considered 277 whether or not this format contains all the metadata SACM cares 278 about to enable an organization to make assertions about the 279 provenance of that data. 281 o PA-TNC provides a data model by which to express the results of an 282 assessment via the "assessment result" attribute. Specifically, 283 it provides results based on one of five values (expressed as a 284 32-bit value) which indicate whether or not the endpoint was 285 compliant or if a Posture Validator was unable to carry out the 286 assessment for a particular reason. While this provides a basic, 287 high-level result of the assessment, SACM also wants the ability 288 support detailed results (e.g. what failed and why, etc.) as well 289 as metadata about the results so that it can drive follow-up 290 actions. 292 Lastly, PA-TNC includes capabilities for remediation and network 293 access control that are currently out-of-scope for SACM and likely 294 need to be removed. Fortunately, due to the modular nature of this 295 protocol, these capabilities can be easily removed without requiring 296 significant changes to the specification or impacting other 297 capabilities. 299 Most of the noted issues represent relatively minor modifications to 300 the PA-TNC specification. On the other hand, PA-TNC directly aligns 301 closely with many of the core requirements and provides one of the 302 central SACM capabilities, namely the ability to gather and deliver 303 endpoint attributes. Therefore, the PA-TNC protocol is given a 304 rating of 3. 306 2.2. Potential Use in SACM 308 PA-TNC provides a protocol that can satisfy the need of SACM to 309 exchange posture assessment information between its architectural 310 components. However, unlike NEA which restricts the communication to 311 just Posture Collectors and Posture Validators and vise-versa, SACM 312 supports both direct and indirect (via a SACM Controller) 313 communication between any SACM Component which could violate this 314 restriction. As a result, this restriction would likely need to be 315 removed if the WG decides to use the NEA protocols beyond supporting 316 the endpoint self-reporting use case. 318 Furthermore, SACM likely needs to extend the list of attribute types 319 to support other types of posture assessment information and their 320 respective data models. For example, the policy used by Posture 321 Validators to evaluate posture attributes, collected from an 322 endpoint, is left as an implementation detail. SACM may want to 323 define a data model for evaluation guidance and transport it via PA- 324 TNC (e.g. from a guidance repository) so that this process could be 325 handled in a standardized way. 327 In the event that SACM wants to use PA-TNC as a standalone protocol 328 (i.e. without the rest of the NEA protocol stack), it would require 329 the selection of another protocol to route messages between SACM 330 Components as well as another protocol to secure the exchange of 331 those messages over the wire. 333 2.3. Priority 335 The SACM charter states that the working group will produce "a 336 standards-track document specifying a protocol and data format for 337 collecting actual endpoint posture". Given that the PA-TNC protocol 338 satisfies this SACM deliverable and provides a mechanism for 339 collecting and reporting attributes which is critical to SACM, the 340 priority for sending the protocol to the SACM WG is HIGH. 341 Furthermore, without such a protocol, the interoperability between 342 vendor products will be severely limited and likely result in end-to- 343 end, single-vendor solutions. 345 2.4. Recommendation 347 Given the extensible nature of the PA-TNC protocol to support new 348 data models including those previously discussed in SACM (SWID, etc.) 349 and the fact it could be used with only minor modifications, the SACM 350 WG should at a minimum adopt the protocol for carrying posture 351 assessment information from a SACM Internal Collector to a SACM 352 Evaluator. 354 3. NEA PB-TNC 356 PB-TNC [RFC5793] is a Posture Broker (PB) protocol that is part of 357 the NEA specifications and compatible with TNC, and which routes the 358 exchange of posture assessment information messages between an 359 endpoint and a server. 361 3.1. Alignment with SACM 363 PB-TNC is a highly-extensible, lightweight protocol that is free of 364 intellectual property rights concerns and is compatible with the TNC 365 IF-TNCCS protocol which has been adopted by members of industry 366 [TNC-FAQ]. It provides a standard mechanism by which to route 367 messages between Posture Collectors and Posture Validators 368 independently of the message contents. Specifically, Posture 369 Collectors and Posture Validators can subscribe to the Posture Broker 370 Client and Posture Broker Server respectively and register to receive 371 messages of a particular type. As a result, it is very easy to 372 extend PA-TNC and dynamically add new Posture Collectors and Posture 373 Validators without having to modify PB-TNC. Direct communication 374 between a specific Posture Collector and Posture Validator is also 375 supported. The PB-TNC protocol also utilizes a type-length-value 376 (TLV) based encoding as well as both half and full duplex 377 communications which is useful to support low-power and low-bandwidth 378 networks which are in scope for SACM. 380 Similar to PA-TNC, PB-TNC also includes capabilities such as 381 remediation and network access control that are currently out-of- 382 scope for SACM. Again, due to the modular nature of the protocol, 383 these capabilities can be easily removed without significant changes 384 to the specification or impacting other capabilities. Given that PB- 385 TNC is largely content-agnostic and focuses on data routing, it does 386 not come into conflict with most SACM requirements which tend to be 387 focused the data itself. As a result, this specification requires 388 very little modification. 390 Since the PB-TNC protocol directly aligns with SACM in that it is 391 extensible, provides a key capability in routing messages between an 392 endpoint and server, and requires only a very minor modification in 393 the form of removing some out-of-scope capabilities, it is given a 394 rating of 3. 396 3.2. Potential Use in SACM 398 Currently, PB-TNC only routes messages between Posture Collectors and 399 Posture Validators which satisfies the endpoint self-reporting use 400 case. However, if SACM plans to use PB-TNC beyond this use case, the 401 protocol will need to be extended to route messages to other types of 402 SACM Components. It may be possible to just leverage the Posture 403 Collector and Posture Validator Identifier fields in some type of 404 source and destination fashion. 406 In addition to the general routing of messages between Posture 407 Collectors and Posture Validators, PB-TNC is responsible for 408 transporting the global assessment result computed by the Posture 409 Broker Server to the Posture Broker Client for further action. 410 Furthermore, the global assessment result is potentially computed 411 using the assessment results from the applicable Posture Validators. 412 In SACM, the computation of assessment results should at a minimum be 413 delegated to an evaluation function and possibly standardized to 414 ensure consistent assessment results across different products. 415 Additionally, further action based on the assessment results should 416 be left as an implementation detail for vendors as it is out-of-scope 417 for SACM. That is, the expectation for the Posture Collector to 418 handle assessment results and remediation instructions should not be 419 enforced. 421 The PB-TNC protocol also assumes a very specific state machine 422 regarding the transmission of messages. This should be reviewed to 423 ensure it aligns with the needs of SACM. 425 Lastly, if SACM decides to use PB-TNC outside of the NEA protocol 426 stack, new protocols and data formats are necessary to exchange 427 posture assessment information between SACM Components as well as 428 provide a secure communication channel between them. 430 3.3. Priority 432 The SACM charter states that the working group will produce "a 433 standards-track document specifying a protocol and data format for 434 collecting actual endpoint posture". While PB-TNC does not directly 435 share posture assessment information, it does facilitate the transfer 436 of posture assessment information by carrying protocols such as PA- 437 TNC between endpoints and routing the messages to the appropriate 438 Posture Collectors and Posture Validators. Given that the PB-TNC 439 protocol supports this deliverable and the routing of messages 440 between an endpoint and a server which is essential for SACM, the 441 priority for sending the protocol to the SACM WG is HIGH. Like PA- 442 TNC, without such a protocol, the interoperability between vendor 443 products will be severely limited as Posture Collectors and Posture 444 Validators will not have a common way to communicate with each other. 446 3.4. Recommendation 448 Given the extensible nature of the PB-TNC protocol to support new 449 protocols to communicate posture assessment information between 450 Posture Collectors and Posture Validators and the fact it can operate 451 independently of the underlying protocol used to ensure a secure 452 communication channel, the SACM WG should at a minimum adopt the PB- 453 TNC protocol for routing posture assessment information messages 454 between a SACM Internal Collector to a SACM Evaluator. 456 4. NEA PT-TLS 458 PT-TLS [RFC6876] is a Posture Transport (PT) protocol that carries 459 posture assessment messages over a Transport Layer Security (TLS) 460 tunnel. It is part of the NEA specifications and is compatible with 461 the TNC PT-TLS specification. 463 4.1. Alignment with SACM 465 PT-TLS is an extensible, lightweight protocol to securely exchange 466 posture assessment information between a NEA Client and NEA Server 467 after the NEA Client has gained access to a network. It is free of 468 intellectual property rights concerns and is compatible with the TNC 469 IF-T Binding to TLS protocol which is adopted by industry [TNC-FAQ]. 470 PT-TLS provides authentication, integrity, and confidentiality of 471 data communicated over the PB-TNC protocol. To do so, PT-TLS 472 leverages the existing TLS protocol, which is already widely adopted. 473 It also operates independently of the protocol it carries (e.g. PB- 474 TNC) and can be extended to support message types used by other 475 protocols. With regards to authentication, PT-TLS provides an 476 authenticated endpoint identity which enables other components in the 477 NEA architecture [RFC5209] to know which component they are 478 communicating with. Lastly, PT-TLS uses a type-length-value encoding 479 which supports low-power endpoints and low-bandwidth networks which 480 are in scope for SACM as well as high-bandwidth, bi-directional 481 communication, and large messages. 483 Since the PT-TLS protocol provides a secure communication channel 484 that satisfies the needs of SACM and is agnostic to the data it is 485 carrying, there are no points of divergence with respect to the 486 alignment with SACM. 488 Given the PA-TNC protocol directly aligns with SACM by providing an 489 extensible mechanism by which to securely exchange posture assessment 490 messages and does not require any modifications, it is given a rating 491 of 3. 493 4.2. Potential Use in SACM 495 PT-TLS provides SACM with a protocol that can be used to secure the 496 exchange of posture assessment information. SACM can decide to 497 leverage PT-TLS with or without the PA-TNC and PB-TNC protocols. In 498 the absence of the using the PA-TNC and PB-TNC protocols, new 499 protocols would need to be specified or PT-TLS would need to carry 500 the data directly and the PT-TLS protocol would need to be extended 501 to support new messages types. For example, there is currently a PB- 502 TNC Batch message type for PB-TNC batches. If a new Protocol-XYZ is 503 used, a Protocol-XYZ message type would be required. 505 4.3. Priority 507 The SACM charter states that the working group will produce a 508 deliverable that is "a standards-track document specifying a protocol 509 and data format for collecting actual endpoint posture". While PT- 510 TLS does not directly share posture assessment information, it does 511 ensure posture assessment information carried over protocols such as 512 PA-TNC and PB-TNC is done so over a secure communication channel. 513 Specifically, it does so by providing mechanisms that ensure 514 authentication, integrity, and confidentially of the data being 515 shared. Since it supports this SACM deliverable, satisfies the need 516 to securely exchange posture assessment information, and provides a 517 mechanism for endpoint identity, all of which are critical for SACM, 518 the priority for sending the PT-TLS protocol to SACM is HIGH. 519 Without such a protocol, the interoperability between vendor products 520 will be severely limited and sensitive posture information sent over 521 a network may not be adequately protected. 523 4.4. Recommendation 525 Given the extensible nature of the PT-TLS protocol and its ability to 526 carry other protocols such as PA-TNC and PB-TNC over a secure 527 communication channel, the SACM WG should at a minimum adopt the PT- 528 TLS protocol for securing the exchange of posture assessment 529 information messages between a SACM Internal Collector and a SACM 530 Evaluator. 532 5. TCG TNC SWID Message and Attributes for IF-M 534 TNC SWID Message and Attributes for IF-M is an extension of the IF-M 535 protocol to support the exchange of ISO Software Identification 536 (SWID) tags. It is compatible with the NEA architecture, but is not 537 itself part of the NEA specifications. 539 5.1. Alignment with SACM 541 TNC SWID Message and Attributes for IF-M is an extension of the IF-M 542 protocol to support the exchange of ISO Software Identification 543 (SWID) tags and the events involving those tags. Unlike the IETF NEA 544 specifications, TNC SWID Message and Attributes for IF-M is not free 545 of intellectual property rights concerns as it is owned by the TCG. 546 With that said, in the past, the TCG has been willing to allow 547 interested parties to create compatible specifications in the IETF 548 and commit to update their specifications to align with the IETF 549 specifications (e.g. IF-M, IF-TNCCS, IF-T TLS/EAP). Since PA-TNC 550 and IF-M are compatible specifications, the SWID Message and 551 Attributes for IF-M specification should be straightforward for PA- 552 TNC to support SWID tags if not a drop-in extension. 554 Furthermore, the TNC SWID Message and Attributes for IF-M 555 specification satisfies key SACM use cases (software inventory, 556 endpoint characterization, vulnerability management, etc.) by 557 providing a standard protocol for exchanging detailed software 558 inventory data that is expressed using a standard data model (ISO 559 SWID tag). It also mandates that a SWID Posture Collector, in near 560 real-time, detect changes in the software inventory of an endpoint 561 (creation of tags, deletion of tags and alteration of tags). These 562 detected changes can then be sent to the appropriate destination 563 whether it be a SWID Posture Validator or a central repository. 564 Change detection on an endpoint is a critical capability for SACM. 565 Given the focus of this specification on change detection on the 566 endpoint, it best supports the endpoint self-reporting use case of 567 SACM. 569 Since TNC SWID Message and Attributes for IF-M addresses key SACM use 570 cases including software inventory, endpoint characterization, and 571 vulnerability management using a standard data model in SWID tags and 572 without modification, it is given a rating of 3. 574 5.2. Potential Use in SACM 576 For the most part, SACM should be able to leverage the SWID Message 577 and Attributes for IF-M specification as-is to support its software 578 asset management use case as it supports the use of either a central 579 repository or federated repositories. However, like PA-TNC, SACM 580 needs to determine if the specification contains all the metadata 581 needed to enable an organization to make assertions about the 582 provenance of that data. 584 SACM could also decide to use the SWID Message and Attributes for 585 IF-M as a standalone protocol (i.e. without PB-TNC, PT-TLS, or PT- 586 EAP), however, it would require the selection of another protocol to 587 route messages between SACM Components as well as a protocol to 588 secure the exchange of those messages over the wire. Of course, in 589 this situation, PA-TNC is required as SWID Message and Attributes for 590 IF-M is an extension for it. 592 5.3. Priority 594 Software inventory data is critical to achieving SACM's use cases. 595 The ability to share this software inventory data using a standard 596 data format over a standard protocol enables interoperability among 597 vendor products. Furthermore, it serves as a model for future 598 extensions to PA-TNC to support other data models. As a result of 599 these capabilities, the priority for sending the TNC SWID Message and 600 Attributes for IF-M specification to SACM is HIGH. 602 5.4. Recommendation 604 Given the SWID Message and Attributes for IF-M specification is 605 compatible with PA-TNC and utilizes SWID tags in a way that enables 606 the monitoring of software inventory events in a standardized way, it 607 should be adopted by the SACM WG if PA-TNC is also adopted by the 608 SACM WG. 610 6. TCG TNC IF-IMC / IF-IMV 612 TNC IF-IMC [IF-IMC] and IF-IMV [IF-IMV] provide standard interfaces 613 by which Posture Collectors can interact with a Posture Broker Client 614 and Posture Validators can interact with a Posture Broker Server. 615 IF-IMC and IF-IMV are not part of the NEA standards, but are 616 compatible with the NEA architecture. 618 6.1. Alignment with SACM 620 TNC IF-IMC and IF-IMV provide standard, extensible interfaces by 621 which Posture Collectors can interact with a Posture Broker Client 622 and a Posture Validator can interact with a Posture Broker Server . 623 Specifically, these interfaces support the passing and routing of 624 attributes between the PA-TNC layer of the TNC/NEA architecture, and 625 the PB-TNC layer within a single endpoint or server. This allows 626 flexibility in the addition of Posture Collectors and Posture 627 Validators, allowing easy addition or removal of such components. 628 These specifications are extensible through the definition of vendor- 629 specific functions and are both programming language and platform 630 independent, which aligns with SACM's desire to support all types of 631 endpoints. TNC IF-IMC and IF-IMV also support batching of endpoint 632 attribute transmission, which is ideal for low-power endpoints and 633 low-bandwidth networks which are in scope for SACM. Unlike the IETF 634 NEA specifications, TNC IF-IMC and IF-IMV are not free of 635 intellectual property rights concerns as they are owned by the TCG. 636 With that said, in the past, the TCG has been willing to allow 637 interested parties to create compatible specifications in the IETF 638 and commit to update their specifications to align with the IETF 639 specifications (e.g. IF-M, IF-TNCCS, IF-T TLS/EAP). 641 TNC IF-IMC and IF-IMV also include capabilities such as remediation 642 and network access control that are out-of-scope for SACM. Again, 643 due to the modular nature of the protocol, these capabilities can be 644 easily removed without significant changes to the specification or 645 impacting other capabilities. 647 Given that the TNC IF-IMC and IF-IMV interfaces directly align with 648 SACM in that they provide a mechanism by which Posture Collectors and 649 Posture Validators can easily be added to the assessment 650 infrastructure and can do so with relatively minor modifications, 651 these specifications are given a rating of 3. 653 6.2. Potential Use in SACM 655 The TNC IF-IMC and IF-IMV interfaces should plug into the SACM 656 architecture with little change assuming PA-TNC, PB-TNC, and PT-TLS/ 657 PT-EAP are adopted by SACM. These interfaces should remain stable as 658 new data models are supported (vendor-specific functions 659 notwithstanding) as these extensions impact the higher level 660 protocols and the messages are not interpreted by the interfaces. 662 The TNC IF-IMC and IF-IMV interfaces also assume a very specific 663 state machine regarding the transmission of messages. This should be 664 reviewed to ensure it aligns with the needs of SACM. 666 6.3. Priority 668 SACM wants to standardize the interfaces between SACM Components to 669 ensure interoperable communication. These interfaces provide 670 standard interfaces between Posture Collectors and a Posture Broker 671 Client and Posture Validators and a Posture Broker Server which is 672 currently left as an implementation detail in NEA. Most importantly, 673 these standard interfaces reduce the level-of-effort needed to 674 develop and deploy new Posture Collectors and Posture Validators 675 which is vital to keep pace with the rapidly changing platforms and 676 ever-evolving security landscape. As a result, the priority for 677 submitting these specifications the SACM WG is HIGH. 679 6.4. Recommendation 681 The SACM WG should adopt the TNC IF-IMC and IF-IMV specifications if 682 they adopt the PA-TNC and PB-TNC protocols as they standardize the 683 interfaces between the Posture Collector and the Posture Broker 684 Client and the Posture Validator and the Posture Broker Server. By 685 doing so, they promote additional opportunity for interoperability 686 among vendor products which would otherwise resort to proprietary 687 solutions. 689 7. TCG TNC Server Discovery and Validation 691 TNC Server Discovery and Validation [Server-Discovery] provides 692 endpoints with a mechanism by which an endpoint can discover the 693 presence of servers on the network and determine if they can be 694 trusted. Server Discovery and Validation is not part of the NEA 695 specifications, but is compatible with the NEA architecture. 697 7.1. Alignment with SACM 699 TNC Server Discovery and Validation is an extensible specification 700 that is currently under development in the TCG. At the time of this 701 document, the specification is in the public comment phase of the 702 development lifecycle. The specification provides endpoints with a 703 mechanism to locate servers (TNC Policy Decision Points, NEA Servers, 704 vendor-specific, etc.) and ensure that they are trusted before 705 sending sensitive posture information to them. Discovery can occur 706 either through the use of DNS SRV records or through a specific PB- 707 TNC message type. Furthermore, it can be extended to support 708 different types of servers, server identifiers, and trust parameters. 709 By leveraging existing protocols such as PB-TNC, DNS, etc., TNC 710 Server Discovery and Validation increases the likelihood of adoption 711 when the final version is published. Similar to other TCG 712 specifications, TNC Server Discovery and Validation is not free of 713 intellectual property rights concerns. However, in the past, the TCG 714 has been willing to allow interested parties to create compatible 715 specifications in the IETF and commit to update their specifications 716 to align with the IETF specifications (e.g. IF-M, IF-TNCCS, IF-T 717 TLS/EAP). 719 While the ability to discover and validate servers is well supported 720 for the use case where endpoints self-report their posture assessment 721 information, it will take some work to support SACM use case beyond 722 this such as where on the network a SACM Component should go to 723 retrieve a specific piece of information. As a result, this 724 specification is given a rating of 2. 726 7.2. Potential Use in SACM 728 TNC Server Discovery and Validation provides an excellent starting 729 point, however, SACM may want to consider extending the specification 730 in a few ways to address its needs. First, there is no standard 731 interface for sharing the referral information obtained via server 732 discovery with the component on the endpoint that is responsible for 733 actually establishing a connection to the server that it was referred 734 to. SACM may want to develop this interface so it is not left as an 735 implementation detail. 737 Second, SACM may want to support additional server types which is 738 easily done via the extensible nature of the server type field. 739 Given that SACM follows more of a peer-to-peer model where each SACM 740 Component can communicate with each other, it probably makes sense to 741 include a server type for each type of SACM Component. 743 The specification also uses IPv4, IPv6, and FQDN to identify servers. 744 SACM supports these identifiers (now called designation attributes) 745 although FQDN is no longer mandatory-to-implement in 746 [I-D.ietf-sacm-information-model]. Once 747 [I-D.ietf-sacm-information-model] is complete, the mandatory-to- 748 implement list of identifiers in TNC Server Discovery and Validation 749 should be brought into alignment. 751 Lastly, the specification permits the development of more complex 752 server validation trust computations that go beyond a simple binary 753 result (i.e., "trusted" or "not trusted"). SACM may want to extend 754 the trust parameters, in a standard way, to carry out role and 755 context based authorizations of SACM Components (i.e., "trusted for 756 purpose X", "trusted for purpose Y", etc.). 758 7.3. Priority 760 SACM needs a mechanism for SACM Components to locate other SACM 761 Components and ensure they are trusted prior to requesting or 762 providing posture assessment information. In the long term, hard- 763 coded discovery and validation capabilities are not scalable, but 764 given the scope and progress of SACM, it might make sense to start 765 with hard-coded discovery and validation capabilities until a basic 766 set of data formats and protocols, for exchanging posture assessment 767 information, are adopted. Once a few data formats and protocols are 768 supported, this specification provides a great starting point by 769 which SACM can further develop these discovery and validation 770 capabilities in a standardized way. As a result, this specification 771 is given a priority of MEDIUM. 773 7.4. Recommendation 775 The SACM WG should adopt the TNC Server Discovery and Validation if 776 PB-TNC is adopted by SACM for the endpoint self-reporting use case 777 after protocols for securely exchange posture assessment information 778 have been adopted. 780 8. IETF NEA PT-EAP 782 PT-EAP [RFC7171] is a Posture Transport (PT) protocol that carries 783 posture assessment messages over an Extensible Authentication 784 Protocol (EAP) tunnel. It is part of the NEA specifications and is 785 compatible with the TNC architecture. 787 8.1. Alignment with SACM 789 PT-EAP is an extensible, lightweight protocol to securely exchange 790 posture assessment information between a NEA Client and NEA Server 791 prior to assignment of an IP address. It is free of intellectual 792 property rights concerns and is compatible with the TNC IF-T Protocol 793 Bindings for Tunneled EAP Methods protocol which is adopted by 794 industry [TNC-FAQ]. PT-EAP provides authentication, integrity, and 795 confidentiality of data communicated over the PB-TNC protocol. To do 796 so, PT-EAP leverages existing EAP tunnels such as EAP-FAST and EAP- 797 TTLS. It also operates independently of the protocol it carries 798 (e.g. PB-TNC) and can be extended to support message types used by 799 other protocols. With regards to authentication, like PT-TLS, PT-EAP 800 provides an authenticated endpoint identity which enables other 801 components in the NEA architecture to know which component they are 802 communicating with. Lastly, PT-EAP uses a type-length-value encoding 803 which supports low-power endpoints and low-bandwidth networks which 804 are in scope for SACM as well as high-bandwidth, bi-directional 805 communication, and large messages. 807 While the PT-EAP protocol aligns with SACM by providing an extensible 808 mechanism by which to securely exchange posture assessment messages, 809 it focuses on the communication prior to an endpoint joining a 810 network which is out-of-scope for SACM. As a result, it is given a 811 rating of 1. 813 8.2. Potential Use in SACM 815 PT-EAP provides SACM with a protocol that can be used to secure the 816 exchange of posture assessment information prior to an endpoint 817 joining a network. SACM can decide to leverage PT-EAP with or 818 without the PA-TNC and PB-TNC protocols. In the absence of using the 819 PA-TNC and PB-TNC protocols, new protocols would need to be specified 820 or PT-EAP would need to directly carry the data. 822 8.3. Priority 824 The SACM charter states that the working group will produce "a 825 standards-track document specifying a protocol and data format for 826 collecting actual endpoint posture". While PT-EAP provides 827 mechanisms that ensure authentication, integrity, and confidentially 828 of the posture assessment information being shared, it primary use is 829 for prior to an endpoint gaining access to he a network. This is a 830 useful for network access control capabilities, however, network 831 access control is not something that SACM plans to standardize at 832 this time. As a result, the priority for this protocol is LOW. 834 8.4. Recommendation 836 Although the PT-EAP protocol provides a mechanism to securely 837 exchange posture assessment information, SACM is not currently 838 addressing the scenario involving endpoints prior to joining the 839 network. As a result, the PT-EAP protocol should not be adopted by 840 SACM at this time. However, if SACM decides to address this scenario 841 in the future, the PT-EAP protocol should definitely be considered 842 for inclusion. 844 9. Conclusion 846 The TNC Endpoint Compliance Profile identifies several extensible 847 specifications that are in use today and align with the many of the 848 architectural and protocol needs of SACM. While these specifications 849 do not provide a complete solution for SACM, this document shows how 850 many of the specifications, sometimes with modifications, support the 851 use case where an endpoint self-reports its posture assessment 852 information to a server very well and would serve as an excellent 853 starting point for SACM. Please consider these recommendations when 854 deciding if the ECP specifications make sense for the SACM WG to 855 adopt. If there is consensus around adopting these specifications, a 856 formal request will be made to the TCG to resolve any relevant 857 outstanding IPR concerns. 859 10. IANA Considerations 861 This memo includes no request to IANA. 863 11. Security Considerations 865 This memo documents high-level recommendations for which TCG ECP 866 specifications might be most productively brought into the IETF SACM 867 WG. It is for informational purposes only. As a result, there are 868 no specific security considerations. 870 12. Informative References 872 [Endpoint-Compliance-Profile] 873 Trusted Computing Group, "TNC Endpoint Compliance Profile 874 Specification, Version 1.0", December 2014. 876 [I-D.fitzgeraldmckay-sacm-endpointcompliance] 877 Fitzgerald-McKay, J., "Endpoint Compliance Standard", 878 draft-fitzgeraldmckay-sacm-endpointcompliance-00 (work in 879 progress), May 2015. 881 [I-D.haynes-sacm-ecp-mapping] 882 Coffin, C., Haynes, D., Schmidt, C., and J. Fitzgerald- 883 McKay, "SACM ECP Mapping", draft-haynes-sacm-ecp- 884 mapping-00 (work in progress), July 2015. 886 [I-D.ietf-sacm-information-model] 887 Waltermire, D., Watson, K., Kahn, C., and L. Lorenzin, 888 "SACM Information Model", draft-ietf-sacm-information- 889 model-02 (work in progress), July 2015. 891 [IF-IMC] Trusted Computing Group, "TCG Trusted Network Connect TNC 892 IF-IMC, Version 1.3", February 2013. 894 [IF-IMV] Trusted Computing Group, "TCG Trusted Network Connect TNC 895 IF-IMV, Version 1.4", December 2014. 897 [ISO.19770-2] 898 "Information Technology -- Software Asset Management -- 899 Part 2: Software identification tag", ISO/IEC 19770-2, 900 2009. 902 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 903 Tardo, "Network Endpoint Assessment (NEA): Overview and 904 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 905 . 907 [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute 908 (PA) Protocol Compatible with Trusted Network Connect 909 (TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010, 910 . 912 [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: 913 A Posture Broker (PB) Protocol Compatible with Trusted 914 Network Connect (TNC)", RFC 5793, DOI 10.17487/RFC5793, 915 March 2010, . 917 [RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture 918 Transport Protocol over TLS (PT-TLS)", RFC 6876, DOI 919 10.17487/RFC6876, February 2013, 920 . 922 [RFC7171] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport 923 (PT) Protocol for Extensible Authentication Protocol (EAP) 924 Tunnel Methods", RFC 7171, DOI 10.17487/RFC7171, May 2014, 925 . 927 [RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security 928 Posture Assessment: Enterprise Use Cases", RFC 7632, DOI 929 10.17487/RFC7632, September 2015, 930 . 932 [Server-Discovery] 933 Trusted Computing Group, "DRAFT: TCG Trusted Network 934 Connect PDP Discovery and Validation, Version 1.0", August 935 2013. 937 [SWID-Messages] 938 Trusted Computing Group, "DRAFT: TCG Trusted Network 939 Connect SWID Message and Attributes for IF-M, Version 940 1.0", March 2015. 942 [TNC] Trusted Computing Group, "TCG Trusted Network 943 Communications TNC Architecture for Interoperability, 944 Version 1.5", February 2012. 946 [TNC-FAQ] Trusted Computing Group, "TCG Trusted Network 947 Communications FAQ", October 2015. 949 Authors' Addresses 951 Daniel Haynes 952 The MITRE Corporation 953 202 Burlington Road 954 Bedford, MA 01730 955 USA 957 Email: dhaynes@mitre.org 959 Charles Schmidt 960 The MITRE Corporation 961 202 Burlington Road 962 Bedford, MA 01730 963 USA 965 Email: cmschmidt@mitre.org 967 Jessica Fitzgerald-McKay 968 Department of Defense 969 9800 Savage Road 970 Ft. Meade, Maryland 971 USA 973 Email: jmfitz2@nsa.gov