[Ace] Agenda

Hannes Tschofenig <hannes.tschofenig@gmx.net> Mon, 14 July 2014 08:46 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 ED7481A0046 for <ace@ietfa.amsl.com>; Mon, 14 Jul 2014 01:46:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_BACKHAIR_22=1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 DnUMP8BkAQ6Q for <ace@ietfa.amsl.com>; Mon, 14 Jul 2014 01:46:42 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32E4B1A0379 for <ace@ietf.org>; Mon, 14 Jul 2014 01:46:42 -0700 (PDT)
Received: from [172.16.254.119] ([80.92.116.212]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M7YF5-1WKPRA3zCJ-00xGut for <ace@ietf.org>; Mon, 14 Jul 2014 10:46:40 +0200
Message-ID: <53C398ED.3030302@gmx.net>
Date: Mon, 14 Jul 2014 10:46:37 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "ace@ietf.org" <ace@ietf.org>
X-Enigmail-Version: 1.5.2
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="8Mg8Va63HxakgU6b7EoCAqJO9XxxQKHa2"
X-Provags-ID: V03:K0:+bnfW+GMql/R+agyONqCvsdAr6gjmPojuJZMBiVB5kEU8Ul1S7V FnUodWQIWgJ2B1uFu5Duc2fit07+CUPil4Q7LDPHbW9w9HPfYoVakfNEIj3mBQxXpoyrApq WI7qqmkTVlcW4cu1VlrOImnXcgZA4IsNGS8qMmsgNhCLzJUAUj9V7Yxw0VA9zNiwyHXrvWZ lvkYtGUqZ6ojaCfCxVMzg==
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/aseLSnrzbsNNjlMw1KgIxr19Ugw
Subject: [Ace] Agenda
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: Mon, 14 Jul 2014 08:46:44 -0000

Hi all,

Kepeng and I would like to thank you for the feedback on the list
regarding the agenda preparation. Below is our proposed agenda for the
meeting.

As you can see we have also made a few suggestions for discussion
leaders (who still need to confirm their willingness) and there are also
a couple of free spots as well. If you are willing to help out during
the meeting drop us a message.

Ciao
Hannes & Kepeng

------

Authentication and Authorization for Constrained Environments (ACE)

WEDNESDAY, July 23, 2014

0900-1130 EDT
Tudor 7/8 (MM)

- Welcome & Agenda Bashing (Chairs, 10 mins)

- ACE Introduction (Chairs, 10 mins)

Since this is the first meeting of the working group we would like to
give a brief description the high level goal of the group. This part of
the agenda should also help you to become familiar with the terminology.

- Design Directions

We want to spend the main meeting time to answer a couple of challenging
questions.
Our hope is it to get answers to some of these questions during the
meeting or in preparation of the meeting.

1) Problem Description

1a) Client <-> RS Communication: What transport should be used?
1b) What degree of flexibility should we aim for? DTLS or application
layer security?

[[Relevant document: draft-seitz-ace-problem-description-01]]

Discussion Leader: Ludwig (to-be-confirmed)

2) Design Patterns

2a) Is the OAuth/Kerberos design pattern sufficient?
(does it cover all the use cases)
2b) Is the OAUTH/Kerberos design pattern necessary?
(can we throw something away?)

[[Relevant document: draft-seitz-ace-usecases-01]]

Discussion Leader: Ludwig (to-be-confirmed)

3) Design Considerations

3a) What design components could we re-use?
3b) What areas need to be explored in more detail?

Example topics:

  * RS<->AS Communication: In scope / out of scope?
  * Protocol re-use: what's good and what's not?
  * Message encoding: Base64, JSON, ASN.1, CBOR

3c) Should the design be based on symmetric or asymmetric crypto?
  (or both?)

[[Relevant document: draft-seitz-ace-design-considerations-00]]

Discussion Leader: Goeran (to-be-confirmed)

4) Cross-domain Support

4a) How to address cross-domain support in the initial protocol design?
4b) What lessons from other areas can be taken into account?
4c) Do we need new terminology or can we re-use existing terms?

[[Relevant documents: draft-gerdes-ace-actors-01 and
draft-tschofenig-ace-overview-00]]

Discussion Leader: Carsten (to-be-confirmed)

- Summary and Next Steps (Chairs, 10 mins)