Subject: [Ace] My comments about draft-seitz-ace-oauth-authz-00

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 30 Oct 2015 14:46:00 +0100

Dear authors, all:

Here you can find my review about draft-seitz-ace-oauth-authz-00.

The document is very detailed, which helps to understand the proposal. In my opinion, using a well-known protocol such as OAuth 2.0 where many people are working and have worked gives maturity and makes comprehensible the proposal to a broader audience. I also think it would be good to have some performance data (if available) such as message size, processing time , etc… . In any case, I believe the usage of OAuth 2.0 is a right and reasonable path for achieving an ACE solution.

Here some more detail comments/questions:

In page 3:

"This memo describes how to re-use OAuth 2.0 [RFC6749] to extend
   authorization to Internet of Things devices with different kinds of
   constrainedness.  At the time of writing OAuth 2.0 is already used
   with certain types of IoT devices and this document will provide..."

[Rafa]  What types of IoT devices already use OAuth 2.0? A reference with this usage of OAuth 2.0 would be helpful.

"Figure 1: Overview of the basic protocol flow

   Requesting an Access Token (A):”

[Rafa] Is there any assumption for the client authentication here?

"The /token resource (called "endpoint" in OAuth 2.0), defined in
   Section 3.2 of [RFC6749], is used by the client to obtain an access
   token.  Requests sent to the /token resource use the HTTP POST method…"

[Rafa] Mmmmm… if client is constrained … will it use HTTP POST? 

“6.1 Client and Resource Server are Offline"

[Rafa] I realize that offline is sometimes confusing. client and resource server can communicate each other. The AS is offline since it is not reachable. But anyway, this is a minor thing.

 "A: The client first generates a public-private key pair used for
      communication security with the RS."

[Rafa] In the same section 6.1, you describe the case where client and resource server cannot contact the AS. However you describe the communication with the AS. This might result confusing is shown. Perhaps the interaction with the AS should be placed out of this section.

Page 16

"Figure 5: Access Token including Public Key of the Client.

   Messages C and F are shown in Figure 6 - Figure 7.

      C: The client then sends the PoP token to the /authz-info resource
      at the RS.  This is a plain CoAP request, i.e. no DTLS/OSCOAP
      between client and RS, since the token is integrity protected
      between AS and RS."  

[Rafa] I think I am missing something here. A PoP token proves that the client knows a key (key confirmation). But the reason you give for not using DTLS/OSCOAP is that the token is integrity protected AS and RS. The client should prove that it owns the key anyway, no?

"The RS verifies that the PoP token was created
      by a known and trusted AS, is valid, and responds to the client.
      The RS caches the security context together with authorization
      information about this client contained in the PoP token."

[Rafa] This is related to my previous comment. Is it possible for an attacker to reply the PoP token? It should not due to PoP token nature but nothing is mentioned about it, just the verification that it was created by a trusted AS. Maybe my understanding of PoP token is wrong. 

"6.3.  Token Introspection with an Offline Client"

[Rafa] Although token introspection may be an interesting feature, I am thinking that sending additional messages from the RS to the AS is not good when RS is constrained. I understand it is a tradeoff between “authorization freshness” vs additional signaling. 

Page 25: "In case 2., the RS does not need to receive any message from the
   client," 

[Rafa] I do not understand why the RS does not need to receive any message from the client… could you clarify?

Hope this helps.

Best Regards.

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Erik Wahlström neXus <[email-masked]>
Date: Sat, 31 Oct 2015 11:25:59 +0000

Thanks for the review. It's very valuable.

See comments below.

Sent from my iPhone

On 30 Oct 2015, at 14:46, Rafa Marin Lopez <[email-masked]<mailto:[email-masked]>> wrote:

Dear authors, all:

Yes. I also thinks that would be valuable and we should add that going forward.

In page 3:

I personally have been working on two but can't show them yet. Hope to be able to show more in 2 weeks. You could also argue for that the API economy is also good examples where machines talks to machines where I would say that oauth2 have become the standard way to protect the communication.

Vanilla Oauth2 supports many types of grant flows. The draft uses client credentials (could be pre provisioned either manually or using something like dynamic client registration specs from oauth wg). There is no reason for not using other types of credentials for authentication against the AS.

No. It's just bad wordings. Good catch. If the client would not be constrained then http post would do, but otherwise there are coap examples of it in Figure 2.

Yes I see the point. We tried our a couple of namings of the examples of different deployment models using the oauth framework but I guess it still can be worked on a bit more.

We state in the intro text that it's done priori of the real access requests. It's still a mandatory step to initialize C and RS.

"This access procedure involves

   steps A, B, C, and F of Figure 1, but assumes that step A and B have
   been carried out during a phase when the client had connectivity to
   AS."

That could be done in factory, installation or one minute or a lot of years before depending on the scenario.

Page 16

That's done later when the real GET request is sent. In the first request the access token is sent to the RS. The token is, as stated, integrity protected by the AS and then verified and stored by the RS. In the later get request the pop key is used by the client to prove to the RS that the client really have access to the key.

The token could include a "cti" claim defined in appendix D that talks about cbor web tokens (CWT). That could be used to prevent replays but there are also features in the object security drafts for he same. We should add more details about replays in the security considerations section.

Yes. There will be different needs for different deployments.

"Messages" is actually tokens in this scenario.

Hope this helps.

It did. Thanks!

/ Erik

Best Regards.

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]<mailto:[email-masked]>
-------------------------------------------------------

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 31 Oct 2015 13:03:39 +0100

Hi Rafa,

thanks for you review. Since you have contributed the EAP-based solution
to the group I was obviously very interested to hear your opinion.

Responses inline:

On 10/30/2015 02:46 PM, Rafa Marin Lopez wrote:
> The document is very detailed, which helps to understand the
> proposal. In my opinion, using a well-known protocol such as OAuth
> 2.0 where many people are working and have worked gives maturity and
> makes comprehensible the proposal to a broader audience. I also think
> it would be good to have some performance data (if available) such as
> message size, processing time , etc… . In any case, I believe the
> usage of OAuth 2.0 is a right and reasonable path for achieving an
> ACE solution.

Thanks for the positive feedback.

Regarding the performance data we can put some figures together based on
what we have been playing with. In fact, we (Erik/Samuel from Nexus
Technology and ARM) are going to show a demo of OAuth for a home
automation scenario at the upcoming ARM TechCon event. Forgerock will
also show OAuth-based scenarios at the same event.

What is difficult with the performance data is that it depends a bit on
the assumptions made for the scenario. For example, in our case we are
using Bluetooth Smart with a custom BLE service for the communication
between an Android phone and an IoT device. The custom BLE service uses
JOSE, which is quite naturally more heavy than the COSE solution
currently being developed. While we didn't see problems with the JOSE
solution so far we could replace it with COSE reducing the number of
bits on the wire. For the data exchanged between the phone and the
authorization server it again depends what user experience is offered
and what authentication mechanism is utilized.

In a nutshell, there is more than just counting bits on the wire there.

> [Rafa]  What types of IoT devices already use OAuth 2.0? A reference
> with this usage of OAuth 2.0 would be helpful.
> 

There are a number of different communication scenarios, as outlined in
the recent ISOC publication:
http://www.internetsociety.org/sites/default/files/ISOC-IoT-Overview-20151022.pdf

For the "Back-End Data-Sharing Model", described on page 16, OAuth is
used quite frequently. This is also pretty reasonable since many
companies seek to share data they collect from IoT devices (with the
permission of the user). Here is an example from the vehicle environment:
https://developer.carvoyant.com/io-docs

I have shared other examples from the fitness / wearable sector previously.

Also for devices that have a user interface but limited input
capabilities OAuth has been used. Here are two examples:
https://developers.facebook.com/docs/facebook-login/for-devices
https://developers.google.com/youtube/v3/guides/auth/devices

This "Device-to-Cloud Communications" scenario is described on page 14
in the ISOC paper.

In general, in terms of deployment it is more common for IoT devices to
communicate with some gateway or a cloud-based service rather than
having IoT devices communicate directly with each other.

> [Rafa] Is there any assumption for the client authentication here?

Yes, the client has to be authenticated prior to get an access token.
There is also the consent aspect here, which may require authentication
of a human.

The client credentials are provisioned to the device either upfront (for
example during manufacturing) or the client is registered dynamically
(which is what we have the dynamic client registration for).

When we wrote the UMA for IoT document there we also had spoke about the
need to consider cases where the consent comes up-front. For this
document we didn't want to go into that level of detail since these
scenarios are a bit more sophisticated and we already have this other
document available.

For this write-up we have taken the approach that the reader knows very
little about the OAuth landscape.

> [Rafa] Mmmmm… if client is constrained … will it use HTTP POST?

In this document we offer the choice to either use HTTP or CoAP.
We are exploring the use of HTTP/2 and QUIC.

But keep in mind that in most scenarios not everything is constrained.
For example, you might have a person in a smart home using his phone or
table to control lights and other devices. Their phone can very well use
HTTP without any problems.

> [Rafa] I realize that offline is sometimes confusing. client and
> resource server can communicate each other. The AS is offline since
> it is not reachable. But anyway, this is a minor thing.

That's a good point, which we may need to describe a bit more.
With the requirements outlined in our group it is obviously not possible
to have a scenario where everything is fully offline and we wouldn't
really be talking about IoT then anyway (but rather about embedded
devices).

Here the distinction is whether the resource server is able to contact
the authorization server at the time of the resource request. The client
still has to be able to obtain the access token at some point in time.
There is, of course, also a tradeoff between the ability to revoke
granted permissions in real-time vs. being offline.

> [Rafa] In the same section 6.1, you describe the case where client
> and resource server cannot contact the AS. However you describe the
> communication with the AS. This might result confusing is shown.
> Perhaps the interaction with the AS should be placed out of this
> section.

I guess this is the same issue as with the previous comment. I believe
we need to describe more clearly what we mean by offline. I think the
qualification "offline during the time of the resource access" might
describe it better.

> C: The client then sends the PoP token to the /authz-info resource at
> the RS.  This is a plain CoAP request, i.e. no DTLS/OSCOAP between
> client and RS, since the token is integrity protected between AS and
> RS."
> 
> [Rafa] I think I am missing something here. A PoP token proves that
> the client knows a key (key confirmation). But the reason you give
> for not using DTLS/OSCOAP is that the token is integrity protected AS
> and RS. The client should prove that it owns the key anyway, no?
> 
> "The RS verifies that the PoP token was created by a known and
> trusted AS, is valid, and responds to the client. The RS caches the
> security context together with authorization information about this
> client contained in the PoP token."
> 
> [Rafa] This is related to my previous comment. Is it possible for an
> attacker to reply the PoP token? It should not due to PoP token
> nature but nothing is mentioned about it, just the verification that
> it was created by a trusted AS. Maybe my understanding of PoP token
> is wrong.
> 

This is a very good comment since I had to fight with this issue as
well. Here is the issue. If you look at the way how things work in HTTP
then you would include the token with the (initial) resource request.

We ideally want to have the same pattern also in CoAP and CoAP is
supposed to be designed like HTTP. However, as it turns out there are
some issues in terms of size limitations. Hence, it may be necessary to
send the token to a special authorization endpoint first before making
the resource request. While I do not quite like that design I believe it
is a side-effect of the CoAP design.

> [Rafa] Although token introspection may be an interesting feature, I
> am thinking that sending additional messages from the RS to the AS is
> not good when RS is constrained. I understand it is a tradeoff
> between “authorization freshness” vs additional signaling.

Yes, there is a tradeoff here and we allow those who deploy the protocol
to decide themselves about this tradeoff.

> 
> Page 25: "In case 2., the RS does not need to receive any message
> from the client,"
> 
> [Rafa] I do not understand why the RS does not need to receive any
> message from the client… could you clarify?

I let Goeran respond to this comment since it relates to the publish
subscribe model.

Ciao
Hannes

> 
> Hope this helps.
> 
> Best Regards.
> 
> ------------------------------------------------------- Rafael Marin
> Lopez, PhD Dept. Information and Communications Engineering (DIIC) 
> Faculty of Computer Science-University of Murcia 30100 Murcia -
> Spain Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked] 
> _______________________________________________ Ace mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/ace
>