- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Sat, 14 Aug 2010 00:49:40 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/docs In directory hutz:/tmp/cvs-serv18732 Added Files: policy-requirements-proposal.html Log Message: proposed change to policy requirements - change title and restructure document, reflecting WG discussions at F2F --- NEW FILE: policy-requirements-proposal.html --- <html> <head> <title>(Proposed Revision:) Device API Access Control Use Cases and Requirements</title> <meta http-equiv='Content-Type' content='text/html;charset=utf-8'/> <script src='http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js' class='remove'></script> <!-- <script src='../ReSpec.js/js/respec.js' class='remove'></script> --> <script class='remove'> var respecConfig = { specStatus: "ED", shortName: "dap-policy-reqs", // publishDate: "2010-06-29", // previousPublishDate: "1977-03-15", edDraftURI: "http://dev.w3.org/2009/dap/policy-reqs/", // lcEnd: "2009-08-05", noRecTrack: true, }; </script> <script src='http://dev.w3.org/2009/dap/common/configPolicy.js' class='remove'></script> </head> <body> <section id='abstract'> This document defines Device API Access Control Requirements and the corresponding use cases. </section> <!-- abstract --> <section id='sotd'> This document is expected to be further updated based on both Working Group input and public comments. The Working Group anticipates to eventually publish a stabilized version of this document as a W3C Working Group Note. </section> <section id='introduction'> <h2>Introduction</h2> <p> The DAP working group is defining APIs designed to enable application access to device resources, including personal contact information such as calendar and contacts information, system information such as network information, and other information. Much of this information is sensitive and potentially misused. For this reason the DAP working group charter explicitly calls out the need to control access to this information, such as through the use of policy. </p> <p>The management of security policies and revocation mechanisms are out of scope.</p> <p>The approach taken in this document is to simplify the possible interactions by considering three related use cases: <ul> <li>un-managed web</li> <li>trusted widgets</li> <li>delegated authority</li> </ul> </p> <p>They are related because requirements for the un-managed web may also apply to trusted widgets, and those various requirements may also apply to delegated authority, likewise trusted widget requirements may apply to delegated authority case. Each level may add additional requirements. For example, the requirement for minimal user-dialogs may apply to all, while requirements on interoperable policy languages may only apply to the delegated authority case. </p> </section> <!-- introduction --> <section id='web-case'> <h3>Un-managed Web Browser</h3> <section id='web-case-overview'> <h4>Use Case Overview</h4> <p>The un-managed web browser Device API use case is the one where a web page invokes the Device API as part of the page code, such as Javascript.</p> <p>This case cannot assume a policy framework that is accepted and managed for all parts of the web.</p> <p>As a result any device API available to such web pages must observe these two requirements: <ol> <li>If no user-interaction is involved, use of the API must be safe.</li> <li>If not safe, then user consent is required for each use of the API. This consent should appear as a part of the task specific workflow, thus not necessarily appear as a permission dialog.</li> </ol> </p> <p> A user may wish to establish a policy configuration (through explicit configuration of preferences, and remembered decisions) and there is the option of reusing this configuration across multiple devices. A user with multiple devices may wish for their security preferences to be consistent (or to at least have the option of consistency) across those devices. Rather than have to manually configure the preferences on each device, it should be possible for there to be a seamless security experience across devices, e.g. by switching SIM card between devices and as a result automatically applying a policy resident on the SIM card or synchronizing with a network-based policy management system. A specific case is the case where a user wishes to transfer a configuration from an old device to a new device. To be consistent with the delegated authority case a similar mechanism for remembering state might be appropriate. </p> <p> In summary: <ul> <li>the user of a device is the sole authority that decides access rights of applications;</li> <li> there is no external policy authority and hence no explicit policy</li> <li>APIs must be designed to require appropriate user interaction or be safe by default</li> <li>There is an open question as to how users may set and remember preferences and if such settings should be interoperable across browsers and stored locally or remotely.</li> </ul> </p> </section> <section id='web-case-rqmts'> <h4>Requirements</h4> <p> <ul> <li>The security framework MUST NOT require User Agents to present modal dialogs to prompt users for security decisions, while the application is running. <ul><li>Note: modal dialogs may be required for security prompts provided during application installation or invocation.</li></ul> </li> <li>The security framework SHOULD allow users to have control over general configuration of security decisions</li> <li>The security policy framework SHOULD make it possible to record security configuration choices and interactive policy decisions using the policy markup language format.</li> </ul> <p> Prompts should be eliminated whenever possible. Many prompts do not provide any meaningful security because:</p> <ul> <li>they don't provide the user with the information needed to make an informed security decision;</li> <li>with modal prompts, the user is inclined simply to dismiss the prompt and permit the operation just because that's what's needed for the application to continue.</li> </ul> </p> <p> If prompts are shown and dismissed as a matter of routine, then the user is less inclined to take any security decision seriously, which further undermines the effectiveness of a user-driven access control system. </p><p> It is important to note that modal prompts (i.e. prompts that block all other user interaction until dismissed) seriously compromise the user experience. Modal security prompts SHOULD be avoided. </p><p> Any prompt or dialog that requests a user security decision at runtime (e.g. at the time a sensitive action is attempted) can be non-modal if the API that initiates it is asynchronous. DAP APIs MUST be designed so that all operations that could potentially trigger a prompt are asynchronous. </p> <p> If user decisions are themselves expressible in the policy language, then they can be "remembered" by adding a policy-set and/or rule to the policy. Similarly, user configuration settings should be possible in the policy language. This means that the policy document is not just a way of creating an initial policy configuration, but can be the sole and complete representation of the access control configuration at any time. </p> </section> <section id="web-issues"> <h3>Issues</h3> <ul> <li> Granularity of user decisions <p class='issue'> What is the correct granularity of security decisions presented to user? Perhaps this should be stated in policy. What is the linkage to application logic? </p><p> This issue is whether the user is presented with a single security decision that covers multiple operations, or independent prompts for individual operations. Blanket authorization for an application to use multiple APIs, as often as required, eliminates run-time prompts but also may leave the user without the context required to make a meaningful security decision. Also, a user may not be prepared to give blanket approval for a certain operation but may instead wish to give permission in specific circumstances only. </p><p> Different permission granularities have advantages for different use cases so the requirement might be to support different granularities for different cases. </p></li> </ul> </section> </section> <!-- web --> <section id='trusted-widget-case'> <h3>Trusted Widget</h3> <section id='widget-case-overview'> <h4>Use Case Overview</h4> <p>The trusted Widget Device API use case is where a signed widget is delivered to a device. In this case the entire widget can be trusted as an application would be, so if installed should have a set of privileges associated with a trusted software.</p> <p>Thus a trusted widget should be able to use all safe APIs that could be used in the web case, but may also be able to use additional APIs that are not safe, such as APIs that do not require specific user consent in each case. However this list must be carefully controlled. </p> </section> <section id='widget-case-rqmts'> <h4>Requirements</h4> <p> </p> </section> <section id='widget-policy-examples'> <h3>Policy Examples</h3> <p> These use cases are specific examples of statements or rules that may be expressed in a policy. </p> <p>Example web site use cases, to give examples of the types of policy that might be expressed:</p> <ul> <li> A reliably identified website can access geolocation coordinates if the user confirms it’s OK. </li><li> Any website in a subdomain of <code>mynetwork.example.com</code> can read phone status properties. </li><li> Reliably identified websites can send and receive SMS except to premium rate numbers. </li><li> <code>evil.example.com</code> cannot access any device APIs. </li><li> The <code>weather.example.com</code> <var>foo</var> widget can access geolocation coordinates but only if it’s embedded on the <var>foo</var> home page. </li> </ul> </section> </section> <!-- trusted widget --> <section id='delegated-authority-case'> <h3>Delegated Authority</h3> <section id='delegated-authority-case-overview'> <h4>Use Case Overview</h4> <p>The enterprise Managed Device API use case includes the use of explicit and interoperable policy definitions to control the use of an extensive set of APIs, save and unsafe. Such rules may be used in the case of a trusted widget or the web case with clients that support it. It may be deployed by an Enterprise or a Mobile Operator, to give two examples. </p> <p>This can be viewed as delegation of authority for access control policy to an external service provider. This external service provider provides advice on the trustworthiness of specific applications, and determines an access control policy that embodies that advice. The advice may be based on a knowledgebase of known trustworthy and/or malicious applications, or algorithms for detecting malicious behavior, or both. The policy defined by the external authority may be updated regularly in response to new information on known threats. </p> <p> This use-case mirrors current practice with products such as virus scanners or other malware detectors. </p> <p> In summary: <ul> <li>the user of a device delegates authority to an external policy provider;</li> <li> an initial security policy configuration may be provided by the external authority, together with any other associated device configuration (such as root certificates). The configured policy may determine access control policy without reference to the user, or may refer certain decisions to the user; </li> <li>The user may or may not be able to modify this policy;</li> <li> the policy may be updated periodically under the authority of the policy authority. Policy maintenance may also occur as the cumulative effect of certain user decisions being remembered. </li> <li>The configured policy, at any given time, may be stored locally on the device or may be stored remotely and be accessible via a network service, or both; </li> <li>The external policy authority may configure the policy as part of the commissioning of the device (e.g. a network operator's configuration applied by the manufacturer prior to sale, or an enterprise configuring device policy using a secured device management interface). </li> </ul> </p> <p> In determining the policy, the policy authority has the opportunity to define a policy that supports a specific objective - such as to limit access to APIs to only those web applications that are themselves distributed by the policy authority (e.g. to control its exposure to the financial risk of abuse of device APIs). </p> </section> <section id='delegated-authority-case-rqmts'> <h4>Requirements</h4> <p> <ul> <li><p>Policy SHOULD be defined in a portable device-independent manner.</p> <p> The reason for this requirement is that a single policy authority may need to define and configure a security policy for multiple dissimilar devices. A typical network operator's portfolio many include tens or even hundreds of models, each based on different platforms, and different UAs. A commonly supported interoperable format for configuration of a policy dramatically impacts the practicality of achieving the desired configuration across all devices. </p> </li> <li>It SHOULD be possible to update portions of policy independently. <p> Configuration of some parts of access control policy may be part of the overall configuration required to enable a particular application or service. This, along with many other configuration parameters, may be remotely configurable via device management. The configuration required to enable a service may be provided by the service provider as a policy fragment, to be added to the overall policy by the policy authority. An interoperable representation of such policy fragments would enable this to be done without authoring the configuration updates separately for each target device, platform, or UA. </p> </li> <li>Security Framework MUST be separable from policy rules.</li> <li>Access control policy MUST be stated in declarative manner.</li> <li>The DAP policy language MUST define an XML syntax for that language.</li> <li>It MUST be possible to provide integrity protection and source authentication for policy. <p>It should be possible for policy to be integrity protected during various points in its life-cycle.</p> </li> <li>The DAP security framework MUST NOT preclude different authorities defining the security policy. </li> <li>The Security Framework MUST allow multiple instantiations of a web runtime with independent security decisions</li> <li>The Security Framework MUST be application language independent</li> <li>The Security Framework MUST be Javascript capable and define a Javascript binding</li> <li>It MUST be possible to have separate policy decision and enforcement points</li> <li>The DAP security model SHOULD be compatible with the same origin policy.</li> <li>The security framework MUST support sufficient granularity for sensible access control decisions. (features ) </li> </ul> </p> <p> Note that separation of the security framework from policy statements can be achieved using declarative policy statements. </p> </section> <section id='delegated-authority-case-examples'> <h3>Policy Examples</h3> <p> These use cases are specific examples of statements or rules that may be expressed in a policy. </p> <ul> <li> A widget whose signature chains to operator root can read and write from the PIM databases. </li><li> A widget downloaded from <code>weather.example.com</code> can access geolocation coordinates if the user says it’s OK. </li><li> The <code>weather.example.com</code> widget can connect to <code>weather.example.com</code> without notifying the user, except when roaming. </li><li> All widgets with a reliably identified author can save data persistently if the user says it’s OK. </li><li> No widget can get my location, no matter who trusts it. </li><li> No widget can access <code>evil.example.org</code>. </li><li> An unsigned widget cannot launch another application without user consent. </li> </ul> </section> <section id="delegated-authority-issues"> <h4>Issues</h4> <p class="issue">Whether requirements are needed specifying need to define capabilities in addition to features deferred since this is a higher level document at this time. </p> <p class="issue">Define features, capabilities as URIs, strings, both</p> <p class="issue"> Features defined according to CRUD, one feature for Create, Read, Update, Delete? </p> <p class="issue"> Feature parameters to avoid explosion of capabilities and features? e.g. file open with either read or write parameter. ( see <a href="http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/att-0120/minutes-2009-10-07.html#item03">discussions in minutes of October 7 call</a> ) </p> </section> <!-- delegated authority issues --> </section> <!-- delgated authority --> <section id="threats"> <h3>Security and Privacy Threats</h3> <p> This section outlines some threats related to the Device APIs. </p> <p> The landscape that is being created is the enablement of cross-platform, cross-device, easy to develop, highly functional applications based on browser technology that has been proven repeatedly to be untrustworthy - a perfect recipe for evil. Will this meet all the criteria for really successful malware on mobile devices for example? </p> <p> Up until now the measures taken by the mobile industry have proven highly successful in ensuring no major malware incident has affected the industry. There have been attempts: the MMS-spreading Commwarrior is probably the most infamous, along with the Spyware tool, Flexispy. An additional factor in ensuring the success of mobile security has been the fact that mobile platforms have been too fragmented and complex, therefore not representing an attractive target so far. Existing modus operandi from technology-related attacks can provide indicators as to the types of attack and abuse that can be expected on widgets and web applications as device APIs are opened up. </p> <section id="premium-rate-abuse"> <h2>Abuse Case AC1: Premium Rate Abuse</h2> <p>A widget that seems benign but is actually spewing out SMSs to premium rate numbers without the user’s knowledge. This could be modified from an original safe widget such as a game. For the malware author, the key piece to solve is to dupe the user into thinking that the SMS capability is something that is part of the original application. Examples of this have been seen in the past, created from games and this model could be used for ‘diallers’ too (which plagued the desktop world in the days of dial-up networking). There have been recent warnings about this kind of abuse from security firms. </p> </section> <!-- premium rate Abuse --> <section id="privacy-breach"> <h3>Abuse Case AC2: Privacy Breach</h3> <p>An application that gains access to locations, contacts and gallery, silently uploading the data in the background to a site owned by the attacker. This is something that has been a clear goal for attackers already. There have been numerous high-profile examples in the past in the mobile world. Celebrities such as Paris Hilton, Miley Cyrus and Lindsay Lohan have all had private pictures, phone numbers and voicemails stolen from devices or networks in clear breach of their privacy. There has been embarrassment for teachers who had their pictures and videos copied by the children in their class and spread around school. The most high-profile case in the UK of a mobile related privacy breach was that of the News of the World's use of voicemail hacking to gain access to private information about Royalty. The Royal editor, Clive Goodman was jailed for four months and the editor, Andy Coulson resigned over this blatant privacy breach. Given the appetite for breaching privacy, users need to be safe in the knowledge that their personal data will not leak in any way. </p> </section> <!-- privacy-breach --> <section id="integrity-breach"> <h3>Abuse Case AC3: Integrity Breach</h3> <p>A widget that replaces the voicemail number with a premium rate number instead? There are number of reasons why an attacker would want to breach the integrity of the device. Simply changing the telephone number of the voicemail that is stored on the device could be enough to make an attacker a lot of money. Users usually have a shortcut key to their voicemail and may not notice for a long time that anything is wrong. A more sinister use could be to plant evidence on a device. Pictures, files and even criminal contacts could potentially be anonymously planted all without the user's consent or knowledge. Proving innocence could suddenly become very difficult. There are also a number of reasons why somebody would want to steal data. The contents of corporate e-mails would be very interesting to a competitor, as would sabotaging data stored in spreadsheets and presentations on the target phone. </p> </section> <!-- integrity-breach --> <section id="phishing"> <h3>Abuse Case AC4: Phishing</h3> <p>A widget that replaces the voicemail number with a premium rate number instead? There are number of reasons why an attacker would want to breach the integrity of the device. Simply changing the telephone number of the voicemail that is stored on the device could be enough to make an attacker a lot of money. Users usually have a shortcut key to their voicemail and may not notice for a long time that anything is wrong. A more sinister use could be to plant evidence on a device. Pictures, files and even criminal contacts could potentially be anonymously planted all without the user's consent or knowledge. Proving innocence could suddenly become very difficult. There are also a number of reasons why somebody would want to steal data. The contents of corporate e-mails would be very interesting to a competitor, as would sabotaging data stored in spreadsheets and presentations on the target phone. </p> </section> <!-- phishing --> </section> <!-- threats --> <section class='appendix'> <h2>Acknowledgements</h2> <p> The editors would like to extend special thanks to Nokia, OMTP BONDI, and PhoneGap for providing the foundation of the working group's requirements discussion. </p> </section> </body> </html>
Received on Saturday, 14 August 2010 00:49:43 UTC