Re: [security] describing trust domain requirements for policy requirements draft

Hi,

One apparent difference of the BONDI [1], [2]  and Nokia [3] submissions to
> the DAP WG is the handling of trust domains.
>
> The Nokia input, given in the position paper, has trust domain handling
> explicit, with a "trust manager" determining the trust domain based on
> various inputs, in particular origin, and possibly signatures/certificates.
> Access control policy may then be based on trust domain, with different
> decisions based on the (named) trust domain.
>
> I'd suggest the BONDI security model also requires trust domain handling,
> with inputs in the "subject attribute" in section 5.4, Logical Model [2],
> e.g. origin, signatures/certificates etc. In this case a trust domain is not
> named, but is implicit in the subject + subject attribute information which
> drives access decisions. Another way of saying this is that for the two
> classes ("widget" and "website") there are various combinations of
> attributes noted in BONDI Security Appendix B, and a number of these
> combinations could correspond to the same policy decisions, and be named as
>  "trust domains". It doesn't look like that many - untrusted, widget/website
> signed (by author,  distributor, both)?
>

To be simplistic, the separation of trust domains and policy in the Nokia
framework separates the definition of:

- the "who": ie which subjects are grouped together for the purposes of
defining access control rules;
- the "what": ie the rules themselves.

The "who" is defined by the trust domains, and the "what" is defined by the
policy.

Unsurprisingly, the BONDI model allows and expects this same separation.

The building block of a BONDI access control policy is the <policy> element.
Within a <policy>:

- the child <target> elements defines the "who" - each is an expression
involving the subject attributes that defines those subjects to which the
policy applies;
- the child <rule> elements define the "what".

Instead of binding these two together by explcitly naming the trust domains,
as in the Nokia case, BONDI binds them together implicitly by defining them
within the same <policy>.

Although BONDI then defines <policy-set>, and gives a variety of different
ways to combine <policy>s, specify precedence, create child <policy>s with
more specific <target>s (ie "sub domains") the principle is the same.

I think the differences in approach are more to do with who configures the
policy and what it is intended to represent.

One obvious use case is where some policy authority (eg the network
operator) creates a policy configuration, which is embedded when a phone is
manufactured. However, many devices will have no such initial configuration
(other than that applied by the manufacturer) and no external policy
authority. As we've seen from the discussion of policy for web applications,
the configuration (ie the policy) may be nothing more than the user's own
configuration - partly from explicit configuration settings ( eg what IE
gives you with its configured "security zones"), and partly the accumulated
configuration from user's responses to prompts (eg "yes, allow this site to
use my location, and don't ask again" or "yes, allow this site to use my
location, and since I trust this site, allow it to use any other API without
asking again" or "yes, I trust this widget, and also all other widgets from
the same author").

You can also imagine the "incognito" use case, in which, as a tempory global
setting, a user selects a configuration which says "don't reveal my location
to any site right now", which overrides the previously configured domains
and rules.

Therefore the BONDI policy model was intended to be capable of representing
not just the initial configuration, but also representing the persistent
configuration (user decisions, settings etc) for these kinds of use cases.
There might not be any initial policy configuration, but the policy
configuration is built up over time by encoding the outcomes of those user
decisions. A user agent can add a <policy> with a specific target which
reflects any of those specific user responses - and this will result in a
fine-grained configuration, rather than the coarse-grained and static set of
trust domains that we are accustomed to seeing ("operator", "manufacturer,
"trusted third party" etc). (Of course, determining the right user
experience for all of this is not easy, and it's not proposed that the user
is given a menu of multiple different things he can say when granting
permission, but nonetheless the model should be capable of capturing those
decisions under reasonable use cases.)

I'm not sure I understand in practice how many variants based on the
> attributes listed in Appendix B are really unique, in other words how many
> distinct trust domains are likely in BONDI? Is it possible to make a simple
> table/list?
>

Hopefully from the examples above you can see that there may not be a simple
table or list - at least not until we've got an agreed set of use cases.


> I think  it would be useful to explicitly include trust in the DAP policy
> requirements document [4], in particular the classes, attributes and logical
> trust domains. The reason is that the trust domain (implicit or explicit)
> drives subsequent decisions. Naming trust domains does not seem inconsistent
> with BONDI and offers value in reducing duplication of policy and making
> purpose clearer, but regardless it would be helpful to understand the list
> corresponding to expected use cases.
>
> What do you think?
>

I think the use cases should help us to think of names for "trust domains"
(equivalently <policy>s) that we would recognise as being meaningful in
practice.

Thanks - Paddy