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

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 13 Sep 2017 17:42:41 +0200

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

---

From: Göran Selander <[email-masked]>
Date: Thu, 14 Sep 2017 06:47:18 +0000

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"
<[email-masked] on behalf of [email-masked]> wrote:

>_______________________________________________
>Ace mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ace

---

From: Cigdem Sengul <[email-masked]>
Date: Thu, 14 Sep 2017 10:34:46 +0100

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 <[email-masked]
> wrote:

---

From: peter van der Stok <[email-masked]>
Date: Fri, 15 Sep 2017 10:05:06 +0200

Hi Goran and Hannes,

Thanks Hannes, for starting the discussion.
I am glad to contribute to this discussion, as one of the more 
interested parties, co-author of est-coaps.
Looking at the charter of ACE, the following sentences seemed of 
interest to me.

"As a starting point, the working
group will assume that access to resources at a resource server by a
client device takes place using CoAP and is protected by DTLS. Both
resource server and client may be constrained. This access will be
mediated by an authorization server, which is not considered to be
constrained."

" Note that the initial focus is on CoAP and HTTP
with DTLS and TLS. Other security protocols may be considered as long as
the primary focus is maintained."

It clearly states that for the authorization and authentication coap and 
dtls are the first technologies that are investigated followed by other 
technologies.
Mapping this approach from authorization to certificate management, The 
same text seems valid to me, and I consider the coap-est draft belonging 
to the coap-dtls focus and eals draft belonging to other technologies. 
They are complementary in my view.

Currently, many manufacturers are happy to use their "finally" working 
dtls implementation. They are reluctant to try anything new at this 
moment. That motivates the writing of the coap-est draft.

That does not mean that manufacturers will not go over to new technology 
in a later stage, once the advantages are clearer, and more experience 
has been gained. Neither does it mean that all manufacturers are glued 
to their current DTLS implementation.

Although ACE focuses on authentication and authorization, it is the WG 
that looks after security for constrained devices, using RESTful 
techniques, CoAP and TLS/DTLS; and as such I hope the "certificate 
management" drafts fit in.

Looking forward to other reactions on this subject.

Peter

---

From: Eliot Lear <[email-masked]>
Date: Fri, 15 Sep 2017 13:07:02 +0200

Hi Hannes,

To keep things simple to understand, what would be best is the closest
analog to EST/HTTP.  I don't object to other work going on, however.

Eliot