Re: Possible Security and Privacy Next Steps

Hi

As to yesterday's discussion, I think we should put effort for releasing Vehicle APIs on schedule as the principal purpose. For this purpose,

* We may have to omit 'set-api' from V1
* V1 spec should rely on OS security framework instead of on-going web solutions because we cannot control these schedule.
* Security & privacy consideration doesn't have to be in spec but should be anywhere, e.g., as a BG/WG note. This will be required in the review process.

Regards,
Junichi

Paul J. Boyes
--------------------------------
Mobile:   206-276-9675
Skype:  pauljboyes




On Oct 27, 2015, at 12:33 PM, Gavigan, Kevin <kgavigan@jaguarlandrover.com<mailto:kgavigan@jaguarlandrover.com>> wrote:

Hi Ted,

That's great, thanks,

>> we should review the various use cases and attack vectors.

Completely agree and believe we should use these to develop a Threat Model  (focussing on the API and its use), as the type of attacks and their mitigations will inform what secure implementations of the spec would need to address.

It wont be perfect, and in fact implementors will need to continually review, revise and add to it as new threats and types of attack are identified, but it will help us think about what the security model will need to achieve in a more organised way.

>> If Set/Get/Subscribe/Unsubscribe fails because of a security problem what are the detailed error codes.

Believe we need a high level view of how we are assuming security might be implemented. For example, if there are authentication or authorisation errors, will these be handled using HTTP 401 and 403 errors?

Then if this is the case, more specifically, believe we should define common error codes that are returned to help ensure that this behaviour is consistent across different implementations.

For example, believe we would need to define the following error codes for a HTTP 401

user token invalid
vehicle token invalid
device token invalid (where device is e.g. a component or group of components e.g. in a vehicle)

So would return a 401 if request should be retried after user/vehicle/device has renewed its access token.

For cases where the information in the request will never succeed (unless something else changes e.g. invalid VIN is passed, user does not have a subscription and needs to pay for one before authorised request can succeed)

HTTP 403 Forbidden

user details invalid
vehicle details invalid
device details invalid

etc (need to add other cases)

Regards,

Kev

Kevin Gavigan BSc, MSC, PhD, MCP, MCTS
Software Architect
Connected Infotainment
Electrical, Electronic and Software Engineering (EESE)
Jaguar Land Rover

Mobile: 07990 084866
Email: kgavigan@jaguarlandrover.com<mailto:kgavigan@jaguarlandrover.com>

Office address:
GO03/057 • Building 523, Gaydon • Maildrop: (G03)
Jaguar Land Rover • Banbury Road • Gaydon • Warwick • CV35 0RR

On 27 October 2015 at 11:50, Ted Guild <ted@w3.org<mailto:ted@w3.org>> wrote:
I propose in addition to repeated iteration through the three steps
(list use cases, review in detail identifying attacks vectors, derive
requirements) as Junichi recommended we need to consider additional next
steps.  Here are few that occur to me and for all we should survey other
groups at W3C who may have approached similar problems so that we can
leverage or learn from.

Access Control Mechanism

There will be inter-process security restrictions imposed by the
operating system.  There is also a need to be able to do similar in the
web runtime.  For both it is beneficial to have granular access control
on our data spec.  This may be a separate document.  We discussed
perhaps a tiered approach and it should allow for implementers to define
their preferred different privileged tiers and attributes at that
tier.

Best Practices for Web Runtime in IVI

Since the web runtime will have external interactions we should review
the various use cases and attack vectors.  This is not directly related
to our specifications but the environment app written against these
specs will be operating in so most likely a Best Practices document.
Mitigating these concerns are more likely going to be from enforcement
systems in the operating system although some elements may be in the web
runtime itself.  A sample possible mitigation technique could be for the
OS to require all external web site/service interactions to go through a
proxy server that manages certificates of sanctioned sites and does data
sampling for integrity checks.

Entity preferences profile

For individual users, owners and applications to be able to define
personal, payment, vehicle and other information.

--
Ted Guild <ted@w3.org<mailto:ted@w3.org>>
W3C Systems Team
http://www.w3.org<http://www.w3.org/>