Subject: [Ace] [ACE] Permanant client-server relations and draft-seitz-ace-oauth-authz-00

From: Somaraju Abhinav <[email-masked]>
Date: Tue, 17 Nov 2015 13:42:31 +0000

Hi,

I have reviewed the draft and find that is very nicely written and easy to understand. It would be nice to see this document taken further and made into an RFC.

I have a question regarding the usage of OAuth in constrained networks. In web architectures, OAuth is used a lot. However, in the constrained world, I am not sure if it applies to every situation. Typically, in constrained networks we have three types of connections: constrained device<->central (management) server(s), constrained device<-> temporary devices (e.g. mobile apps) and constrained device<->constrained device. For the constrained device<-> temporary devices (e.g. mobile apps) OAuth seems to work quite nicely and probably even for constrained device<->central (management) server(s).

I would like to focus on the constrained device<->constrained device to case. In this case, we typically have permanent authorization rules that connect e.g. sensors to actuators (pushbuttons connected to lights). For such permanent authorization rules that do not change, does it still make sense to use OAuth. I would have thought that an access control list type solution that is managed by a central server is more suitable for this situation. I would like to understand from the authors exactly which type of communication is being targeted in this draft and if it is also applicable to create "permanent client-server authorization rules".

Abhinav
________________________________________________________ The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 18 Nov 2015 09:14:23 +0100

Hi Abhinav,

> I have reviewed the draft and find that is very nicely written and easy
> to understand. It would be nice to see this document taken further and
> made into an RFC.
Thanks.

~snip~

> I would like to focus on the constrained device<->constrained device to
> case. In this case, we typically have permanent authorization rules that
> connect e.g. sensors to actuators (pushbuttons connected to lights). For
> such permanent authorization rules that do not change, does it still
> make sense to use OAuth. I would have thought that an access control
> list type solution that is managed by a central server is more suitable
> for this situation. I would like to understand from the authors exactly
> which type of communication is being targeted in this draft and if it is
> also applicable to create “permanent client-server authorization rules”.

The constrained client to constrained server case is conceptually
simpler than the other cases since the authorization step, as you noted,
already happened out-of-band (by someone).

This scenario motivated me to write this IoT credential grant, see
draft-tschofenig-oauth-iot. In response to the draft submission I got
comments that claimed I can get the same functionality already with base
OAuth, which may need to be discussed. At that time it was, however,
premature to have these detailed discussions.

Another input to take into account is a document you might well be
familiar with, namely <draft-somaraju-ace-multicast-00>. There we also
had use cases where the authorization rules were pre-provisioned into
the devices and, in addition to what you mentioned, the device may need
to operate without having an authorization server to consult in real time.

Does this make sense to you?

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 19 Nov 2015 10:57:39 +0100

As an add-on to my email from yesterday I thought it might be also
useful to look at the LWM2M protocol and to see whether it helps in
those scenarios. I was thinking about doing a tutorial about LWM2M to
the group for a little while already and maybe I should give it a try in
December.

Ciao
Hannes

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 19 Nov 2015 11:32:06 +0100

> the group for a little while already and maybe I should give it a try in

I think a LWM2M tutorial would be very helpful. Please do give it a try.

/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: Somaraju Abhinav <[email-masked]>
Date: Thu, 19 Nov 2015 12:49:58 +0000

Hi Hannes, Göran,

I will try to summaries your replies and please correct me if I am wrong.:
"The constrained client to constrained server case is conceptually simpler than the other cases since the authorization step, as you noted, already happened out-of-band (by someone)" and  “permanent client-server relations may be viewed as a special case of the dynamic access rights."

I agree with this assessment. However, for a lot of constrained devices, the only use case that is important is permanent client-server relations. So, considering the proposal to use OAuth draft as the starting point for the ACE solutions, the questions for me are:

1) Can we judge how many use cases we have for permanent client-server relations vs temporary (dynamic) client server relationships. From how I see it, the permanent ones are a lot more used in practice for constrained devices.

2) Do we want to mandate-
Option1: the use of full OAuth (constrained profile) for every device or
Option2: will we have a method to say that a constrained server or client is only going to support permanent links and not the full OAuth constrained profile.

3) If we choose Option 1 in Step 2, can we get an estimate of how much overhead it is compared to Option 1. The LWM2M comparison is relevant here which is more or less option 2 with Option 1 still possible but managed via a single central server.

Abhinav

________________________________________
From: Ace [[email-masked]] on behalf of Ludwig Seitz [[email-masked]]
Sent: Thursday, November 19, 2015 11:32 AM
To: [email-masked]
Subject: Re: [Ace] [ACE] Permanant client-server relations and draft-seitz-ace-oauth-authz-00

/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: Samuel Erdtman <[email-masked]>
Date: Thu, 19 Nov 2015 16:49:32 +0100

Hi Abhinav,

I´m glad to here that you liked the draft.

1.
> you might be right, I would say that all answers to this would just be
more or less qualified guesses.

2.
It is slightly unclear to me what you mean but I´ll try to explain my
understanding
* option one would be to use an optimised OAuth2 profile
* option two would be pre-provisioned keys to establish secure links
I prefer option one since it includes metadata around the keys, i.e. how
and where to use the keys and the server can connect them to an authorised
client. I think this is information that you must have in som way
independent of the solution, i.e. when you have added this to option two
you will have the same amount of metadata more or less (but also another
specification).

3.
I think that there will be no or very little overhead since from my
interpretation you would need to have som metadata around keys in option

Regarding LWM2M I think but I´m not sure that Hannes sees that it could be
used for provisioning of the trust relationship with the AS to RS (i.e.
pushing AS key), and possible also for the provisioning of OAuth2 token and
connected key to the Client.

Best Regards
//Samuel

On Thu, Nov 19, 2015 at 1:49 PM, Somaraju Abhinav <
[email-masked]> wrote:

> "The constrained client to constrained server case is conceptually simpler
> than the other cases since the authorization step, as you noted, already
> happened out-of-band (by someone)" and  “permanent client-server relations
> may be viewed as a special case of the dynamic access rights."
>
> I agree with this assessment. However, for a lot of constrained devices,
> the only use case that is important is permanent client-server relations.
> So, considering the proposal to use OAuth draft as the starting point for
> the ACE solutions, the questions for me are:
>
> 1) Can we judge how many use cases we have for permanent client-server
> relations vs temporary (dynamic) client server relationships. From how I
> see it, the permanent ones are a lot more used in practice for constrained
> devices.
>
> Option2: will we have a method to say that a constrained server or client
> is only going to support permanent links and not the full OAuth constrained
> profile.
>
> 3) If we choose Option 1 in Step 2, can we get an estimate of how much
> overhead it is compared to Option 1. The LWM2M comparison is relevant here
> which is more or less option 2 with Option 1 still possible but managed via
> a single central server.
>
> Abhinav
>
>
> ________________________________________________________ The contents of
> this e-mail and any attachments are confidential to the intended recipient.
> They may not be disclosed to or used by or copied in any way by anyone
> other than the intended recipient. If this e-mail is received in error,
> please immediately notify the sender and delete the e-mail and attached
> documents. Please note that neither the sender nor the sender's company
> accept any responsibility for viruses and it is your responsibility to scan
> or otherwise check this e-mail and any attachments.
>
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

---

From: Somaraju Abhinav <[email-masked]>
Date: Mon, 23 Nov 2015 08:27:53 +0000

Hi Samuel,
Thank you for your comments. Please see inline.

1.
> you might be right, I would say that all answers to this would just be more or less qualified guesses.
[AS] Agree.

2.
It is slightly unclear to me what you mean but I´ll try to explain my understanding
* option one would be to use an optimised OAuth2 profile
* option two would be pre-provisioned keys to establish secure links
I prefer option one since it includes metadata around the keys, i.e. how and where to use the keys and the server can connect them to an authorised client. I think this is information that you must have in som way independent of the solution, i.e. when you have added this to option two you will have the same amount of metadata more or less (but also another specification).
[AS] Ideally speaking, we do not want another specification but an addition to the OAuth document. Referring to Figure 1 in your document, can we not think of simpler flows where the authorization server writes client credentials directly to the Resource server and provides client information to the client. So, the only steps that need to be performed are E, B, C and F? I do not think the permanent client server roles are corner cases to consider and at least in my applications (indoor prof. lighting), it is the main use case. Maybe it would help if I could get a more detailed description of how this case will be addressed in the current draft.

3.
I think that there will be no or very little overhead since from my interpretation you would need to have som metadata around keys in option

Regarding LWM2M I think but I´m not sure that Hannes sees that it could be used for provisioning of the trust relationship with the AS to RS (i.e. pushing AS key), and possible also for the provisioning of OAuth2 token and connected key to the Client.

Best Regards
//Samuel

On Thu, Nov 19, 2015 at 1:49 PM, Somaraju Abhinav <[email-masked]<mailto:[email-masked]>> wrote:
Hi Hannes, Göran,

Abhinav

________________________________________
From: Ace [[email-masked]<mailto:[email-masked]>] on behalf of Ludwig Seitz [[email-masked]<mailto:[email-masked]>]
Sent: Thursday, November 19, 2015 11:32 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Ace] [ACE] Permanant client-server relations and draft-seitz-ace-oauth-authz-00

/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

_______________________________________________
Ace mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ace