INTERNET-DRAFT S. Whitlock Intended Status: Informational Boeing Expires: November 11, 2010 May 10, 2010 Information Access Control: Problem Statement and Requirements draft-whitlock-iac-prob-00.txt Status of this Memo This Internet-Draft is submitted to IETF 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Whitlock Expires November 11, 2010 [Page 1] INTERNET DRAFT draft-whitlock-iac-prob-00.txt May 10, 2010 Abstract This document describes the need for and some of the characteristics of standards necessary to control the secure sharing of information in collaborative working environments. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2 The Problem . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 Non-Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1 Normative References . . . . . . . . . . . . . . . . . . . 7 8.2 Informative References . . . . . . . . . . . . . . . . . . 7 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Whitlock Expires November 11, 2010 [Page 2] INTERNET DRAFT draft-whitlock-iac-prob-00.txt May 10, 2010 1 Introduction This document describes the need for granular information access protection and an approach for achieving it. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2 The Problem The commercialization of the Internet has provided a platform for enterprises to collaborate with their supply chains in a virtual, rather than physical sense. Originally this collaboration was limited to file transfer and e-mail but as new tools have become available, it has taken a more sophisticated direction. The tools for protecting information and services in an Internet based collaboration environment have not kept pace with this growth. Enterprises are basically limited to two techniques for protecting their information: o Some form of tunnel based encryption (TLS, IPSec, etc.) o Bulk encryption of the information itself. The limitation with encryption is that protection is on or off, providing limited granularity of permissible actions that can be applied to the protected information. Tunnel based encryption protection is tied to a session or security association and terminates when that relationship ends. While direct encryption of the information itself persists, the information protection toggles between protected but unusable and usable but unprotected states. As organizations continue to invest in collaboration capabilities and share large amounts of information with their suppliers, customers, and partners, there is a need for fine grained access control that can more precisely specify how the information will be used as well as providing audit capability that supports regulatory and contractual requirements. There are current related product offerings that generally describe their capabilities as digital rights management technologies. To date these products assume that all participants have the same product and a tightly coupled identity system. This severely limits the ability Whitlock Expires November 11, 2010 [Page 3] INTERNET DRAFT draft-whitlock-iac-prob-00.txt May 10, 2010 to use any existing technology beyond corporate boundaries. Whitlock Expires November 11, 2010 [Page 4] INTERNET DRAFT draft-whitlock-iac-prob-00.txt May 10, 2010 3 Non-Approach Information protection (except for encryption) is often confused with copy protection. This occurs partly because some copy protection technologies are referred to as Digital Rights Management (DRM) technologies and some information protection products or technologies are referred to as Information Rights Management and both are often shortened to just Rights Management. In spite of the name similarity, the security model for both is very different. In the case of copy protection technologies, the owner of the information does not trust the consumer, yet needs to provide a way for the consumer to use the information, typically tied to a hard- ware instance of the information. In the Information Access Control Model, the different parties are collaborators and the desire is to guide the allowed actions as the information passes through a workflow. This is no different in principle than having computer accounts with different privilege sets or different roles in a database management system. The goal is to transfer that same sort of granularity and accountability to the information itself, providing protection independent of application or operating systems controls that can move with the information. This document is specifically about the latter case, providing granular access for collaborating parties, and specifically not copy protection. 4 Approach This approach applies general authorization principles to information, treating information as any any other resource. These guidelines were first articulated in ISO 10181-3:1996 [ISO10181-3] and the Open Group's X/Open Distributed Security Framework (XDSF) [XDSF], produced in 1994. The main architectural component is the separation of authorization (or access control) functions between making the decision and enforcement of those decisions. 10181/XDSF designate these as Access COntrol Enforcement Functions (AEF) and Access COntrol Decision Functions (ADF). IETF Working Groups (AAA for example) and Standards (COPS RFC4261, etc) typically use the terms POlicy Decision Point (PDP) for the ADF and Policy Enforcement Point (PEP) for the AEF. While a function, or operational capability, is more accurate than viewing these as single points in a network architecture, the terms PDP and PEP are in more common use so this document, while referencing the ISO model will use these terms. Whitlock Expires November 11, 2010 [Page 5] INTERNET DRAFT draft-whitlock-iac-prob-00.txt May 10, 2010 While a PDP/PEP architecture has generally been applied to network control, ISO 10181 takes a much more general approach and this same architecture is suitable for applications, operating systems controls and information itself. 5 Architecture Following the ISO model, some form of Policy Administration Point (PAP) would be used to apply specific access control policies to specified information instances or types. A PEP would apply the described protections to the information. A PDP would be consulted when applying and accessing the protected information. Access control protection is applied as follows: o Current products and technologies apply this protection via an API to a software container or envelope that encapsulates the information. The protection is typically based on some form of encryption. Access decisions are based on specified rights which are typically linked to an identity management system that contains individuals and groups of individuals and their respective attributes. o A participating application interacts with the access control service by querying it when access to a protected piece of information is required. If access is granted, the access control service supplies the required information to unlock the information to perform the granted access function. There are several candidates for standardization necessary to make different access control systems interact with each other. o First there needs to be a standard protocol or set of protocols to convey the information access requests and grants. These could be based on (or profiles of) an existing access control protocol such as OASIS XACML, or they could be protocols more specialized to the information access control use case or some hybrid - potentially an abstract layer on XACML. o Secondly, there needs to be a common API, container or mechanism to apply and remove the access control protection. o Finally, there needs to be a standard set of tags or meta data to convey the information access protection requirements. Standardizing on these three areas should enable multi-vendor interoperability. 6 Security Considerations Whitlock Expires November 11, 2010 [Page 6] INTERNET DRAFT draft-whitlock-iac-prob-00.txt May 10, 2010 This is a requirements statement and proposed approach, not a proposal for technology. Any working group using this requirements technology or protocols should carefully consider the requirements and use them as part of an input to developing technical standards that will be robust and secure. 7 IANA Considerations This document has no actions for IANA. 8 References 8.1 Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2 Informative References [ISO10181-3] IS0/IEC 10181-3, "Information technology -- Open Systems Interconnection -- Security frameworks for open systems: Access control framework", September 1996. [XDSF] "X/Open Guide: Distributed Security Framework", X/Open Document Number G410, October 1994. Author's Addresses Stephen T. Whitlock 10825 SE 233RD PL Kent, WA 98031 USA EMail: stephen.whitlock@boeing.com Whitlock Expires November 11, 2010 [Page 7]