Subject: Re: [Ace] Acre

From: Stefanie Gerdes <[email-masked]>
Date: Fri, 24 Jul 2015 10:20:18 +0200

Hi Hannes,

Ludwig's authorization draft has the DCAF draft in the acknowledgements as one of the inspirations for the draft. I think it would help to state more clearly, which parts are DCAF if there are so large similarities. I don't think we should end up having two descriptions that are only slightly different.

Thanks,
Steffi

Am 24.07.2015 09:51 schrieb Hannes Tschofenig <[email-masked]>:
>
> Hi Steffi, 
>
>
> On 07/24/2015 01:57 AM, Stefanie Gerdes wrote: 
> > At the end of the ACE session yesterday you said that one of the models you are describing in your new authorization draft is mostly DCAF and only differs in very small details. I was wondering why you are not pointing that out in your draft. I think it will be less confusing for people. 
>
> I am not sure where you are heading with this question. I fear that 
> others might easily argue why you aren't referencing their spec either. 
>
> I believe the point raised with several drafts is the following: there 
> are various communication models in use today. 
>
> - Do we need all of them? 
>
> - Do we need to select a few of them? 
>
> - For a given model do we care much about the message names or details 
> in encoding? 
>
>
> Ciao 
> Hannes 
>
> _______________________________________________ 
> Ace mailing list 
> [email-masked] 
> https://www.ietf.org/mailman/listinfo/ace

---

From: Ludwig Seitz <[email-masked]>
Date: Fri, 24 Jul 2015 10:53:07 +0200

> Ludwig's authorization draft has the DCAF draft in the acknowledgements as one of the inspirations for the draft. I think it would help to state more clearly, which parts are DCAF if there are so l…

I think listing the differences is going to be less confusing.

So here is my take:

DCAF proposes to use the Push model, ACRE argues that there are 
(significant) use cases that require or are more optimally served by 
other models (Pull, Client-Pull).

As far as the Push model is concerned, DCAF and ACRE are rather similar 
with the following differences:

1. DCAF proposes to use DTLS exclusively. ACRE argues that it is useful 
to allow either object security or DTLS for communication security.

Note that for the Push model both require object security for the tokens 
anyway, so we are not saving any code size either way.

2. DCAF uses psk-identity to transfer the token, which we think is a 
cludge, especially since there is a standardized authorization data type 
for (D)TLS supplemental data (RFC 4680). ACRE proposes to treat the 
tokens as RESTful resources and allow clients to POST tokens to the 
resource server. Optionally ACRE suggests the use of TLS supplemental 
data to transfer tokens.

3. As a consequence of 2, in DCAF you have to perform a DTLS session 
renegotiation to update a token. In ACRE you just update the RESTful 
resource.

4. DCAF leverages the client authentication of DTLS to bind the token to 
the session. When using object security in ACRE this needs to be done by 
signing the client request with a key associated to the token.

5. In ACRE the RS needs to locate the corresponding token for an 
incoming request. Given that it is easy to find out which token applies 
to which resources and this information is static, this should not be 
very complicated.

Regards,

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: Hannes Tschofenig <[email-masked]>
Date: Fri, 24 Jul 2015 11:33:31 +0200

Just to respond from an OAuth ACE point of view since it also uses a
variant of the push model.

* It does not rely on DTLS for the communication between the client and
the RS but it can use it.

For the use of CoAP with bearer tokens (over DTLS) there is this
write-up: draft-tschofenig-ace-oauth-bt

Since we re-use as much as possible the use of DTLS with a
proof-of-possession token would at the moment resort to the token
binding work.

The proposal also works with the object security model Goeran has been
proposing for the case where a PoP token is used and proof of possession
happens at the app layer. In some sense you could call also our
Bluetooth Smart Door Lock investigations an application layer security
solution but it is the application layer within the BLE stack.

* There is not only the push model but also the token introspection
model, which keeps access tokens small. It does, however, require the RS
to be able to reach the AS.

* It provides flexibility for the access tokens and the type of
proof-of-possession model. It therefore works with symmetric as well
asymmetric keys.

Unlike any other proposal it is well integrated with user identity
management. It is well integrated in all scenarios where you use a smart
phone / tablet for use with IoT device.

Ciao
Hannes

On 07/24/2015 10:53 AM, Ludwig Seitz wrote:
>> Ludwig's authorization draft has the DCAF draft in the
>> acknowledgements as one of the inspirations for the draft. I think it
>> would help to state more clearly, which parts are DCAF if there are so
>> large similarities. I don't think we should end up having two
>> descriptions that are only slightly different.
>>
>> Thanks,
>> Steffi
>>
>