Re: [Ace] Ace Digest, Vol 29, Issue 16

[Vasu Kantubukta <[e-mail]>]

Hi Ludwig Seitz,

Plz find my inline comments:

Access control already provides limited access on it's own, so I would need a bit more concrete convincing on why mixing it up with resource
control would increase security.

Usually when you mix up solutions for different problems, the increased complexity goes a long way to reduce security. You are simply
creating more ways of getting it wrong.

---> Because you can add more access privileges based on resource control policies.
Based on operational instructions (i.e. who can access what resource, on what level of service to users), only allow users if meet such criteria.
Moreover, provisioning the resources during commissioning time will also increase the security.
(section 6.4 of "draft-vasu-ace-core-access-privilege-provisioning-00" explains this)

I am not sure I understand what you are trying to say here. Who
provisions resource control policies to whom? And how is this related to
the access token?

Is the provisioning server something like the Authorization Server (AS) 
in our design?

Do you expect a RS to be connected to a PS at all times? (Note that we 
have use cases where that is not possible or not cost-effective)

Alternatively, do you expect to be able to provision both access control 
policies and resource control policies to an RS at commissioning time 
and then enforce them offline at the RS when a client requests access?

--> Yes, Provisioning server is something like the Authorization Server. Can do both "admission and resource control"
--> No need to connect to PS all times. 
--> Commission agent verifies the registered services to RD. And then commissioning agent defines
the access control and resource control policies for RS at provisioning server. Then, whenever client requests for a service, it needs to be provisioned by provisioning server before getting access of resource. 
(section 4, and 7 of "draft-vasu-ace-core-access-privilege-provisioning-00" explains this)

So if OAuth does not deal with resource control, why should the ACE 
solution (which is based on OAuth) do so?
--> No comment on this.

Why would the scheduling problem be caused by the access control 
mechanism? That causality doesn't seem obvious to me, please explain in 
more detail.
--> Here, If I am not wrong, you mentioned that same access tokens can be valid for multiple resources. 
If access control does not consider resource availability and resources max capacity to handle the request. Then clients need to send the resource request to multiple resource servers. Then it may need a scheduling by a proxy.

Here in ACE we are not trying to standardize how an Authorization Server 
(or provisioning server) decides which client is issued which kind of 
access token (i.e. the access control decision process).
--> No comment on this.

It seems to me that your goal is to include resource control aspects 
into that decision, and that is fine by me, but not relevant for the ACE 
work, which deals with encoding the access control decision into a 
token, getting the token to the Resource Server and then having the RS 
enforce that access control decision.
--> Can you suggest me, which group I can reach for?


Thanks and Best Regards
K Vasu



-----Original Message-----
From: Ace [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: 2016年4月21日 16:56
To: [e-mail]
Subject: Ace Digest, Vol 29, Issue 16

Send Ace mailing list submissions to
	[e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/ace
or, via email, send a message with subject or body 'help' to
	[e-mail]

You can reach the person managing the list at
	[e-mail]

When replying, please edit your Subject line so it is more specific than "Re: Contents of Ace digest..."

--- Begin Message ---

Hi Ludwig Seitz,

Plz find my inline comments:

-->Admission control, and resource control together will provide increased security of resource access by providing limited access with various other
provisioning parameters.

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.
--->yes, that's why it needs to be provisioned by resource control policies offline at the provisioning server and provide access tokens to clients.

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.
---> yes, oAuth does not deal the resource control. Resource control also needs a privilege mechanism to provision the request along with admission control.

Because, authorization should happen before resource control. Moreover, it provides a provides a consistent application performance along with authorization as like in telecom/IP networks.


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.
---> of course, it is a scheduling problem. But scheduling problem because of an access control mechanism. proxy can be a provisioning server here.

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

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.
-->yes, that's why commissioning agents will make the policy rules about the registered services to provisioning server, which can ultimately influence the access tokens/grants issued to the client devices.


Thanks and Best Regards
K Vasu




-----Original Message-----
From: Ace [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: 2016年4月21日 0:30
To: [e-mail]
Subject: Ace Digest, Vol 29, Issue 15

Send Ace mailing list submissions to
        [e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/ace
or, via email, send a message with subject or body 'help' to
        [e-mail]

You can reach the person managing the list at
        [e-mail]

When replying, please edit your Subject line so it is more specific than "Re: Contents of Ace digest..."

--- Begin Message ---

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

--- End Message ---

--- End Message ---

--- Begin Message ---

On 2016-04-21 07:35, Vasu Kantubukta wrote:
> Hi Ludwig Seitz,
>
> Plz find my inline comments:
>
> -->Admission control, and resource control together will provide
> increased security of resource access by providing limited access
> with various other provisioning parameters.
>
Access control already provides limited access on it's own, so I would
need a bit more concrete convincing on why mixing it up with resource
control would increase security.

Usually when you mix up solutions for different problems, the
increased complexity goes a long way to reduce security. You are simply
creating more ways of getting it wrong.

> 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.

> --->yes, that's why it needs to be provisioned by resource control
> policies offline at the provisioning server and provide access
> tokens to clients.
>

I am not sure I understand what you are trying to say here. Who
provisions resource control policies to whom? And how is this related to
the access token?

Is the provisioning server something like the Authorization Server (AS) 
in our design?

Do you expect a RS to be connected to a PS at all times? (Note that we 
have use cases where that is not possible or not cost-effective)

Alternatively, do you expect to be able to provision both access control 
policies and resource control policies to an RS at commissioning time 
and then enforce them offline at the RS when a client requests access?

> 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.
>
> ---> yes, oAuth does not deal the resource control. Resource control
>  also needs a  privilege mechanism to provision the request along
> with admission control.
>

So if OAuth does not deal with resource control, why should the ACE 
solution (which is based on OAuth) do so?

[...]
> 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.
>
> ---> of course, it is a scheduling problem. But scheduling problem
> because of an access control mechanism. proxy can be a provisioning
> server here.

Why would the scheduling problem be caused by the access control 
mechanism? That causality doesn't seem obvious to me, please explain in 
more detail.

...
> 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.
>
 >
  >-->yes, that's why commissioning agents will make the policy rules
> about the registered services to provisioning server, which can
> ultimately influence the access tokens/grants issued to the client
> devices.

Here in ACE we are not trying to standardize how an Authorization Server 
(or provisioning server) decides which client is issued which kind of 
access token (i.e. the access control decision process).

It seems to me that your goal is to include resource control aspects 
into that decision, and that is fine by me, but not relevant for the ACE 
work, which deals with encoding the access control decision into a 
token, getting the token to the Resource Server and then having the RS 
enforce that access control decision.


Regards,

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

--- End Message ---