Re: [Ace] draft-selander-ace-eals vs. draft-vanderstok-ace-coap-est

Hello,

Just wanted to add,  as one of the authors of the
draft-sengul-ace-mqtt-tls-profile,
I can say we would be very happy to discuss what the overlaps with the
draft-palombini-ace-coap-pubsub-profile are and how we can progress with
that.
Of course, MQTT has some fundamental differences as a protocol.

This discussion will help our next revision also, which  we are working on
based on the feedback we received.
The new version will include options for better error and disconnection
handling, and token
updates with MQTT v5.

Thanks,
--Cigdem

On Thu, Sep 14, 2017 at 7:47 AM, Göran Selander <goran.selander@ericsson.com
> wrote:

> Hi Hannes,
>
> It is interesting to note that during the last 6 months there seems to be
> very little activity to encourage discussion or reviews of the drafts
> which actually are in scope of the current ACE charter. For example, what
> do people think about the overlaps between the two publish-subscribe
> profiles (draft-sengul-kirby-ace-mqtt-tls-profile vs.
> draft-palombini-ace-coap-pubsub-profile)? Instead, you as co-chair of ACE
> encourage the WG to discuss two drafts about certificate enrolment, a
> topic which is not even mentioned in the current charter.
>
> As co-author of one of the drafts in the subject of this mail I of course
> welcome the discussion, but it is important that this thread does not to
> distract the ACE WG from working according to its charter on its missed
> milestones.
>
> Now for the topic of comparing the certificate enrolment drafts.
> draft-vanderstok-ace-coap-est proposes a very natural and significant
> optimization of EST adapted to the established security setup for CoAP,
> and I fully support that. There are overlapping authors between the
> drafts, so clearly the drafts should not be seen in opposition to each
> other.
>
> My view of the potential contribution with draft-selander-ace-eals (which
> is a first sketch we made in the spring, and which I recently stepped in
> revision just to keep alive) is twofold:
>
> 1. It discusses the generalisation of EST to application layer security.
> The enrolment procedure in EST is in principle not dependent on what layer
> authentication takes place, provided there is security end-to-end between
> the endpoint making the enrolment request and the endpoint providing the
> certificate. As we know, there are common IoT settings where security on
> transport layer does not go end-to-end because of gateways or proxies or
> because of change of underlying layers, which is the reason for proposing
> this complement on the application layer. As to the actual enrolment
> procedure, it may well be the same in both cases of transport layer
> security or application layer security.
>
> 2. In a second independent component (section 3.2), the ACE framework is
> applied to authorise and provide keys to the endpoints involved in the
> enrolment, after which the very same enrolment procedure can take place.
> This shows a more lightweight key establishment than with a key exchange
> protocol (such as the DTLS handshake or EDHOC) with fewer and smaller
> messages, and less public key operations, all of which are favourable
> properties in constrained environments.
>
> The implicit question posed by draft-selander-ace-eals is the following:
> If we are considering one IoT variant of EST
> (draft-vanderstok-ace-coap-est) should we also consider other variants
> using the same enrolment procedure, which can be applied to a wider range
> of IoT use cases and/or which are more favourable in settings with
> constrained IoT devices?
>
>
>
> Göran
>
>
>
>
> On 2017-09-13 17:42, "Ace on behalf of Hannes Tschofenig"
> <ace-bounces@ietf.org on behalf of hannes.tschofenig@gmx.net> wrote:
>
> >Hi all,
> >
> >in previous IETF meetings we had presentations on these two documents
> >and it appears that there is an overlap. So far we haven't had a lot of
> >discussions on these proposals on the list but since there seems to be
> >interest from the folks attending the IETF meetings I am recommending to
> >have a discussion about the direction we should go with this work.
> >
> >Any thoughts?
> >
> >Ciao
> >Hannes
> >
> >_______________________________________________
> >Ace mailing list
> >Ace@ietf.org
> >https://www.ietf.org/mailman/listinfo/ace
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>