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

[Vasu Kantubukta <[e-mail]>]

Hi Hannes Tschofenig,

Thanks for reviewing our draft and giving us feedback. 
Plz find the below inline response:

The term itself is defined in the terminology section:

      o "Commissioner" Commissioning agent is tool/device that verifies
      the devices operation, integrity check with the network.

Could you explain a little bit what you mean by "verifies the device operation", and "integrity check with the network"?
---> Sorry for the wording, maybe it is not conveying the actual meaning. 
---> I mean it verifies whether the device can be operational in the network or not, and can join to the network or not.

Thanks and Best Regards
K Vasu


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

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

Hello,

I'm still trying to clarify the details of the approach you propose,
so please excuse the barrage of questions.

In figure 2 it looks like the RS has to do an online lookup at the AS to
get an access control decision while in figure 3 it seems as if the AS
itself executes the request on behalf of the client.

Both cases work fine if the RS can connect to the AS at the time of the
request, but if you look at RFC 7744 we have usecases where this is not
possible or not cost effective (e.g. in terms of battery usage). Have 
you considered such usecases?

 From our discussion I got the impression that in your approach, both
access control and resource control policies are provisioned to the AS
only and not to the RS, but in figure 3 is seems like the RS makes some
access control decision towards the AS, I wonder based on which policies
that happens?

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

Right

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

As I said, the AS can very well consider resource control or scheduling 
when making an access control decision, but the details of how the AS 
makes access control decisions are not in scope for ACE.

I also get the feeling that you got hang up on my simplistic example of 
a client sending a request to multiple resource servers. I guess a more 
realistic example would be that there are proxies taking care of 
scheduling, independently of the access control mechanism in place. 
Alternatively you could imagine a setting where the client broadcasts or 
multicasts its request.

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

I don't think there is an IETF working group on that topic.




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

Please note this ^^^^^^



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

--- Begin Message ---

Hi Vasu,

thanks for your draft. I have browsed through it and I had a number of
questions and I wanted to start with one aspect that seems to be quite
central to your document.

In the introduction you talk about RD and the past work in the IETF CORE
working group.

Then, you introduce a Commissioner:

   Once the services are advertised by any device, those services need
   to be verified using commissioner. CORE RD provides a standard
   procedure to interact with commissioner, where commissioner acts like
   a client device to look up and verify the advertised services. Once
   the commissioner verifies the pre-registered services, commissioner
   can put some policy rules on services hosted by devices for resource
   control.

The term itself is defined in the terminology section:

      o "Commissioner" Commissioning agent is tool/device that verifies
      the devices operation, integrity check with the network.

Could you explain a little bit what you mean by "verifies the device
operation", and "integrity check with the network"?

Ciao
Hannes

PS: You may have missed a few working group meetings and therefore you
may not know that we have already made a decision regarding the solution
direction regarding the use of OAuth for IoT.

--- End Message ---