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

From: Göran Selander <[email-masked]>
Date: Sun, 1 Nov 2015 13:07:48 +0000

Hi Rafa,

Thanks for good comments. There were some outstanding questions Hannes
didn’t reply to, inline.

On 2015-10-31 21:03, "Hannes Tschofenig" <[email-masked]> wrote:

>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:
>> 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.
>
>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.
>
>> 
>> 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.
>> 
>
>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-20151
>022.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.
>
>> 
>> "Figure 1: Overview of the basic protocol flow
>> 
>> Requesting an Access Token (A):”
>> 
>> [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.
>
>
>
>
>
>> 
>> "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?
>
>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.
>
>
>> 
>> “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.
>
>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.
>
>
>
>
>> 
>> "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.
>
>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.
>
>> 
>> 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?

[GS] Yes, you are right that the client needs to prove possession of the
key in the PoP token, but the PoP token provisioning needs not be
integrity protected by the client. It suffices in principle that it is
signed or MACed by the AS (you could also consider replay protection). The
proof of possession step comes in the access request, which may be
separated out from the token provisioning step, relating to your next
question.

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

[GS] As you write, a second POST using the same PoP token would not lead
to a violation of privileges, but may be used in a DoS attack which is one
reason to have some form of replay protection. Just to be clear, the
intent here is to minimize the transport so that the PoP token is
transported once but may be used multiple times (if supported by the
claims).

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

[GS] Just to add to what Hannes wrote, we consider the optimization of
combining token provisioning with access request to RS in Appendix B.

Göran

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

---

From: Rafa Marin Lopez <[email-masked]>
Date: Sun, 1 Nov 2015 21:04:00 +0100

Hi Erik,

Thanks for your clarifications. See my comments inline:

> El 31 oct 2015, a las 12:25, Erik Wahlström neXus <[email-masked]> escribió:
> 
> 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]> wrote:
> 
>> Dear authors, all:
>> 
>> 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.
> 
> Yes. I also thinks that would be valuable and we should add that going forward.
> 
>> 
>> [Rafa]  What types of IoT devices already use OAuth 2.0? A reference with this usage of OAuth 2.0 would be helpful.
> 
> 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.

[Rafa] Let’s wait for two weeks then. No problem!
> 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.

[Rafa] Yes, I am aware you’re using client credentials. I was wondering if it would be useful to mention what choices could be considered as client authentication.

>>   token.  Requests sent to the /token resource use the HTTP POST method…"
>> 
> 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.
> 
>> 
>> [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.
> 
> 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.
> 
>> 
>> [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.
> 
> 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.”

[Rafa] Yes I noticed that but my point is that the interaction between C and AS could be placed out of the that section. In 6.1 you could just mention that C already has the access token.

> 
> 
> That could be done in factory, installation or one minute or a lot of years before depending on the scenario.
> 
>> 
>> Page 16
>> 
>>      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?
> 
> 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.

[Rafa] Fig. 7  with the DTLS negotiation, right?

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

[Rafa] Yes that would be good. 

>> [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 will be different needs for different deployments.
> 
>> 
>> 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?
>> 
> "Messages" is actually tokens in this scenario.

[Rafa] Oh I see.

Thanks!
> It did. Thanks!
> / Erik
>> 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]
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ace

-------------------------------------------------------
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: Rafa Marin Lopez <[email-masked]>
Date: Sun, 1 Nov 2015 21:05:20 +0100

Hi Hannes:

> El 31 oct 2015, a las 13:03, Hannes Tschofenig <[email-masked]> escribió:
> 
> Hi Rafa,
> 

[Rafa] Thank for your answer. I think EAP-based solution can be used as bootstrapping and as a choice of client authentication with the AS to bootstrap security between both entities. From that point , an ACE solution as the one based on OAuth 2.0 will happen.

See my comments inline

> also show OAuth-based scenarios at the same event.

[Rafa] It is fine. I will looking forward to seeing those results.

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

[Rafa] That’s for sure. But having some preliminary is always useful to have an initial approximation. 

> http://www.internetsociety.org/sites/default/files/ISOC-IoT-Overview-20151022.pdf
> 
> I have shared other examples from the fitness / wearable sector previously.
> 

[Rafa]  Thanks for the pointer. Maybe it is worthy including this reference.  

> little about the OAuth landscape.

[Rafa] I see. Nevertheless, I think this should be clarified this aspect in some point in the evolution of the I-D.

> HTTP without any problems.

[Rafa]  Yes I know that but the text seems limiting the case to not constrained case. That is why I mentioned it.

> granted permissions in real-time vs. being offline.

[Rafa] My point is that in 6.1 it is assumed precisely that at some point in the past the client already got an access token but when using the access token the AS is offline for both the client and the resource server.

> qualification "offline during the time of the resource access" might

[Rafa] What I suggested that in the interaction of the AS should be placed out of this section.
> is a side-effect of the CoAP design.

[Rafa] So the PoP token is first presented without client authentication because it may not fit in the resource request, correct? According to Goran’s comment key confirmation happens, for example, during the establishment of the DTLS connection just after sending the PoP token (Fig. 7). Am I right?

Thanks!

---

From: Rafa Marin Lopez <[email-masked]>
Date: Sun, 1 Nov 2015 21:17:28 +0100

Hi Göran:

> signed or MACed by the AS (you could also consider replay protection).

> The

[Rafa] You mean the Fig. 7 where the DTLS is established that proves the possession of the key , right?

> transported once but may be used multiple times (if supported by the

[Rafa] Do you mean creating a state related with the PoP token in the resource server before accessing the service? Is this correct?

> combining token provisioning with access request to RS in Appendix B.

[Rafa] Thanks for the pointer!

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 2 Nov 2015 08:09:11 +0100

>> "Messages" is actually tokens in this scenario.

Actually the client might actually not be sending any messages to the RS 
here. The example we are looking at is a publish-subscribe scenario with 
a message broker as suggested in draft-koster-core-coap-pubsub-02. So 
the RS would send (encrypted and signed) sensor readings to the broker 
and the client would get those readings directly from the broker without 
ever sending messages to the RS. It would also get the necessary keys 
from the AS if it is allowed 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