Re: [Ace] discussion on draft-vasu-ace-core-access-privilege-provisioning-00

[Ludwig Seitz <[e-mail]>]

On 2016-04-20 08:10, Vasu Kantubukta wrote:
> Hi Ludwig Seitz,
>
> Plz find the below comment inline :
>
> Btw: I really don't know what exactly you mean with 'security
> context' and 'protocol access', in order to avoid misunderstandings
> it would be good to get to a common understanding on the terms we
> use.
>
> ----> A Security Context is an object that captures all
> security-related information, consider below access token example
> specified in the draft that considers only the security related
> information (i.e. security context) { "aud" :
> "tempSensorInLivingRoom", "iat" : "1360189224", "cnf" : { "jwk" : {
> "kid" : b64'1Bg8vub9tLe1gHMzV76e8', "kty" : "EC", "crv" : "P-256",
> "x" : b64'f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU', "y" :
> b64'x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0' } } }
>
> ----> protocol access such as DTLS Response-Payload : {
> "access_token" : b64'SlAV32hkKG ...', "token_type" : "pop", "csp" :
> "DTLS", "key" : b64'eyJhbGciOiJSU0ExXzUi ...' }

Ok good! We have a common understanding of security context.
If I understand you correctly you are suggesting that the token should 
carry more information than just security context, right?

Note that the security context alone already makes the tokens quite 
large, and thus not ideal for constrained networks, so one should be 
very careful about adding even more data to this format.

I would suggest the following approach: Have a look at what is done in 
the "Web" world with OAuth. If it's not done there, there is probably a 
good reason for it. To my knowledge OAuth does not deal with resource 
availability, service level agreements, QoS, and resource manageability.
I would venture the guess that this is simply because things would get 
very messy if you mixed up access control with such resource control issues.

> You are aware that in some usecases the RS is not even be able to
> communicate with AS?
>
> Note however that an access token might be valid for more than just
> one specific RS, so in the case you describe above, where several RS
> could satisfy the client's request, the AS could issue such a token
> to the client, and the client could contact all the matching RS using
> the same token until it finds one that can satisfy its request.

>--> suppose if client is a constrained device, then also it has to send
> request to all RS's ?
--> It may be a overhead in network aend burden
 > on constrained client.

That's a scheduling problem and not an access control problem and thus 
out of scope for ACE. This could for example be handled by a proxy that 
dispatches the client's request to the right RS.

> Such resource oriented operations can be encoded in an access token
> as well using a different set of OAuth scopes. The ACL defined in
> draft-bormann-core-ace-aif is just one example specific to protocol
> operations. This will probably pan out for IoT the same way it has
> for Web OAuth: There will be many different application specific uses
> scope, that define resource oriented permissions similar to those you
> listed above. See https://www.brandur.org/oauth-scope for an overview
> of how people have used scopes differently to implement
> application/resource specific permissions.
>
> ---> yes, scope parameters can be used to encode the resource
> specific permissions and operations.
>
>
> Again it is hard for me to discuses your points unless I know what you
> mean with 'security context', 'admission control' and 'resource
> control'. Could you please clarify these terms?

---> Admission control: admission control is realized by accepting or
> refusing the request for the resources. It has the defined policies to
 > admit/deny the request. These policies might be made upon security info.

That would be 'Access Control' in the terms I've been using, this is in 
scope for ACE.

---> Resource control: resource control defines extra policies based on
> resource availability, service level agreements and QoS, and resource
> manageability. (you can refer section 6.4 of
> draft-vasu-ace-core-access-privilege-provisioning-00)
>

This is not in scope for ACE. Furthermore I don't think individual 
constrained devices should handle this kind of things, they are simply 
not well-equipped to do so. This should be handled by back-end devices 
and enforced by gateways or proxies. Perhaps this could influence the 
policies governing what access tokens the AS issues.


[...]
---> In my
> opinion, RS may not have to verify the token each time the resource
> access done.
>

Depends on what you mean with "verify". The signature of a JWT/CWT has 
to be verified once only, as well as the audience (i.e. which RS the 
token applies to), but expiration, and scope have to be checked for each 
resource access. If you don't have a secure session, you also need to 
check the binding between client and token (see Proof-of-Possession in 
OAuth) for every access.

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone [phone]
http://www.sics.se