Network Working Group S. Hanna Internet Draft Juniper Networks Intended status: Informational October 15, 2012 Expires: April 2013 Standard Assessment Protocols and Formats for SACM draft-hanna-sacm-assessment-protocols-00.txt Abstract The draft charter for the SACM BOF at IETF 85 calls for the development of "continuous assessment interfaces". This draft points out several existing documents that provide a good start in this area. 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 15, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Hanna Expires April 15, 2013 [Page 1] Internet-Draft Assessment Protocols and Formats October 2012 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction...................................................2 2. Languages and Enumerations.....................................2 3. Protocols......................................................3 4. Merging The Two................................................4 5. Next Steps.....................................................4 6. Security Considerations........................................5 7. IANA Considerations............................................5 8. References.....................................................5 8.1. Informative References....................................5 9. Acknowledgments................................................6 1. Introduction The draft charter for the SACM BOF at IETF 85 [1] calls for the development of "continuous assessment interfaces". This text from the draft charter provides more detail about what's desired: 2. Define, either by normative reference, adoption, or creation, a set of standards that can be used to continuously assess and report on the state of systems, composed of many different types of devices and networks, operated by varying personnel, to ensure security process effectiveness in a pre-defined or ad-hoc manner. This area of focus provides for integration protocols supporting plug and play continuous assessment and security automation networking within an enterprise. Actually, there are several specifications from IETF and other organizations that provide a very good start on addressing this problem. More work is certainly needed but the SACM BOF should be aware of these documents. 2. Languages and Enumerations The SCAP specification [2] lists a large number of languages and enumerations that are useful for remote security assessment: XCCDF [3], OVAL [4], OCIL [5], Asset Identification [6], CCE [7], CPE [8], and CVE [9]. Since there is a great deal of implementation Hanna Expires April 15, 2013 [Page 2] Internet-Draft Assessment Protocols and Formats October 2012 experience with these specifications, they should certainly be considered by the SACM BOF or any successor Working Group. 3. Protocols The IETF NEA Working Group has defined an architecture and a layered set of protocols for remote assessment of endpoint security posture: the NEA Architecture [10], PA-TNC [11], PB-TNC [12], PT-TLS [13], and PT-EAP [14]. These protocols are designed to be used either at the time that an endpoint connects to a network or continuously after the endpoint is connected to the network. The NEA protocols are based on the Trusted Network Connect (TNC) protocols, which were created by the Trusted Computing Group (TCG) and donated to the IETF. The TCG contributed the TNC specifications to the IETF in full compliance with BCP 78 [15] and BCP 79 [16], transferring change control and copyright to the IETF (among other things). The IETF took full advantage of this change control, adopting the TNC standards through an open and competitive process but adapting them to the IETF's needs and processes. For example, the IETF renamed all the TNC protocols: IF-M became PA-TNC, IF-TNCCS became PB-TNC, IF-T Binding for TLS became PT-TLS, and IF-T Binding for Tunneled EAP Methods became PT-EAP. Because the NEA protocols are based on the TNC protocols, they benefit from the experiences of and feedback from millions of users, thousands of customers, and dozens of vendors and open source implementers who have used the TNC protocols. For example, users strongly prefer quick and efficient checks when waiting to get on the network. Therefore, all the NEA protocols use a binary encoding and minimize round trips. Still, vendors need extensibility so the NEA specs permit vendor-specific extensions while requiring that vendors work without them. Two of the NEA protocols (PA-TNC and PB-TNC) were published as Proposed Standards in 2010. At the same time, the TCG issued updated TNC protocol specs (IF-M 1.0 [17] and IF-TNCCS 2.0 [18]) that correspond exactly to the NEA specs, thus ensuring that the two architectures remain in alignment. The other two NEA specs (PT-TLS and PT-EAP) are expected to be published as Proposed Standards within the next few months. TCG may reasonably be expected to again issue updated versions of the corresponding TNC specs to maintain alignment. Customer and vendor adoption is expected to be rapid for these specs since the old versions were widely implemented and the new specs are a simple upgrade from the old. Even vendors who have long used proprietary protocols have indicated their plans to support the new open standard protocols. Hanna Expires April 15, 2013 [Page 3] Internet-Draft Assessment Protocols and Formats October 2012 4. Merging The Two While the NEA protocols define the format for some simple posture checks (anti-virus or host firewall status, OS patch level), they do not define standards that approach the level of detail that sophisticated enterprise customers need and can achieve with SCAP. At the same time, SCAP does not define any standards for gathering SCAP content from an endpoint. This is left to the vendor, resulting in a situation where each vendor must place a software agent on the endpoint in order to assess that endpoint (or settle for an external scan, which has lower fidelity). What's needed to fully satisfy the SACM BOF's charter item on continuous assessment interfaces is a standard for conveying the SCAP languages and enumerations in the NEA protocols. Fortunately, the TCG has recently published exactly this document. The TCG's SCAP Messages for IF-M specification [19] was published for Public Review on TCG's web site on October 3, 2012. This document describes how SCAP content should be carried over the NEA (TNC) protocols. It includes support for provisioning SCAP content to endpoints, for rapidly and efficiently gathering assessment results when a device connects to the network, for gathering exhaustive information in the background after the device is connected to the network, and for continuously monitoring changes to configuration. While the TCG has not made any official statements about its intent with respect to donating this specification to IETF, I believe that the TCG would be glad to do so if the IETF charters a Working Group to work on continuous assessment interfaces. I should know about this. I'm co-chair of the TCG's Trusted Network Connect Work Group. 5. Next Steps The SACM BOF participants should review the new SCAP Messages for IF-M specification to see if it meets their needs. If they find deficiencies, they should notify the TCG by sending email to SCAP-Messages-Comments@trustedcomputinggroup.org. Within IETF, we should review and discuss these documents to see if they are relevant to the SACM effort. Do they meet the need for continuous assessment interfaces that was described in the proposed SACM charter? If not, what changes are needed? Could those changes be made using these specs as a starting point, assuming that the TCG donated the specs to the IETF with all rights and full change Hanna Expires April 15, 2013 [Page 4] Internet-Draft Assessment Protocols and Formats October 2012 control? And should this work happen in a new Working Group or should it happen in the NEA Working Group, which already has five years of experience with this topic. The IETF discussions should happen on the sacm@ietf.org list. I would also be glad to lead a discussion of this topic at the SACM BOF at IETF 85. 6. Security Considerations This document describes several existing standards relating to endpoint assessment and configuration management. Each of these specifications includes its own Security Considerations section so the reader is referred to those documents for more details. 7. IANA Considerations This document has no actions for IANA. 8. References 8.1. Informative References [1] SACM BOF Draft Charter, http://www.ietf.org/mail- archive/web/sacm/current/msg00628.html [2] U.S. NIST, "The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2", NIST Special Publication 800-126 Revision 2, September 2011. [3] U.S. NIST, "Specification for the Extensible Configuration Checklist Description Format (XCCDF) Version 1.2", NIST Interagency Report 7275 Revision 4, September 2011. [4] The MITRE Corporation, "The OVAL(R) Language Specification Version 5.10.1", January 2012. [5] U.S. NIST, "Specification for the Open Checklist Interactive Language (OCIL) Version 2.0", NIST Interagency Report 7692, April 2011. [6] U.S. NIST, "Specification for Asset Identification 1.1", NIST Interagency Report 7693, June 2011. [7] The MITRE Corporation, http://cce.mitre.org [8] U.S. NIST, http://scap.nist.gov/specifications/cpe Hanna Expires April 15, 2013 [Page 5] Internet-Draft Assessment Protocols and Formats October 2012 [9] The MITRE Corporation, http://cve.mitre.org [10] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, June 2008. [11] Sangster, P., and K. Narayan, "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5792, March 2010. [12] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5793, March 2010. [13] Sangster, P., N. Cam-Winget, and J. Salowey, "PT-TLS: A TCP- based Posture Transport (PT) Protocol", draft-ietf-nea-pt-tls- 07.txt (work in progress), August 2012. [14] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods", draft-ietf-nea-pt-eap- 03.txt (work in progress), July 2012. [15] Bradner, S. and J. Contreras, "Rights Contributors Provide to the IETF Trust", RFC 5378, November 2008. [16] Bradner, S., "Intellectual Property Rights in IETF Technology", RFC 3979, March 2005. [17] Trusted Computing Group, "IF-M: TLV Binding", Version 1.0, Revision 37, March 2010. [18] Trusted Computing Group, "IF-TNCCS: TLV Binding", Version 2.0, Revision 16, January 2010. [19] Trusted Computing Group, "SCAP Messages for IF-M", Version 1.0, Revision 16, October 2012. 9. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Hanna Expires April 15, 2013 [Page 6] Internet-Draft Assessment Protocols and Formats October 2012 Author's Address Steve Hanna Juniper Networks, Inc. 79 Parsons Street Brighton, MA 02135 USA Email: shanna@juniper.net Hanna Expires April 15, 2013 [Page 7]