- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 01 Sep 2010 17:03:42 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/policy-reqs
In directory hutz:/tmp/cvs-serv31344
Added Files:
WD-src.html WD.html
Log Message:
WD publication
--- NEW FILE: WD.html ---
<!DOCTYPE html PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN' 'http://www.w3.org/TR/html4/loose.dtd'>
<html lang="en" dir="ltr">
<head>
<title>Device API Access Control Use Cases and Requirements</title>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
<!-- <script src='../ReSpec.js/js/respec.js' class='remove'></script> -->
<link href="http://www.w3.org/StyleSheets/TR/W3C-WD" rel="stylesheet" type="text/css" charset="utf-8"></head><body style="display: inherit; "><div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" src="http://www.w3.org/Icons/w3c_home" alt="W3C"></a></p><h1 class="title" id="title">Device API Access Control Use Cases and Requirements</h1><h2 id="w3c-working-draft-07-september-2010">W3C Working Draft 07 September 2010</h2><dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2010/WD-dap-policy-reqs-20100907/">http://www.w3.org/TR/2010/WD-dap-policy-reqs-20100907/</a></dd><dt>Latest published version:</dt><dd><a href="http://www.w3.org/TR/dap-policy-reqs/">http://www.w3.org/TR/dap-policy-reqs/</a></dd><dt>Latest editor's draft:</dt><dd><a href="http://dev.w3.org/2009/dap/policy-reqs/">http://dev.w3.org/2009/dap/policy-reqs/</a></dd><dt>Previous version:</dt><dd>none</dd><dt>Editors:</dt><dd><span>Laura Arribas</span>, <a href="http://vodafone.com/">Vodafone</a></dd>
<dd><span>Paddy Byers</span>, <a href="http://www.aplix.com/">Aplix</a></dd>
<dd><span>Frederick Hirsch</span>, <a href="http://www.nokia.com/">Nokia</a></dd>
<dd><span>David Rogers</span>, <a href="http://omtp.org/">OMTP</a></dd>
</dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2010 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p><hr></div>
<div id="abstract" class="introductory section"><h2>Abstract</h2>
This document describes Device API Access Control Use Cases and
corresponding Requirements.
</div><div id="sotd" class="introductory section"><h2>Status of This Document</h2><p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/">W3C technical reports index</a> at http://www.w3.org/TR/.</em></p>
This document is not normative. The Working Group expects to evolve
this document further and will eventually publish a stable
version as a Working Group Note.
<p>This document was published by the <a href="http://www.w3.org/2009/dap/">Device APIs and Policy Working Group</a> as a Working Draft. If you wish to make comments regarding this document, please send them to <a href="mailto:public-device-apis@w3.org">public-device-apis@w3.org</a> (<a href="mailto:public-device-apis-request@w3.org?subject=subscribe">subscribe</a>, <a href="http://lists.w3.org/Archives/Public/public-device-apis/">archives</a>). All feedback is welcome.</p><p>Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</p><p>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C Patent Policy</a>. The group does not expect this document to become a W3C Recommendation. W3C maintains a <a href="http://www.w3.org/204/01/pp-impl/43696/status" rel="disclosure">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the W3C Patent Policy</a>.</p></div><div id="toc" class="section"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a href="#introduction" class="tocxref"><span class="secno">1. </span>Introduction</a></li><li class="tocline"><a href="#web-case" class="tocxref"><span class="secno">2. </span>Web Browser and Untrusted Widgets</a><ul class="toc"><li class="tocline"><a href="#web-case-overview" class="tocxref"><span class="secno">2.1 </span>Use Case Overvew</a></li><li class="tocline"><a href="#web-case-rqmts" class="tocxref"><span class="secno">2.2 </span>Requirements</a></li><li class="tocline"><a href="#web-issues" class="tocxref"><span class="secno">2.3 </span>Issues</a></li></ul></li><li class="tocline"><a href="#trusted-widget-case" class="tocxref"><span class="secno">3. </span>Trusted Widget or Application</a><ul class="toc"><li class="tocline"><a href="#widget-case-overview" class="tocxref"><span class="secno">3.1 </span>Use Case Overview</a></li><li class="tocline"><a href="#widget-case-rqmts" class="tocxref"><span class="secno">3.2 </span>Requirements</a></li></ul></li><li class="tocline"><a href="#delegated-authority-case" class="tocxref"><span class="secno">4. </span>Delegated Authority</a><ul class="toc"><li class="tocline"><a href="#delegated-authority-case-overview" class="tocxref"><span class="secno">4.1 </span>Use Case Overview</a></li><li class="tocline"><a href="#delegated-authority-case-rqmts" class="tocxref"><span class="secno">4.2 </spn>Requirements</a></li><li class="tocline"><a href="#delegated-authority-case-examples" class="tocxref"><span class="secno">4.3 </span>Policy Examples</a></li></ul></li><li class="tocline"><a href="#threats" class="tocxref"><span class="secno">5. </span>Security and Privacy Threats</a><ul class="toc"><li class="tocline"><a href="#premium-rate-abuse" class="tocxref"><span class="secno">5.1 </span>Abuse Case AC1: Premium Rate Abuse</a></li><li class="tocline"><a href="#privacy-breach" class="tocxref"><span class="secno">5.2 </span>Abuse Case AC2: Privacy Breach</a></li><li class="tocline"><a href="#integrity-breach" class="tocxref"><span class="secno">5.3 </span>Abuse Case AC3: Integrity Breach</a></li><li class="tocline"><a href="#phishing" class="tocxref"><span class="secno">5.4 </span>Abuse Case AC4: Phishing</a></li></ul></li><li class="tocline"><a href="#acknowledgements" class="tocxref"><span class="secno">A. </span>Acknowledgements</a></li><li class="tocline"><a href="#references" class="tocxref"><spanclass="secno">B. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">B.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">B.2 </span>Informative references</a></li></ul></li></ul></div> <!-- abstract -->
<div id="introduction" class="informative section">
<!--OddPage--><h2><span class="secno">1. </span>Introduction</h2><p><em>This section is non-normative.</em></p>
<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:</p>
<ul>
<li>web browser web pages and untrusted widgets</li>
<li>trusted widgets and applications</li>
<li>delegated authority</li>
</ul>
<p>They are related because requirements for the web may
also apply to trusted widgets, and those various requirements may
also apply to delegated authority, likewise trusted widget/application
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>
</div> <!-- introduction -->
<div id="web-case" class="informative section">
<!--OddPage--><h2><span class="secno">2. </span>Web Browser and Untrusted Widgets</h2><p><em>This section is non-normative.</em></p>
<div id="web-case-overview" class="informative section">
<h3><span class="secno">2.1 </span>Use Case Overview</h3><p><em>This section is non-normative.</em></p>
<p>The 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:</p>
<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>
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>
An un-trusted widget (i.e. unsigned widget or widget signed by an
unknown or untrusted authority) should be treated in the
same manner as a web browser, since the risks
are the same.</p>
<p>
In summary:</p>
<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>
</div>
<div id="web-case-rqmts" class="informative section">
<h3><span class="secno">2.2 </span>Requirements</h3><p><em>This section is non-normative.</em></p>
<p>
</p><ul>
<li>The security framework <em class="rfc2119" title="must not">must not</em> 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 <em class="rfc2119" title="should">should</em> allow users to have control
over general configuration of security
decisions</li>
<li>The security policy framework <em class="rfc2119" title="should">should</em> 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>
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 <em class="rfc2119" title="should">should</em> 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 <em class="rfc2119" title="must">must</em> 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>
</div>
<div id="web-issues" class="informative section">
<h3><span class="secno">2.3 </span>Issues</h3><p><em>This section is non-normative.</em></p>
<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>
</div>
</div> <!-- web -->
<div id="trusted-widget-case" class="informative section">
<!--OddPage--><h2><span class="secno">3. </span>Trusted Widget or Application</h2><p><em>This section is non-normative.</em></p>
<div id="widget-case-overview" class="informative section">
<h3><span class="secno">3.1 </span>Use Case Overview</h3><p><em>This section is non-normative.</em></p>
<p>The trusted Widget or application Device API use case is
where a trusted widget or application is
delivered to a device.
In this case the entire widget or application
can be trusted as an desktop application would be, so if installed
should have a set of privileges associated with a trusted
software.
Thus it 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>
<p>
Trust may be established in different ways, the most common being
through a validated signature on the widget or application package,
with a corresponding verification of the trust chain to a trusted root.
Alternative means of determining trust are also possible, such as
using a reputation or other mechanism.
</p>
<p>
Once trust is established, a trusted widget or application
might have explicit policy associated with it. In this case it
can be treated the same as in the delegated authority case
below, or it may not have explicit policy, but additional
API functionality may in general be allowed due to the
trust. In this case user acceptance of the entire widget or
application ,
similar to personal computer application install, may be appropriate.
</p>
</div>
<div id="widget-case-rqmts" class="informative section">
<h3><span class="secno">3.2 </span>Requirements</h3><p><em>This section is non-normative.</em></p>
<ul>
<li><p>Trust be established to a satisfactory level. In the
case of using
signature in conjunction with PKI mechanisms, the
signature <em class="rfc2119" title="must">must</em> be
verified and the certificate chain <em class="rfc2119" title="must">must</em> be validated to
a known trust
root.</p></li>
<li><p>Other mechanisms than signatures may be used if they
offer robust enough trust verification.</p></li>
</ul>
</div>
</div> <!-- trusted widget -->
<div id="delegated-authority-case" class="informative section">
<!--OddPage--><h2><span class="secno">4. </span>Delegated Authority</h2><p><em>This section is non-normative.</em></p>
<div id="delegated-authority-case-overview" class="informative section">
<h3><span class="secno">4.1 </span>Use Case Overview</h3><p><em>This section is non-normative.</em></p>
<p>The Delegated Authority 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:</p>
<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>
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>
</div>
<div id="delegated-authority-case-rqmts" class="informative section">
<h3><span class="secno">4.2 </span>Requirements</h3><p><em>This section is non-normative.</em></p>
<ul>
<li><p>Policy <em class="rfc2119" title="should">should</em> 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 <em class="rfc2119" title="should">should</em> 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 <em class="rfc2119" title="must">must</em> be separable from policy
rules.</li>
<li>Access control policy <em class="rfc2119" title="must">must</em> be stated in declarative
manner.</li>
<li>The DAP policy language <em class="rfc2119" title="must">must</em> define an XML syntax for
that language.</li>
<li>It <em class="rfc2119" title="must">must</em> 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 <em class="rfc2119" title="must not">must not</em> preclude different
authorities defining the security policy.
</li>
<li>The Security Framework <em class="rfc2119" title="must">must</em> allow multiple instantiations of a web
runtime with independent security decisions</li>
<li>The Security Framework <em class="rfc2119" title="must">must</em> be application language
independent</li>
<li>The Security Framework <em class="rfc2119" title="must">must</em> be Javascript capable and
define a Javascript binding</li>
<li>It <em class="rfc2119" title="must">must</em> be possible to have separate policy decision and
enforcement points</li>
<li>The DAP security model <em class="rfc2119" title="should">should</em> be compatible with the
same origin policy.</li>
<li>The security framework <em class="rfc2119" title="must">must</em> support sufficient granularity
for sensible access control decisions. (features )
</li>
</ul>
<p>
Note that separation of the security framework from policy
statements
can be achieved using declarative
policy statements.
</p>
</div>
<div id="delegated-authority-case-examples" class="informative section">
<h3><span class="secno">4.3 </span>Policy Examples</h3><p><em>This section is non-normative.</em></p>
<p>
This section provides specific examples of statements or
rules that may be
expressed in a policy.
</p>
<p>Example web site policy cases:</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>
<p>Example widget policy cases:</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>
</div>
</div> <!-- delgated authority -->
<div id="threats" class="informative section">
<!--OddPage--><h2><span class="secno">5. </span>Security and Privacy Threats</h2><p><em>This section is non-normative.</em></p>
<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>
<div id="premium-rate-abuse" class="section">
<h3><span class="secno">5.1 </span>Abuse Case AC1: Premium Rate Abuse</h3>
<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>
</div> <!-- premium rate Abuse -->
<div id="privacy-breach" class="section">
<h3><span class="secno">5.2 </span>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>
</div> <!-- privacy-breach -->
<div id="integrity-breach" class="section">
<h3><span class="secno">5.3 </span>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>
</div> <!-- integrity-breach -->
<div id="phishing" class="section">
<h3><span class="secno">5.4 </span>Abuse Case AC4: Phishing</h3>
<p>
Widgets contain web content making it is easy to duplicate
and masquerade as something legitimate… perhaps a bank?
</p>
<p>
In January 2010, Google removed a number of applications
from the Android Market which were supposed to be banking
applications for a number of different banks worldwide. It
is unclear whether these applications were intentional
phishing applications. The removal was based on a breach
of terms and conditions surrounding copyright. The episode
however highlighted the phishing potential. Widgets
contain web content, therefore it is very easy to
duplicate the look and feel of something that the user
trusts and proceed to abuse that trust either by stealing
credentials or by manipulating money transfers.
</p>
<p>
These are of course just examples to consider in relation to how we
would manage the policies for device APIs and are of course not
exhaustive. Alongside the device-API specific examples
above, we still
need to consider traditional web threats which pose a
significant risk
and lots of other types of attack which should be considered in a
formal threat model.
</p>
</div> <!-- phishing -->
</div> <!-- threats -->
<div class="appendix section" id="acknowledgements">
<!--OddPage--><h2><span class="secno">A. </span>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>
</div>
<div id="respec-err" style="position: fixed; width: 350px; top: 10px; right: 10px; border: 3px double #f00; background: #fff" class="removeOnSave"><ul><li style="color: #c00">There appears to have been a problem fetching the style sheet; status=0</li></ul></div><div id="references" class="appendix section"><!--OddPage--><h2><span class="secno">B. </span>References</h2><div id="normative-references" class="section"><h3><span class="secno">B.1 </span>Normative references</h3><p>No normative references.</p></div><div id="informative-references" class="section"><h3><span class="secno">B.2 </span>Informative references</h3><p>No informative references.</p></div></div></body></html>
--- NEW FILE: WD-src.html ---
<!DOCTYPE html>
<html>
<head>
<title>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: "WD",
shortName: "dap-policy-reqs",
publishDate: "2010-09-07",
// 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 describes Device API Access Control Use Cases and
corresponding Requirements.
</section> <!-- abstract -->
<section id='sotd'>
This document is not normative. The Working Group expects to evolve
this document further and will eventually publish a stable
version as a Working Group Note.
</section>
<section id='introduction' class='informative'>
<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:</p>
<ul>
<li>web browser web pages and untrusted widgets</li>
<li>trusted widgets and applications</li>
<li>delegated authority</li>
</ul>
<p>They are related because requirements for the web may
also apply to trusted widgets, and those various requirements may
also apply to delegated authority, likewise trusted widget/application
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' class='informative'>
<h3>Web Browser and Untrusted Widgets</h3>
<section id='web-case-overview' class='informative'>
<h4>Use Case Overview</h4>
<p>The 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:</p>
<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>
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>
An un-trusted widget (i.e. unsigned widget or widget signed by an
unknown or untrusted authority) should be treated in the
same manner as a web browser, since the risks
are the same.</p>
<p>
In summary:</p>
<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>
</section>
<section id='web-case-rqmts' class='informative'>
<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>
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" class='informative'>
<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' class='informative'>
<h3>Trusted Widget or Application</h3>
<section id='widget-case-overview' class='informative'>
<h4>Use Case Overview</h4>
<p>The trusted Widget or application Device API use case is
where a trusted widget or application is
delivered to a device.
In this case the entire widget or application
can be trusted as an desktop application would be, so if installed
should have a set of privileges associated with a trusted
software.
Thus it 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>
<p>
Trust may be established in different ways, the most common being
through a validated signature on the widget or application package,
with a corresponding verification of the trust chain to a trusted root.
Alternative means of determining trust are also possible, such as
using a reputation or other mechanism.
</p>
<p>
Once trust is established, a trusted widget or application
might have explicit policy associated with it. In this case it
can be treated the same as in the delegated authority case
below, or it may not have explicit policy, but additional
API functionality may in general be allowed due to the
trust. In this case user acceptance of the entire widget or
application ,
similar to personal computer application install, may be appropriate.
</p>
</section>
<section id='widget-case-rqmts' class='informative'>
<h4>Requirements</h4>
<ul>
<li><p>Trust be established to a satisfactory level. In the
case of using
signature in conjunction with PKI mechanisms, the
signature MUST be
verified and the certificate chain MUST be validated to
a known trust
root.</p></li>
<li><p>Other mechanisms than signatures may be used if they
offer robust enough trust verification.</p></li>
</ul>
</section>
</section> <!-- trusted widget -->
<section id='delegated-authority-case' class='informative'>
<h3>Delegated Authority</h3>
<section id='delegated-authority-case-overview' class='informative'>
<h4>Use Case Overview</h4>
<p>The Delegated Authority 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:</p>
<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>
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' class='informative'>
<h4>Requirements</h4>
<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>
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' class='informative'>
<h3>Policy Examples</h3>
<p>
This section provides specific examples of statements or
rules that may be
expressed in a policy.
</p>
<p>Example web site policy cases:</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>
<p>Example widget policy cases:</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> <!-- delgated authority -->
<section id="threats" class='informative'>
<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>
Widgets contain web content making it is easy to duplicate
and masquerade as something legitimate… perhaps a bank?
</p>
<p>
In January 2010, Google removed a number of applications
from the Android Market which were supposed to be banking
applications for a number of different banks worldwide. It
is unclear whether these applications were intentional
phishing applications. The removal was based on a breach
of terms and conditions surrounding copyright. The episode
however highlighted the phishing potential. Widgets
contain web content, therefore it is very easy to
duplicate the look and feel of something that the user
trusts and proceed to abuse that trust either by stealing
credentials or by manipulating money transfers.
</p>
<p>
These are of course just examples to consider in relation to how we
would manage the policies for device APIs and are of course not
exhaustive. Alongside the device-API specific examples
above, we still
need to consider traditional web threats which pose a
significant risk
and lots of other types of attack which should be considered in a
formal threat model.
</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 Wednesday, 1 September 2010 17:03:46 UTC