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

[Vasu Kantubukta <[e-mail]>]

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:[e-mail]] On Behalf Of [e-mail]
Sent: 2016年4月19日 0:30
To: [e-mail]
Subject: Ace Digest, Vol 29, Issue 12

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

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: [e-mail] [mailto:[e-mail]]
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

--- End Message ---

--- Begin Message ---

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 [phone]
http://www.sics.se

--- End Message ---