Subject: Re: [Ace] Ace Digest, Vol 29, Issue 13

From: Vasu Kantubukta <[email-masked]>
Date: Wed, 20 Apr 2016 06:10:39 +0000

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

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 and burden on constrained client. 

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

Note that there is centralized control today in OAuth through the AS.

The RS would still have to get the results from the intermediate server in a secure way and verify that they are correct.

a.) In some use cases this does not work at all because the RS has no connectivity
b.) In most cases I expect that verifying the intermediate servers assertions and maintaining a secure connection to this intermediate 
server is going to be at least as burdensome for the RS as just verifying token itself.
---> That's true, it is very burdensome to interact with AS for a RS all the time.
---> In my opinion, RS may not have to verify the token each time the resource access done. 

Thanks and Best Regards
K Vasu

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 2016年4月19日 13:41
To: [email-masked]
Subject: Ace Digest, Vol 29, Issue 13

Send Ace mailing list submissions to
	[email-masked]

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
	[email-masked]

You can reach the person managing the list at
	[email-masked]

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

Subject: Re: [Ace] Ace Digest, Vol 29, Issue 12
From: Vasu Kantubukta <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "Caozhen (zcao)" <[email-masked]>, Ashutosh prakash <[email-masked]>, Javed siddiqui <[email-masked]>, "Zuojing (2012 Laboratories)" <[email-masked]>
Date: Tue, 19 Apr 2016 06:58:20 +0000

Hi Ludwig Seitz,

I have a quick look on your draft. We are happy even to discuss about our draft and can collaborate.

Plz find my few inline comments below:

Actually that draft is not so much about pre-configuring endpoints with
tokens, the idea behind OAuth is that you supply these tokens on demand,
i.e. when a client tries to access a resource on a server.

Btw: The reference is wrong, it's now draft-ietf-ace-oauth-authz

----> Thanks for bringing me to notice the new draft "draft-ietf-ace-oauth-authz-01"
----> Yes, these tokens are not configured at the endpoints, those are at AS, my doubt is about how AS can make dynamic configuration of security policies about RS, and clients. Does there be any frequent updates about policies from RS to AS.

I'm not sure what you mean with those points. Priority of requests and
QoS could be parameters that have a bearing on what kind of access token
you get, but they are certainly out of scope for ACE.
The operations that clients can perform on the resource are supposed to
either be encoded in the token, or available through introspection by
ways of the "scope" of an OAuth token.

---> Authorization server provides resource access to client by giving access tokens to client that includes only security context, and kind of protocol
access.
---> Suppose RS cannot handle any request at that time, and some other similar resource can handle the request. Does the RS will update to AS?. If not, then request should not be allowed. Here the check is not happened based on the resource management. Only protocol operations like (PUT,POST,GET etc) may not be sufficient to distinguish the resource access. Resource oriented operations are more appropriate for resource control (for ex. for resource IP Camera, the operations allowed are {"turn it up", "turn it down", "play", "pause"}). Centralized resource control is required to admit client request. On what basis these tokens assigned is very important in constrained environments. only based on security context is not sufficient to authorize the resource. Authorization should include both admission and resource control. There should be some decision making required to provide access controls on resource access not only just by the security context.
---> Admission control does not have to consider about resource management, but resource control should consider. And, any access control mechanism should include both admission and resource control. Permission to access a resource is an authorization. So, managing and monitoring of access controls of a resource is also a part of resource access.

Moreover, other few queries about draft-ietf-ace-oauth-authz-01:
--->resource server is involved in processing the access token which is supplied as payload from client request. Or in other case, it has to construct new introspection request to AS and verify the access token of client. Which burdens the resource heavily due to limited memory.
--->why can't this be delegated to some intermediate server that do access token verification on behalf of RS.
--->Does the RS has to do this verification of access request for each client and resource request?.

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 2016年4月19日 0:30
To: [email-masked]
Subject: Ace Digest, Vol 29, Issue 12

Send Ace mailing list submissions to
        [email-masked]

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
        [email-masked]

You can reach the person managing the list at
        [email-masked]

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

Subject: [Ace] FW: New Version Notification for draft-vasu-ace-core-access-privilege-provisioning-00.txt
From: Vasu Kantubukta <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Ashutosh prakash <[email-masked]>, Javed siddiqui <[email-masked]>, "Zuojing (2012 Laboratories)" <[email-masked]>
Date: Mon, 18 Apr 2016 09:56:23 +0000

Dear CORE and ACE,

We have submitted a draft on "access privilege provisioning for constrained devices" that provides a method to configure the policies for admission as well as resource control in constrained environment (including both constrained and non-constrained devices) which includes complete system architecture, methods for defining policies, and with commissioning procedures. Here, the service provisioning includes authentication, authorization, admission and resource control.

The draft details about the following:

1) Discover provisioning server, and verify registered service with CORE-RD using commissioning procedure.
2) Defining admission control policies for registered resources.
3) How resource control policies can be configured to allow only privileged users to access the resource?

We would like to discuss the CoRE, and ACE aspects of this draft in the CORE and ACE WG meeting.

Thanks and Best Regards
K Vasu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 2016年4月15日 21:40
To: Rahul Arvind Jadhav (Rahul Arvind Jadhav, 2012 Labs); Vasu Kantubukta; Vasu Kantubukta; Yangneng; Rahul Arvind Jadhav (Rahul Arvind Jadhav, 2012 Labs)
Subject: New Version Notification for draft-vasu-ace-core-access-privilege-provisioning-00.txt

A new version of I-D, draft-vasu-ace-core-access-privilege-provisioning-00.txt
has been successfully submitted by Kantubukta Vasu and posted to the IETF repository.

Name:           draft-vasu-ace-core-access-privilege-provisioning
Revision:       00
Title:          Access Privilege Provisioning for Constrained Devices
Document date:  2016-04-15
Group:          Individual Submission
Pages:          30
URL:            https://www.ietf.org/internet-drafts/draft-vasu-ace-core-access-privilege-provisioning-00.txt
Status:         https://datatracker.ietf.org/doc/draft-vasu-ace-core-access-privilege-provisioning/
Htmlized:       https://tools.ietf.org/html/draft-vasu-ace-core-access-privilege-provisioning-00

Abstract:
   As more constrained devices are integrating with current Internet,
   the ubiquitous computing in scenarios like smart home is very
   important. In smart home, the constrained devices (ex. thermostat)
   need to be provisioned in such a way that it can inter-operate with
   any kind of devices like other constrained devices (ex. Air
   conditioner) or client devices (ex. smart phone). This document
   provides a method to support access privilege provisioning based on
   pre-configured admission and resource control policies, where this
   method explains device's service access in two different use cases:
   first provisioning the service when a constrained device accessing
   the service provided by other constrained device, second, accessing
   the service provided by constrained device from the client device
   (non constrained device).

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

Subject: Re: [Ace] [core] FW: New Version Notification for draft-vasu-ace-core-access-privilege-provisioning-00.txt
From: Ludwig Seitz <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 18 Apr 2016 12:55:05 +0200

On 2016-04-18 11:56, Vasu Kantubukta wrote:
> Dear CORE and ACE,
>
> We have submitted a draft on "access privilege provisioning for
> constrained devices" ...
>

Hello Vasu,

thank you for your interest in the ACE work. I've had a quick look at 
your draft and noticed some issues that I'd like to clarify with your 
help. You write:

>
>    Admission control is addressed with the draft (draft-seitz-ace-oauth-
>    authz) provides a mechanism for pre-configuring secure/authorization
>    policies with token mechanism to access the resource.

Actually that draft is not so much about pre-configuring enpoints with 
tokens, the idea behind OAuth is that you supply these tokens on demand, 
i.e. when a client tries to access a resource on a server.

Btw: The reference is wrong, it's now draft-ietf-ace-oauth-authz

> It is not possible to manage the rest resources by using only tokens that
>    authorize the clients to access the resource. Because, it also needs
>    to handle resource control interms of various other parameters such
>    as priority of request, QoS, Operations that can be performed on
>    resource by various clients.

I'm not sure what you mean with those points. Priority of requests and 
QoS could be parameters that have a bearing on what kind of access token 
you get, but they are certainly out of scope for ACE.
The operations that clients can perform on the resource are supposed to 
either be encoded in the token, or available through introspection by 
ways of the "scope" of an OAuth token.

> The draft (draft-seitz-ace-oauth-authz)
>    talks about how to provide admission control (conditional
>    authorization) for resource access from client device, but it does
>    not consider constrained device access from another constrained
>    device.

That is simply not correct. If you look at section 6.1 of
draft-ietf-ace-oauth-authz-01, this deployment example deals with the 
case of a constrained client accessing a constrained resource server.

Maybe you have identified other requirements that are not currently 
covered by our draft, or that are unclear in the current document. If 
that is the case, please explain to the group what these requirements 
are, so that we can discuss them and try to find the best solution.

I'd also like to clarify what you mean with 'Admission Control' vs 
'Resource Control', the distinction does not seem very useful to me at 
this point, so perhaps I'm missing something.

Regards,

Ludwig Seitz

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

Phone +46(0)70-349 92 51
http://www.sics.se

Subject: Re: [Ace] Ace Digest, Vol 29, Issue 12
From: Ludwig Seitz <[email-masked]>
To: <[email-masked]>
Date: Tue, 19 Apr 2016 10:10:31 +0200

On 2016-04-19 08:58, Vasu Kantubukta wrote:
> Hi Ludwig Seitz,
>
> I have a quick look on your draft. We are happy even to discuss about
> our draft and can collaborate.
>
> Plz find my few inline comments below:
>
> Actually that draft is not so much about pre-configuring endpoints
> with tokens, the idea behind OAuth is that you supply these tokens on
> demand, i.e. when a client tries to access a resource on a server.
>
> Btw: The reference is wrong, it's now draft-ietf-ace-oauth-authz
>
> ----> Thanks for bringing me to notice the new draft
> "draft-ietf-ace-oauth-authz-01"

----> Yes, these tokens are not
> configured at the endpoints, those are at AS, my doubt is about how
> AS can make dynamic configuration of security policies about RS, and
> clients. Does there be any frequent updates about policies from RS to
> AS.
>

The RS is not supposed to manage policies at the AS. Managing access 
control policies at the AS is the job of the Resource Owner RO (i.e. the 
entity in charge of RS). Since the AS and RO are not considered to be 
constrained devices, normal web tools can be used for that. Furthermore 
since the AS is not constrained it is considered to be connected at all 
times, thus frequent access control policy updates are possible.
How AS are implemented in detail is not in scope for ACE, you might be 
able to get some feedback on that from people at the OAuth WG.

> I'm not sure what you mean with those points. Priority of requests
> and QoS could be parameters that have a bearing on what kind of
> access token you get, but they are certainly out of scope for ACE.
> The operations that clients can perform on the resource are supposed
> to either be encoded in the token, or available through introspection
> by ways of the "scope" of an OAuth token.
>
> ---> Authorization server provides resource access to client by
> giving access tokens to client that includes only security context,
> and kind of protocol access.

The token only includes very few parameters indeed, but the policies the 
AS uses to determine what token a client can get in a specific situation 
can be as complex as you like (e.g. depending on requested QoS or 
whatever else).

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.

---> Suppose RS cannot handle any
> request at that time, and some other similar resource can handle the
> request. Does the RS will update to AS?. If not, then request should
> not be allowed.

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.

> Here the check is not happened based on the resource
> management. Only protocol operations like (PUT,POST,GET etc) may not
> be sufficient to distinguish the resource access. Resource oriented
> operations are more appropriate for resource control (for ex. for
> resource IP Camera, the operations allowed are {"turn it up", "turn
> it down", "play", "pause"}).

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.

> Centralized resource control is required
> to admit client request. On what basis these tokens assigned is very
> important in constrained environments. only based on security context
> is not sufficient to authorize the resource. Authorization should
> include both admission and resource control. There should be some
> decision making required to provide access controls on resource
> access not only just by the security context.

Again it is hard for me to discuss your points unless I know what you 
mean with 'security context', 'admission control' and 'resource 
control'. Could you please clarify these terms?

Note that there is centralized control today in OAuth through the AS.

--> Admission control
> does not have to consider about resource management, but resource
> control should consider. And, any access control mechanism should
> include both admission and resource control. Permission to access a
> resource is an authorization. So, managing and monitoring of access
> controls of a resource is also a part of resource access.
>
> Moreover, other few queries about draft-ietf-ace-oauth-authz-01:
>
--->resource server is involved in processing the access token which
> is supplied as payload from client request. Or in other case, it has
> to construct new introspection request to AS and verify the access
> token of client. Which burdens the resource heavily due to limited
> memory.
--->why can't this be delegated to some intermediate server
> that do access token verification on behalf of RS.

The RS would still have to get the results from the intermediate server 
in a secure way and verify that they are correct.

a.) In some usecases this does not work at all because the RS has no 
connectivity
b.) In most cases I expect that verifying the intermediate servers 
assertions and maintaining a secure connection to this intermediate 
server is going to be at least as burdensome for the RS as just 
verifying token itself.

Note that the idea is that the AS makes an access control decision, 
which is a heavyweight process, it encodes this decision into an access 
token. The RS then only enforces the decision made by the AS, and for 
that it has to verify the token, which is supposed to be a lightweight 
process.

--->Does the RS
> has to do this verification of access request for each client and
> resource request?.
>
Access requests are verified by the AS, the RS only matches the resource 
request against the token to see if the token authorizes this resource 
request.

Regards,

Ludwig

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

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 20 Apr 2016 09:15:07 +0200

On 2016-04-20 08:10, Vasu Kantubukta wrote:
> 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.

> 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
--> 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
> 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.
>
> Again it is hard for me to discuses your points unless I know what you

---> 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 +46(0)70-349 92 51
http://www.sics.se