[Ace] Scope of the ACE Charter

Hannes Tschofenig <hannes.tschofenig@gmx.net> Wed, 05 March 2014 14:32 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 083071A014C for <ace@ietfa.amsl.com>; Wed, 5 Mar 2014 06:32:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level:
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
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 XxhE-BDRPHw2 for <ace@ietfa.amsl.com>; Wed, 5 Mar 2014 06:32:34 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 27ADB1A0641 for <ace@ietf.org>; Wed, 5 Mar 2014 06:32:34 -0800 (PST)
Received: from [192.168.10.132] ([31.133.156.1]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lt2BW-1XMdRn1d5W-012be6 for <ace@ietf.org>; Wed, 05 Mar 2014 15:32:29 +0100
Message-ID: <5317357B.6020407@gmx.net>
Date: Wed, 05 Mar 2014 15:32:27 +0100
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "ace@ietf.org" <ace@ietf.org>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="3enjJQCLaV4edW0WTOxJLmLmfiGtHItAR"
X-Provags-ID: V03:K0:y1jQaXhu8qh8CWOeikr/3bh7wi0W0Uea6NZtsqzz4tMlpsIjwX1 b4lAXlvidenAAH4IAIiIguFUgTC/L0NtAZ/V6oM5PjexEz9gPNcA0GzKBCV/l4g0bjcoN2h muxhI2VeDUwjbVK5M1Aa78UgmQ6NKf5TMXKD7zwpfKkkR6ha8U4KHVR10qw9RLJYQ7EOorj z3YmcBGiFU7Cw4TDRoTbg==
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/YnLPogNsdjwsWDHwXTqRISwKkr8
Subject: [Ace] Scope of the ACE Charter
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: <http://www.ietf.org/mail-archive/web/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: Wed, 05 Mar 2014 14:32:36 -0000

Hi all,

I would like to thank you all for the great discussion today at the BOF.
There was good feedback and the following scoping aspect showed up.

In a nutshell there was some disagreement to purely focus on CoAP/DTLS
as part of a future working group.

There was not enough time to go down to the details during the session
due to lack of time. Hence, I will try to clarify this aspect on the
mailing list.

Let us have a look at the high level architecture:

                                          +---------------+
                                          | Authorization |
             +--------------------------->|  Server       |
             |        (I)                 +---------------+
             |                                  ^
             |                                  |
             |                                  |
             |                                  | III
             |                                  |
             |                                  |
             |                                  |
             v                                  v
        +-----------+                     +-----+-----+
        |           |      II             | Resource  |
        |   Client  | <..................>| Server    |
        +-----------+                     +-----------+

I: This is the interaction where keying and authorization information is
provided to the client.

II: This is the resource access.

III: This is a potential exchange necessary for having the resource
server interacting with the authorization server for authenticating the
client and for authorizing the client.

(The exact details of the interaction depend on the specific solution,
of course.)

As you can see in the figure, there are various places where DTLS and
CoAP should or shouldn't be used.

A few persons said that they want to use other protocols besides CoAP
and DTLS.

Please explain me where you would like to other protocols being taken
into consideration. What protocols are you considering in which of these
interfaces?

Ciao
Hannes