Issue on Authorized Read in VISSv2-Transport

[wonsuk73]

There are read, update, subscribe and unsubscribe operations in Current VISSv2-Transport spec. In addition these operations are seperated with authorized and unauthorized as below.

HTTPS:
5.1.2.1 Read
5.1.2.1.1 Authorized Read
5.1.2.1.2 Search Read
5.1.2.1.3 History Read
5.1.2.1.4 Service Discovery Read
5.1.2.2 Update
5.1.2.2.1 Authorized Update

Websocket:
5.2.2.1 Read
5.2.2.1.1 Authorized Read
5.2.2.1.2 Search Read
5.2.2.1.3 History Read
5.2.2.1.4 Service Discovery Read
5.2.2.2 Update
5.2.2.2.1 Authorized Update
5.2.2.3 Subscribe
5.2.2.3.1 Authorized Subscribe
5.2.2.3.2 Curve Logging Subscribe
5.2.2.4 Unsubscribe

Could we allow a client to access vehicle data without authentication? I guess the car manufacturing company might not want to provide their car data without their control. There might be a few level of authentication to control the data access according to security or privacy level. Am I right?
If it is right, I would suggest to add the phase for explanation of this context, and to change all of unauthenticated operations with authenticated operations. What's your opinions?

[wonsuk73]

@UlfBj, @peterMelco and @tguild Could you review and share your view?

[SebastianSchildt]

My (not necessarily correct) understanding at least for WS was, that "Authorized Read" is the special case, where you can put the whole token into each read request, which might be a good pattern if you want a single value ever hour/day or so, while otherwise it has tremendous overhead as a JWT token likely is several times the size of the query and the response combined.

I assumed normal reads are only possible after a session using a token has been established. (of course depending on the implementation maybe it opts to allow certain reads without any prior authentication).

[UlfBj]

Could we allow a client to access vehicle data without authentication?

We do allow that as the access control is optional. On top of that, even if an OEM supports access control, ch. 8.8 "Access control selection" makes it possible to apply access control to only selected nodes of the tree. So some nodes may then not require a token for access.

If access control is enabled on a signal, then according to the spec the token MUST be provided in each request to it.
I do not think we should change that and allow some requests to this signal to be without the token.

[SebastianSchildt]

It seems, in light of Ulfs answer, my "understanding" was wrong.

I would still like to make the observation, that the token MUST be provided in each request to it is a bad design decision as it as soon as an app queries more than 1 value in its lifetime wastes more than 50% of bandwidth on redundant authentication (not to mention that likely JWT token checking can easily be the computationally most expensive part in an implementation, as you need to verify the signature)

[UlfBj]

Yes, the security comes with a cost.
To come around that cost by relying on the notion of client sessions, seems not robust enough in my view.
If a robust solution can be presented, it would be discussed in the WG.

Using subscription, a client can receive multiple signals as a result of one request.

[SebastianSchildt]

I first would like to understand, what is the argument behind the view that sessions are not robust enough? That is virtually done by "everyone", starting on lower layers like TLS up to (maybe more akin to VISS) logins to online shops, your bank, your cloud provider?

[UlfBj]

All the transport protocols supported in VISS must run over TLS, as I am sure you know.
How long is a TLS session when it comes to HTTP? Does it extend over multiple HTTP requests?
Even if it does, is it good security practise to let the token based access control to "rely" on TLS?
I am asking because I am not sure about this.

[SebastianSchildt]

That was a misunderstanding: You are correct, TLS is only transport layer, as such it does not survive multiple HTTP requests (except HTTP pipelining features, to be more precise: It does not survive multiple TCP connections). I merely use it as an example of protocol, that for its purposes also establishes a "session" that remains valid as long as the connection is there.

On the layer (i.e. VISS) above you need session handling as well (as those "relations" can span multiple TLS establishments). For HTTPS (classic web stuff), this is done using session identifiers, potentially stored in cookies (so basically a much shorter random string, compared to a JWT token). For web/REST those time out, either after minutes or months, depending on the application.

For websocket it is even easier, as there you have the underlying TCP connection as long as websocket is "connected" (basically websocket emulates TCP semantics on a higher layer) . As such a "session" is implicitly established by opening a connection and teared down when the connection closes/breaks. So a server only needs to "remember" whether a client on a specific connection authenticated and how it is authorised without the need of a client to send any session identifier.

The only use case I came across where security credentials need to be self-contained in each "message" is in DTN (Delay-Tolerant Networking: Data-ferrying,Store-Carry-and forward, IPN ...), where your packet runtime is hours/days/months and no roundtrips/virtual connections are practically possible. But I think those are not VISS domains.

[UlfBj]

Yes, for HTTP session handling is not as straight forward as for WS. And I think the handling shall be uniform for the different transport protocols. But your mentioning of cookies could be a solution. E. g. the server could return a random nonce (the cookie) together with the signal value(s), and this could then be used instead of the token. Maybe we should bring this up for discussion in the WG?

[wonsuk73]

I think basically it's okay to me because the access control is optional for all of operations. But current structure of the spec described as below. It might make misunderstanding to readers. It looks only Read operation has authorized action even if other operations like Search read, History read and Service Discovery read also can be operated on the authorized channel.

HTTPS:
5.1.2.1 Read
5.1.2.1.1 Authorized Read
5.1.2.1.2 Search Read
5.1.2.1.3 History Read
5.1.2.1.4 Service Discovery Read
5.1.2.2 Update
5.1.2.2.1 Authorized Update

Websocket:
5.2.2.1 Read
5.2.2.1.1 Authorized Read
5.2.2.1.2 Search Read
5.2.2.1.3 History Read
5.2.2.1.4 Service Discovery Read
5.2.2.2 Update
5.2.2.2.1 Authorized Update
5.2.2.3 Subscribe
5.2.2.3.1 Authorized Subscribe
5.2.2.3.2 Curve Logging Subscribe
5.2.2.4 Unsubscribe

If my comment is reasonable, how about revising this as below and adding the normal and authorized examples to each sub-section respectively?

HTTPS:
5.1.2.1 Read
5.1.2.1.1 Basic Read
5.1.2.1.2 Search Read
5.1.2.1.3 History Read
5.1.2.1.4 Service Discovery Read
5.1.2.2 Update
5.1.2.2.1 Basic Update

Websocket:
5.2.2.1 Read
5.2.2.1.1 Basic Read
5.2.2.1.2 Search Read
5.2.2.1.3 History Read
5.2.2.1.4 Service Discovery Read
5.2.2.2 Update
5.2.2.2.1 Basic Update
5.2.2.3 Subscribe
5.2.2.3.1 Basic Subscribe
5.2.2.3.2 Curve Logging Subscribe
5.2.2.4 Unsubscribe

[wonsuk73]

For long-lived HTTPS session using cookie I think we need to put this on the table for discussion in the group. Because I think the subscribe operation is a function typically used in the field.

[UlfBj]

If my comment is reasonable, how about revising this as below and adding the normal and authorized examples to each sub-section respectively?

@wonsuk73 I think your point is relevant, that it is not sufficiently clear how to use authorization in conjunction with the different request types.
However, I think your proposed solution will be a bit "overkill". I believe a reader of this spec is able to generalise from the given example how to use it for different request types. But it should be made clear in the text of the existing example that authorization is supported in all request types. So adding this explanation I believe should be sufficient to solve the problem.

[tguild]

I encourage @SebastianSchildt and @isaacagudo to look at call minutes for this topic. The group is supportive of convenience if not compromising security and then wonder what the mechanism should be to convey a shorter nonce (probably the 40 byte SHA256 signature for the token), is there something in Oauth2 we can use since we transmit the token via Authorization:Bearer?

[UlfBj]

To make the proposal to use only the signature part of the token in subsequent requests robust, the server must, after the first successful validation of the token, save the following data:
- The token signature,
- The token expiry time,
- The signals that are claimed in the token, together with the access mode for each.

The header currently defined to carry the token can also be used in the case only the signature part is sent as the server is able to identify whether the data represents a complete token, or only the signature part. A complete token must contain dots delimiting the different parts, while the data for the signature only does not contain any dots.

A new error response is needed to inform a client that the server cannot grant authorisation without receiving a complete token.
Error response: 401/token_incomplete/A complete token must be used.

If we go with this proposal, I think we should use the full signature part of the token, in order to not reduce the security level that this signature provides. Its size is 43 bytes (32*1,33), while a complete VISSv2 JWT seems to be around 250-300 bytes (600-700% reduction).

This can be an optional feature, with the error response above being mandatory.

[SebastianSchildt]

If I fully got the proposal, I feel it needlessly weakens security: Normally for "session identifiers" it is quite elementary they are random and cannot be easily guessed.

Of course the argument can be made, that stealing the token "signature" is as hard as stealing the complete token, but I still feel VISS should follow common security practices, and not use a fixed element, where it can/should be random.

https://xkcd.com/221/

Also, a "fixed" short form for a token is required to identify "sessions" in a more efficient way, if the server wants to do discern two nodes using the same token, it would need to include IP address (whereas still different nodes might connect from a single IP), and when moving to multipath capable protocols, it might get even harder. (A usecase where you want to discern individual connections might be rate limiting, if a client oversteps its bounds: Without an unambiguously identifiable endpoint, your only chance might be blocking the external IP of a proxy serving a xx k people company)

So in summary I feel the "short hand" for a token used by a specific client to identify a session should follow common practice and be a random "thing" selected by the server (i.e. an uuid would probably fit to the json VISS)