Re: [Ace] Innovating

Stefanie Gerdes <gerdes@tzi.de> Fri, 30 October 2015 23:32 UTC

Return-Path: <gerdes@tzi.de>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78761B3C95 for <ace@ietfa.amsl.com>; Fri, 30 Oct 2015 16:32:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level:
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27EBQ5teasmX for <ace@ietfa.amsl.com>; Fri, 30 Oct 2015 16:32:13 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C65C1B3C94 for <Ace@ietf.org>; Fri, 30 Oct 2015 16:32:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t9UNW78l029032; Sat, 31 Oct 2015 00:32:07 +0100 (CET)
Received: from [192.168.1.109] (pD9F61E6C.dip0.t-ipconnect.de [217.246.30.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nng071cmkz2FMg; Sat, 31 Oct 2015 00:32:07 +0100 (CET)
From: Stefanie Gerdes <gerdes@tzi.de>
To: Samuel Erdtman <samuel@erdtman.se>, Carsten Bormann <cabo@tzi.org>
References: <56326D0D.9020309@tzi.org> <CAF2hCbYy17CENMe6tJvD49QQpdNOVp9nGNNcEXVqPXa=_qgTEg@mail.gmail.com>
Message-ID: <5633FDF6.2010501@tzi.de>
Date: Sat, 31 Oct 2015 00:32:06 +0100
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CAF2hCbYy17CENMe6tJvD49QQpdNOVp9nGNNcEXVqPXa=_qgTEg@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ace/RsGJgg_n_RKIX8-3GAgFjv4mQBU>
Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>, Olaf Bergmann <bergmann@tzi.org>, "Ace@ietf.org" <Ace@ietf.org>, Göran Selander <goran.selander@ericsson.com>
Subject: Re: [Ace] Innovating
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Oct 2015 23:32:15 -0000

Hi all,

The solutions in ACE are all reusing existing solutions, they are just
using different solutions to a different extent.

The use cases show that there is a large variety of scenarios with
different characteristics. The scenarios differ from the web scenarios
which is why we founded ACE in the first place. Some of the use cases
might only require a little tweaking of existing protocols, others need
more consideration about how those protocols can be applied.

We designed DCAF to address scenarios where the client, the server or
both can be class-1 devices (see RFC 7228 [1]), where the client and the
server may belong to different owners with distinct authorization
policies and where these owners may not intervene in the authorization
process at the time of the communication. As far as I understand
draft-seitz-ace-oauth, it only supports less-constrained clients. That
might be fine for the use cases and devices that you have in mind. With
DCAF, we go a bit further into the constrained world and want to enable
constrained devices to securely communicate with other constrained devices.

Of course we want DCAF to interoperate with existing protocols. That is
why we describe how such interactions can work (see
draft-gerdes-ace-dcaf-examples [2]).

Best regards,
Steffi

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