Re: Use case classification, and associated security models

On Jun 13, 2012, at 6:13 PM, Ryan Sleevi wrote:


On Wed, Jun 13, 2012 at 6:00 PM, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com<mailto:Vijay.Bharadwaj@microsoft.com>> wrote:

>  When it first runs, the script does not know the UUID of any pre-provisioned keys - it must query based on the origin-specified naming scheme.

Is this necessarily true?

Crazy idea – what if the origin-specified naming scheme is based on UUIDs? Specifically, if each pre-provisioned key had a UUID that was a function of the user’s identity? (e.g. an HMAC of the user name with some key held by the service, or just a random UUID associated with the user in a server-side table) The service could query for the key by UUID because for any user it would know the expected UUID of the key. But the UUID is effectively random to anyone else who doesn’t know the HMAC key, so there is no feasible way anyone else can probe for it.

Would requiring keys to be named with UUIDs in this way make our API simpler?

In this formulation, what is the advantage of a UUID over an opaque string supplied by the application (which may be a UUID, or may be a string such as the simple English string "NetflixAuthKey")

It's not a question of comparing advantages: we need both kinds of identifier. An identifier for the general 'class' of key (e.g. "NetflixAuthKey") and something which identifies the specific key. If there are thousands of devices deployed, each with a different pre-provisioned "NetflixAuthKey" I need to know which one I am talking to to decrypt/verify the message


My thought is that whatever naming scheme we go with, it should be:

  *   Entirely up to the implementing application/web site how it wants to refer to keys. That is, it can dictate the key name itself.
  *   Entirely scoped/bound to the current security origin. That is "NetflixAuthKey" at netflix.com<http://netflix.com/> may represent a completely different key than "NetflixAuthKey" at netflixcdn.com<http://netflixcdn.com/>.

This is fine for identifying the key amongst other keys present within that device. The UUID is also needed to identify the key amongst all the other NetflixAuthKeys across different devices.

…Mark


This then opens two new desired behaviours:

  *   Users may wish to re-use the same key under the same name or different name between origins (eg: the scenarios #1 and #2 I gave for Alice and Bob)
  *   Site operators may wish to share the same key under the same name between different origins (eg: the netflix.com<http://netflix.com/> and netflixcdn.com<http://netflixcdn.com/>, both entities presumed operated by Netflix, that both wish to perform some keying operation)

>From the perspective of the application consuming the API (eg: doing operations with the keys), a key handle is a key handle. The above scenarios only come up with key discovery. However, whether the key's provenance is via Scenario #1, #2, or #3, and whether it's a shared key, unique-per-origin, or pre-provisioned, is something largely transparent at the API layer outside of discovery.


From: Mark Watson [mailto:watsonm@netflix.com<mailto:watsonm@netflix.com>]
Sent: Wednesday, June 13, 2012 8:59 AM
To: Ryan Sleevi
Cc: Mitch Zollinger; <public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>>

Subject: Re: Use case classification, and associated security models



On Jun 12, 2012, at 3:58 PM, Ryan Sleevi wrote:


If we adopt some form of UUID notation (which I still need to mull over the privacy risks), one might further expand to

var kql = window.crypto.queryKey(
  {
    'id': [ 'UUID_1', 'UUID_2' ],
  })

or with an origin-specified naming scheme:

var kql = window.crypto.queryKey(
  {
    'name': 'NetFlixAuthenticationKey',
  });

It's not really "either-or", you need both. When it first runs, the script does not know the UUID of any pre-provisioned keys - it must query based on the origin-specified naming scheme. If it finds a pre-provisioned key, then it must be able to obtain the UUID of that key. I am not sure there is a need to be able to retrieve keys by UUID.

Regarding privacy, as a starting point I would say all keys, including pre-provisioned ones, should be origin-bound. So the UUID is visible only to one origin.

It's possible that an implementation might use a single pre-provisioned master key to generate pre-provisioned keying material for multiple origins, but in this case it must use some one-way origin-specific function to generate the key and UUID for each origin.

Extending this to pre-provisioned keys visible to multiple origins indeed requires some more difficult privacy issues to be addressed. That's not something that is necessary for our use-case, though others may have this requirement.

…Mark