Subject: [Ace] Agenda

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 14 Jul 2014 10:46:37 +0200

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)

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 14 Jul 2014 14:41:55 +0200

Hi Hannes,

just some requests for clarification. See inline.

/Ludwig

On 07/14/2014 10:46 AM, Hannes Tschofenig wrote:
[...]
> 1b) What degree of flexibility should we aim for? DTLS or application

What do you mean with "What transport should be used?" Is that the DTLS 
vs Object Security discussion?

> Discussion Leader: Ludwig (to-be-confirmed)

What do you mean with the "OAuth/Kerberos design pattern"? Is that the 
Client, RS, AS architecture? Does it include the authorization push 
sequence or could it be any other (pull or agent)?

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

I think this question (3c) is too generic. If we ask like that, we will 
just reiterate the discussions currently ongoing on the DICE list (see 
the "Tyranny of the Lightswitch" thread).

We should really try to get input on what is likely to be supported by 
manufacturers of mass market IoT hardware.

/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: Likepeng <[email-masked]>
Date: Tue, 15 Jul 2014 00:39:51 +0000

> Client, RS, AS architecture?

Yes.

> I think this question (3c) is too generic. If we ask like that, we will just reiterate
> the discussions currently ongoing on the DICE list (see the "Tyranny of the
> Lightswitch" thread).

We can go a little bit further:
- long-term key established between the client and the authorization server
- long-term key established between the authorization server and the resource server
- short term key established between the client and the resource server

Also we need to talk about performance, size, .... and other considerations.

Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: Ace [mailto:[email-masked]] 代表 Ludwig Seitz
> 发送时间: 2014年7月14日 20:42
> 收件人: [email-masked]
> 主题: Re: [Ace] Agenda
> 
> Hi Hannes,
> 
> > 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.
> What do you mean with "What transport should be used?" Is that the DTLS vs
> Object Security discussion?
> 
> >
> Client, RS, AS architecture? Does it include the authorization push sequence or
> could it be any other (pull or agent)?
> 
> 
> > 3) Design Considerations
> >
> I think this question (3c) is too generic. If we ask like that, we will just reiterate
> the discussions currently ongoing on the DICE list (see the "Tyranny of the
> Lightswitch" thread).
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 15 Jul 2014 10:18:25 +0200

> - short term key established between the client and the resource server

The discussion on the DICE list was useful and of course the issues
surface also in this group.

If we could only figure out how to make any progress on that topic this
would be useful. Any ideas?

Ciao
Hannes

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 15 Jul 2014 10:25:06 +0200

> would be useful. Any ideas?

Well in the DICE thread you said that you could ask a colleague about 
the price of adding asymmetric crypto hardware:

> I could ask one of
> my co-workers to share his insight on cost of hardware and embedded
> industry with the rest of the group. This would be one data point. Maybe
> there are other companies willing to share their experience.

I think that would be progress.

/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: Tue, 15 Jul 2014 10:29:04 +0200

> the price of adding asymmetric crypto hardware:

That is too short notice to put a meaningful presentation together for
this meeting. Of course, I could arrange a Webex session in about 2 months.

Ciao
Hannes