Re: Use Cases | ACTION-13 Revisited

On Tue, Sep 4, 2012 at 4:38 PM, Mark Watson <watsonm@netflix.com> wrote:
>
> On Sep 4, 2012, at 4:04 PM, Ryan Sleevi wrote:
>
>> - The existing use cases try to describe novel constructions of a
>> series of operations, whereas the Netflix proposal seems to broadly
>> focus on everything, but without quite describing what operations are
>> actually necessary to perform.
>
> MW> Is this concern addressed if we're more specific in the use-case about the operations needed ?

Consistent with the other use cases, describing the use case solely in
operations / classes of operations seems more useful to understanding
the purpose of the API, and provides enough context for readers to
understand the functionality without having to interpret or disconnect
the supplementary reasons that can be inferred or that have not
affected the design of the API.

Plus, it's shorter that way.

>> - The existing use cases try to describe generic services that can be
>> implemented whether you're 15 or a Fortune 500. The Netflix use case
>> does seem inherently tied to pre-provisioned keys (exclusively), and
>> thus is not something that anybody can necessary implement, since they
>> have to work with device manufacturers-et-al to actually discover
>> these pre-provisioned relationships.
>
> MW> This is true today, but there is no technical reason why devices couldn't mint new origin-specific pre-provisioned keys on demand.

This is also true, but in order to have any use for "device
authentication", the origin would have to know the provenance of the
key is a device. Whether this means knowing the key derivation/minting
algorithm or knowing the master key is supplementary.

This is fundamentally a *different* use case than using device storage
for keys (such as TPMs or other secure elements). This is about the
manufacturer of a device (or some other party in the supply chain)
directly provisioning keys out of band, and having service providers
recognize the provenance of such keys. This "know the provenance" is
the part that I think rules it out from being generally useful, since
it requires specific out of band information that, for privacy
reasons, may not be (and arguably should not be) generally available.

>
>>
>> Broadly speaking, I think the API use cases should focus on use cases
>> that can operate regardless of the provenance of the key - that is,
>> whether it be pre-provisioned or generated.
>
> MW> Why ? This seems an arbitrary place to draw the line on what is included.

For the same reasons we don't focus on Crypto Providers: The key
provenance is left to implementation specific details. Trying to
specify a use case that hinges on provenance, a point specifically not
addressed, seems counter-intuitive, because it directly highlights an
piece of functionality that is both optional and implementation
dependent. It's not addressed by the API.

>
>> Obviously pre-provisioned
>> can be used to bootstrap some trust, but the more focus on
>> pre-provisioned we as a WG place, the further away from having any
>> compelling story to be said to the broader Internet community about
>> the interoperability of these APIs.
>
> MW> I don't understand why that would be the case. Inclusion of material on pre-provisioned keys does not take away from any of the other features. We're not suggesting this should be a "special focus" of the group, just that it is one feature which should be included.
>
>>
>> In looking at the existing use cases, I'm trying to figure out what
>> operations that are present in the Netflix case that are not already
>> captured. The use of pre-provisioned keys is mentioned in the
>> Multi-Factor Auth use case, and then again in the Document Signing use
>> case. The key derivation scheme has been previously acknowledged as
>> something more Netflix specific, so I'm not sure if it needs a special
>> use case. Are there other operations you desire?
>>
>
> MW> The use of pre-provisioned symmetric keys to perform device authentication.
>
> …Mark

So "Multi-factor Authentication", with wording tweaks, essentially. A
use case that's already arguably too long and too specific.

What about the proposed text then, in attempt to reduce the Netflix
case to the "bare essentials" while also attempting to address the
specific needs that Netflix feels have not already been captured in
the existing use cases, which also make efforts to highlight the
possibility of pre-provisioned keys.

I'd like to note that the inclusion of a Netflix specific use case
does not feel appropriate here in this spec, and would object to
publishing a FPWD with such a use case.

I've attempted to try and find some happy medium, but I remain
unconvinced that such a specific use case belongs in the API, because
it is inherently non-portable and implementation-specific.

"Out-of-Band Key Provisioning

Web applications may wish to use keys that have been provisioned
through means other than this API. This may include keys provisioning
or storage through platform-specific native APIs, the use of keys
storage in secure elements such as smart cards or trusted platform
modules (TPMs), or keys that are individually bound to devices at time
of manufacturing. While not required to be supported by this API, and
though it introduces a number of security and privacy concerns, user
agents may choose to expose such keys to web applications, potentially
after gaining user consent or other out-of-band authorization.

Web applications may utilize knowledge obtained out-of-band regarding
the how the key was provisioned or was stored to make local policy
decisions. For example, a web application may wish to restrict access
to users that can prove access to a key that was provided out-of-band
to the user by the application provider, such as via a smart card.
Alternatively, an application may wish to be restricted to a certain
class of devices, and may use a cryptographic challenge to establish
the user agent's access to a particular device-specific key.

The web application must be able to determine if the user agent
supports such externally-provisioned keys, locate any appropriate
keys, and perform authorized cryptographic operations such as signing
or encrypting on the keys, as if it had directly generated or imported
the key."

The above tries to:
- Highlight that pre-provisioned keys may exist
- Highlight that it's implementation dependent
- Highlight that it opens up new security and privacy concerns
- Highlight that it can be used to support "enhanced" authentication
such as smart cards OR device authentication
- Highlight that the operations may include both symmetric and
asymmetric operations.

Would the above meet your needs?

Received on Wednesday, 5 September 2012 23:18:08 UTC