idnits 2.17.1 draft-hanna-sacm-assessment-protocols-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 15, 2012) is 4208 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-nea-pt-tls-07 == Outdated reference: A later version (-09) exists of draft-ietf-nea-pt-eap-03 -- Obsolete informational reference (is this intentional?): RFC 3979 (ref. '16') (Obsoleted by RFC 8179) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Hanna 2 Internet Draft Juniper Networks 3 Intended status: Informational October 15, 2012 4 Expires: April 2013 6 Standard Assessment Protocols and Formats for SACM 7 draft-hanna-sacm-assessment-protocols-00.txt 9 Abstract 11 The draft charter for the SACM BOF at IETF 85 calls for the 12 development of "continuous assessment interfaces". This draft points 13 out several existing documents that provide a good start in this 14 area. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as 29 reference material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on April 15, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with 49 respect to this document. 51 Table of Contents 53 1. Introduction...................................................2 54 2. Languages and Enumerations.....................................2 55 3. Protocols......................................................3 56 4. Merging The Two................................................4 57 5. Next Steps.....................................................4 58 6. Security Considerations........................................5 59 7. IANA Considerations............................................5 60 8. References.....................................................5 61 8.1. Informative References....................................5 62 9. Acknowledgments................................................6 64 1. Introduction 66 The draft charter for the SACM BOF at IETF 85 [1] calls for the 67 development of "continuous assessment interfaces". This text from 68 the draft charter provides more detail about what's desired: 70 2. Define, either by normative reference, adoption, or creation, 71 a set of standards that can be used to continuously assess and 72 report on the state of systems, composed of many different types 73 of devices and networks, operated by varying personnel, to ensure 74 security process effectiveness in a pre-defined or ad-hoc manner. 75 This area of focus provides for integration protocols supporting 76 plug and play continuous assessment and security automation 77 networking within an enterprise. 79 Actually, there are several specifications from IETF and other 80 organizations that provide a very good start on addressing this 81 problem. More work is certainly needed but the SACM BOF should be 82 aware of these documents. 84 2. Languages and Enumerations 86 The SCAP specification [2] lists a large number of languages and 87 enumerations that are useful for remote security assessment: XCCDF 88 [3], OVAL [4], OCIL [5], Asset Identification [6], CCE [7], CPE [8], 89 and CVE [9]. Since there is a great deal of implementation 90 experience with these specifications, they should certainly be 91 considered by the SACM BOF or any successor Working Group. 93 3. Protocols 95 The IETF NEA Working Group has defined an architecture and a layered 96 set of protocols for remote assessment of endpoint security posture: 97 the NEA Architecture [10], PA-TNC [11], PB-TNC [12], PT-TLS [13], 98 and PT-EAP [14]. These protocols are designed to be used either at 99 the time that an endpoint connects to a network or continuously 100 after the endpoint is connected to the network. 102 The NEA protocols are based on the Trusted Network Connect (TNC) 103 protocols, which were created by the Trusted Computing Group (TCG) 104 and donated to the IETF. The TCG contributed the TNC specifications 105 to the IETF in full compliance with BCP 78 [15] and BCP 79 [16], 106 transferring change control and copyright to the IETF (among other 107 things). The IETF took full advantage of this change control, 108 adopting the TNC standards through an open and competitive process 109 but adapting them to the IETF's needs and processes. For example, 110 the IETF renamed all the TNC protocols: IF-M became PA-TNC, IF-TNCCS 111 became PB-TNC, IF-T Binding for TLS became PT-TLS, and IF-T Binding 112 for Tunneled EAP Methods became PT-EAP. 114 Because the NEA protocols are based on the TNC protocols, they 115 benefit from the experiences of and feedback from millions of users, 116 thousands of customers, and dozens of vendors and open source 117 implementers who have used the TNC protocols. For example, users 118 strongly prefer quick and efficient checks when waiting to get on 119 the network. Therefore, all the NEA protocols use a binary encoding 120 and minimize round trips. Still, vendors need extensibility so the 121 NEA specs permit vendor-specific extensions while requiring that 122 vendors work without them. 124 Two of the NEA protocols (PA-TNC and PB-TNC) were published as 125 Proposed Standards in 2010. At the same time, the TCG issued updated 126 TNC protocol specs (IF-M 1.0 [17] and IF-TNCCS 2.0 [18]) that 127 correspond exactly to the NEA specs, thus ensuring that the two 128 architectures remain in alignment. The other two NEA specs (PT-TLS 129 and PT-EAP) are expected to be published as Proposed Standards 130 within the next few months. TCG may reasonably be expected to again 131 issue updated versions of the corresponding TNC specs to maintain 132 alignment. Customer and vendor adoption is expected to be rapid for 133 these specs since the old versions were widely implemented and the 134 new specs are a simple upgrade from the old. Even vendors who have 135 long used proprietary protocols have indicated their plans to 136 support the new open standard protocols. 138 4. Merging The Two 140 While the NEA protocols define the format for some simple posture 141 checks (anti-virus or host firewall status, OS patch level), they do 142 not define standards that approach the level of detail that 143 sophisticated enterprise customers need and can achieve with SCAP. 145 At the same time, SCAP does not define any standards for gathering 146 SCAP content from an endpoint. This is left to the vendor, resulting 147 in a situation where each vendor must place a software agent on the 148 endpoint in order to assess that endpoint (or settle for an external 149 scan, which has lower fidelity). 151 What's needed to fully satisfy the SACM BOF's charter item on 152 continuous assessment interfaces is a standard for conveying the 153 SCAP languages and enumerations in the NEA protocols. 155 Fortunately, the TCG has recently published exactly this document. 156 The TCG's SCAP Messages for IF-M specification [19] was published 157 for Public Review on TCG's web site on October 3, 2012. This 158 document describes how SCAP content should be carried over the NEA 159 (TNC) protocols. It includes support for provisioning SCAP content 160 to endpoints, for rapidly and efficiently gathering assessment 161 results when a device connects to the network, for gathering 162 exhaustive information in the background after the device is 163 connected to the network, and for continuously monitoring changes to 164 configuration. 166 While the TCG has not made any official statements about its intent 167 with respect to donating this specification to IETF, I believe that 168 the TCG would be glad to do so if the IETF charters a Working Group 169 to work on continuous assessment interfaces. I should know about 170 this. I'm co-chair of the TCG's Trusted Network Connect Work Group. 172 5. Next Steps 174 The SACM BOF participants should review the new SCAP Messages for 175 IF-M specification to see if it meets their needs. If they find 176 deficiencies, they should notify the TCG by sending email to 177 SCAP-Messages-Comments@trustedcomputinggroup.org. 179 Within IETF, we should review and discuss these documents to see if 180 they are relevant to the SACM effort. Do they meet the need for 181 continuous assessment interfaces that was described in the proposed 182 SACM charter? If not, what changes are needed? Could those changes 183 be made using these specs as a starting point, assuming that the TCG 184 donated the specs to the IETF with all rights and full change 185 control? And should this work happen in a new Working Group or 186 should it happen in the NEA Working Group, which already has five 187 years of experience with this topic. 189 The IETF discussions should happen on the sacm@ietf.org list. I 190 would also be glad to lead a discussion of this topic at the SACM 191 BOF at IETF 85. 193 6. Security Considerations 195 This document describes several existing standards relating to 196 endpoint assessment and configuration management. Each of these 197 specifications includes its own Security Considerations section so 198 the reader is referred to those documents for more details. 200 7. IANA Considerations 202 This document has no actions for IANA. 204 8. References 206 8.1. Informative References 208 [1] SACM BOF Draft Charter, http://www.ietf.org/mail- 209 archive/web/sacm/current/msg00628.html 211 [2] U.S. NIST, "The Technical Specification for the Security 212 Content Automation Protocol (SCAP): SCAP Version 1.2", NIST 213 Special Publication 800-126 Revision 2, September 2011. 215 [3] U.S. NIST, "Specification for the Extensible Configuration 216 Checklist Description Format (XCCDF) Version 1.2", NIST 217 Interagency Report 7275 Revision 4, September 2011. 219 [4] The MITRE Corporation, "The OVAL(R) Language Specification 220 Version 5.10.1", January 2012. 222 [5] U.S. NIST, "Specification for the Open Checklist Interactive 223 Language (OCIL) Version 2.0", NIST Interagency Report 7692, 224 April 2011. 226 [6] U.S. NIST, "Specification for Asset Identification 1.1", NIST 227 Interagency Report 7693, June 2011. 229 [7] The MITRE Corporation, http://cce.mitre.org 231 [8] U.S. NIST, http://scap.nist.gov/specifications/cpe 233 [9] The MITRE Corporation, http://cve.mitre.org 235 [10] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 236 Tardo, "Network Endpoint Assessment (NEA): Overview and 237 Requirements", RFC 5209, June 2008. 239 [11] Sangster, P., and K. Narayan, "PA-TNC: A Posture Attribute 240 (PA) Protocol Compatible with Trusted Network Connect (TNC)", 241 RFC 5792, March 2010. 243 [12] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: A 244 Posture Broker (PB) Protocol Compatible with Trusted Network 245 Connect (TNC)", RFC 5793, March 2010. 247 [13] Sangster, P., N. Cam-Winget, and J. Salowey, "PT-TLS: A TCP- 248 based Posture Transport (PT) Protocol", draft-ietf-nea-pt-tls- 249 07.txt (work in progress), August 2012. 251 [14] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport 252 (PT) Protocol For EAP Tunnel Methods", draft-ietf-nea-pt-eap- 253 03.txt (work in progress), July 2012. 255 [15] Bradner, S. and J. Contreras, "Rights Contributors Provide to 256 the IETF Trust", RFC 5378, November 2008. 258 [16] Bradner, S., "Intellectual Property Rights in IETF 259 Technology", RFC 3979, March 2005. 261 [17] Trusted Computing Group, "IF-M: TLV Binding", Version 1.0, 262 Revision 37, March 2010. 264 [18] Trusted Computing Group, "IF-TNCCS: TLV Binding", Version 2.0, 265 Revision 16, January 2010. 267 [19] Trusted Computing Group, "SCAP Messages for IF-M", Version 268 1.0, Revision 16, October 2012. 270 9. Acknowledgments 272 This document was prepared using 2-Word-v2.0.template.dot. 274 Author's Address 276 Steve Hanna 277 Juniper Networks, Inc. 278 79 Parsons Street 279 Brighton, MA 02135 280 USA 281 Email: shanna@juniper.net