Re: [Ace] Solution direction

[Stefanie Gerdes <[e-mail]>]

Hi Erik,

DCAF as it is already supports less-constrained devices. It also works
together with OAuth as we showed in an example in
draft-gerdes-ace-dcaf-examples [1]. If we want to, we can also transport
OAuth tickets in DCAF. We should find out which is more useful for which
use case (we may find out that there is more than one answer to that).

The discussion always seems to be whether we are doing something for the
constrained devices or if we are supporting OAuth. I think we should do
both. I don't think it is that important whether we name the result
DCAF, OAuth or UMA in the end as long as it does the right thing.

Best regards,
Steffi

[1] https://tools.ietf.org/html/draft-gerdes-ace-dcaf-examples-00

On 11/19/2015 11:19 AM, Erik Wahlström neXus wrote:
> Hi Steffi,
> 
> Yes, I realise that DCAF can be profiled and used to non-constrained devices just as OAuth can be profiled for constrained devices. For me, it’s more of a question of where momentum is and taking that further to target the continuum of both non-constrained and constrained devices (i.e. take OAuth to constrained devices).
> 
> / Erik
> 
> 
>> On 19 Nov 2015, at 11:03, Stefanie Gerdes <[e-mail]> wrote:
>>
>> Hi Erik,
>>
>> Fortunately, DCAF works with constrained AND less-constrained devices,
>> so we will not have "parallel worlds" if we use it.
>>
>> Steffi
>>
>> On 11/18/2015 08:08 PM, Erik Wahlström neXus wrote:
>>> If the constrained world and the non-constrained world would exists in two different parallell worlds that would make sense. But it’s not. It’s a continuum where both big and small devices will talk to each other. I will have a phone that talks standard oauth2 flows to get a token from an authorization server and it’s later used against a constrained device using coap and vice versa.
>>>
>>> I would be fine if we only could get by with a JWT, but I don’t think so. Please prove me wrong :)
>>>
>>> / Erik
>>>
>>>
>>> On 18 Nov 2015, at 19:57, Anthony Nadalin <[e-mail]<mailto:[e-mail]>> wrote:
>>>
>>> Makes more sense to have a solution that uses Oauth and JSON/JOSE and a DCAF solution that uses CBOR/COSE instead of mixing all the combinations as that will be a nightmare
>>>
>>> From: Erik Wahlström neXus [mailto:[e-mail]]
>>> Sent: Wednesday, November 18, 2015 10:31 AM
>>> To: Anthony Nadalin <[e-mail]<mailto:[e-mail]>>
>>> Cc: Stefanie Gerdes <[e-mail]<mailto:[e-mail]>>; Hannes Tschofenig <[e-mail]<mailto:[e-mail]>>; Stephen Farrell <[e-mail]<mailto:[e-mail]>>; Kathleen Moriarty <[e-mail]<mailto:[e-mail]>>; Kepeng Li <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
>>> Subject: Re: [Ace] Solution direction
>>>
>>> Yes. Json will still be a key format. And it will be heavenly used, especially for class 2 devices. In our tests we did see that JWT got us a very long way. Especially if we just have to send token once (according to the draft).
>>>
>>> Then we have the super constrained class 1 devices. They need something more compact.
>>>
>>> Sent from my iPhone
>>>
>>> On 18 Nov 2015, at 19:17, Anthony Nadalin <[e-mail]<mailto:[e-mail]>> wrote:
>>> Its more than that as we have to deal with JSON and CBOR, so far OAUTH only deals with JSON in the various profiles/extensions
>>>
>>> From: Erik Wahlström neXus [mailto:[e-mail]]
>>> Sent: Wednesday, November 18, 2015 10:14 AM
>>> To: Anthony Nadalin <[e-mail]<mailto:[e-mail]>>
>>> Cc: Stefanie Gerdes <[e-mail]<mailto:[e-mail]>>; Hannes Tschofenig <[e-mail]<mailto:[e-mail]>>; Stephen Farrell <[e-mail]<mailto:[e-mail]>>; Kathleen Moriarty <[e-mail]<mailto:[e-mail]>>; Kepeng Li <[e-mail]<mailto:[e-mail]>>;[e-mail]<mailto:[e-mail]>
>>> Subject: Re: [Ace] Solution direction
>>>
>>> Don't think so. If it's a JWT/JOSE or a CWT/COSE does not mean the world. It's just a token format (both will exist). A client don't really have to care what type of token it is. It's just a access token.
>>>
>>> Then we have the framework on how access tokens are retrieved and sent to establish a context. That's another thing.
>>>
>>> / Erik
>>>
>>> Sent from my iPhone
>>>
>>> On 18 Nov 2015, at 18:39, Anthony Nadalin <[e-mail]<mailto:[e-mail]>> wrote:
>>> Don’t or won’t we already have that confusion with COSE and JOSE (much like confusion with DCAF and OAUTH) ?
>>>
>>> From: Ace [mailto:[e-mail]] On Behalf Of Erik Wahlström neXus
>>> Sent: Wednesday, November 18, 2015 2:58 AM
>>> To: Stefanie Gerdes <[e-mail]<mailto:[e-mail]>>
>>> Cc: Hannes Tschofenig <[e-mail]<mailto:[e-mail]>>; Stephen Farrell <[e-mail]<mailto:[e-mail]>>; Kathleen Moriarty <[e-mail]<mailto:[e-mail]>>; Kepeng Li <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
>>> Subject: Re: [Ace] Solution direction
>>>
>>> Hi,
>>>
>>> Dynamic client registration (RFC7591) and User-Managed Access (UMA) Profile of OAuth 2.0 (https://docs.kantarainitiative.org/uma/rec-uma-core.html<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdocs.kantarainitiative.org%2fuma%2frec-uma-core.html&data=01%7c01%7ctonynad%40microsoft.com%7c2e4a423528b84869171d08d2f0071896%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ALYnNx65C18sUYQB3LgXOc5s5teOHDYv0NzqmCsubAI%3d>) solves those scenarios.
>>>
>>> To make them work with constrained clients and servers, both RFC7591 and UMA must to be profiled in the same way as the OAuth for IoT draft did for core oauth.
>>>
>>> Both dynamic client registration and UMA where added later on after Oauth2 (RFC6749) was completed. I think that’s a sound model that we should follow. Get the core concepts down, then extend them when needed and when we do that we should re-use the concepts already there.
>>>
>>> Having two different proposals, both DCAF and OAuth for IoT, running at the same time confuses implementors. I don’t think we want to do that.
>>>
>>> / Erik
>>>
>>>
>>>
>>> On 17 Nov 2015, at 10:07, Stefanie Gerdes <[e-mail]<mailto:[e-mail]>> wrote:
>>>
>>> Hi all,
>>>
>>> I think we should continue working on DCAF in ACE. It provides valuable
>>> concepts and mechanisms which is why many solutions in ACE draw heavily
>>> from DCAF.
>>>
>>> I think one aspect did not really become clear during the ACE session in
>>> Yokohama: A solution with only one supporting less constrained device
>>> will not be able to fully support communication between constrained
>>> nodes as DCAF does. One main question that is only partly solved by
>>> other solutions is: How can a constrained client authenticate the other
>>> party?
>>>
>>> A constrained device is not able to establish security associations as
>>> easily as a less constrained device. The keying material that is used
>>> for authorization and secure communication must securely be obtained. It
>>> can either be provisioned manually to the constrained device or a
>>> security association with a less constrained device is required that can
>>> then provide the keying material.
>>>
>>> An Authorization Server can provide session keys to the constrained
>>> devices, but the constrained device must have a security association
>>> with the AS to authenticate the origin of the session key. In a scenario
>>> where we have only a single AS and two constrained nodes, both need a
>>> security association with that AS. For cross-domain scenarios this might
>>> be difficult. We will need to manually provision the keying material to
>>> one of the devices which makes the dynamic setup of secure communication
>>> impossible. That's why we need two less-constrained devices in this
>>> scenario.
>>>
>>> You may think that this has nothing to do with authorization and
>>> therefore is not a topic for ACE. Well, it has, but another
>>> terminology-discussion might not be that useful. However, the important
>>> thing is that developing an additional solution to solve this problem
>>> will very likely add more overhead. The result will be more complex and
>>> more difficult to implement. Until such a solution is developed we will
>>> need to use complex workarounds (e.g. manual provisioning), may have
>>> security problems or are not able to address certain scenarios at all.
>>>
>>> But we have never done this before, why now? Because other than the
>>> general purpose computers that we are using today, constrained devices
>>> will communicate autonomously without the help of their user. They often
>>> will not even have user interfaces. Until now this was true for servers
>>> which is why existing protocols protect them. In a true Internet of
>>> Things this will also be true for clients. We therefore need to
>>> reconsider how clients can be protected and how their actions can be
>>> controlled by their owners.
>>>
>>> DCAF supports scenarios with a single less-constrained device (AS) as
>>> well as scenarios where both the Client and the Server have their own.
>>> It works with OAuth and may even transport OAuth tickets if that is
>>> necessary. It has a built-in key distribution mechanism and therefore is
>>> very efficient. The main fault of DCAF seems to be that we didn't call
>>> it OAuth.
>>>
>>> I think DCAF should be one of the building blocks (one of the tools in
>>> our toolbox) that ACE is working on.
>>>
>>> Best regards,
>>> Steffi
>>>
>>> _______________________________________________
>>> Ace mailing list
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/ace<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2face&data=01%7c01%7ctonynad%40microsoft.com%7c7d0c39fa74cf424c073f08d2f043fc00%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=fUd%2fyWsFTYJgyL8ylrY%2bLjeEDGYXOuEB7ikV5vKJ0M0%3d>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Ace mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ace
>>>
>>
>> -- 
>> Stefanie Gerdes			Tel: [phone]
>> TZI Universität Bremen		E-Mail: [e-mail]
>> Bibliothekstr. 1, MZH 5150
>> 28359 Bremen, Germany
> 
> 
> 

-- 
Stefanie Gerdes			Tel: [phone]
TZI Universität Bremen		E-Mail: [e-mail]
Bibliothekstr. 1, MZH 5150
28359 Bremen, Germany