Re: [Ace] Agenda

[Likepeng <[e-mail]>]

> What do you mean with the "OAuth/Kerberos design pattern"? Is that the
> 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:[e-mail]] 代表 Ludwig Seitz
> 发送时间: 2014年7月14日 20:42
> 收件人: [e-mail]
> 主题: Re: [Ace] Agenda
> 
> Hi Hannes,
> 
> just some requests for clarification. See inline.
> 
> /Ludwig
> 
> On 07/14/2014 10:46 AM, Hannes Tschofenig wrote:
> [...]
> > 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?
> 
> What do you mean with "What transport should be used?" Is that the DTLS vs
> Object Security discussion?
> 
> >
> > [[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)
> >
> 
> 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)?
> 
> 
> > 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?)
> 
> 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 [phone]
> http://www.sics.se