Subject: [Anima] ACE new charter

From: Daniel Migault <[email-masked]>
Date: Mon, 7 Dec 2020 13:22:48 -0500

Hi,

The ACE WG though you might be interested in knowing that the current ACE
charter considers, among other things, working on CMPv2 over CoAP. The
current charter can be found here [1].
If you think the work should be done in another WG, please let us know
before Friday December 11, so we can move the charter forward.

Yours,
Daniel

[1]
https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing

-- 
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Mon, 14 Dec 2020 12:00:10 -0500

Hi Ben,

The current proposed charter for ACE is as follows. As soon as the charter
is validated by the IESG, we will start call for adoption - at least for
the CMPv2 and EAP items.

The IESG may find useful that CMPv2 work may also be hosted in LAMPS (which
revisits CMPv2), ANIMA ( which defines CMPv2 as an alternative to EST) or
IOTOPS.

However, the discussion started in LAMPS and it was suggested ACE would be
more appropriated [1] and the current proposed charter has been circulating
on the lamps, anima, iotops mailing list and no concerns have been
raised. We will however make sure , these related WG are informed of our
progress.

EAP work has been coordinated with EMU. In any case, if the work is being
considered in ACE, we will make sure the corresponding WG will follow the
progress.

[1] https://mailarchive.ietf.org/arch/msg/spasm/uyYCf5sMcxg6xoQFcbe1sPxqVLw/

Yours,
Daniel

"""

The Authentication and Authorization for Constrained Environments (ace) WG
has defined a standardized solution framework for authentication and
authorization to enable authorized access to resources identified by a URI
and hosted on a resource server in constrained environments.

The access to the resource is mediated by an authorization server, which is
not considered to be constrained.

Profiles of this framework for application to security protocols commonly
used in constrained environments, including CoAP+DTLS and CoAP+OSCORE, have
also been standardized.  The Working Group is charged with maintenance of
the framework and existing profiles thereof, and may undertake work to
specify profiles of the framework for additional secure communications
protocols and for additional support services providing authorized access
to crypto keys (that are not necessarily limited to constrained endpoints,
though the focus remains on deployment in ecosystems with a substantial
portion of constrained devices).

In addition to the ongoing maintenance work, the Working Group will extend
the framework as needed for applicability to group communications, with
initial focus on (D)TLS and (Group) OSCORE as the underlying group
communication security protocols. The Working Group will standardize
procedures for requesting and distributing group keying material using the
ACE framework as well as appropriated management interfaces.

The Working Group will standardize a format for expressing authorization
information for a given authenticated principal as received from an
authorization manager.

The Working Group will examine how to use Constrained Application Protocol
(CoAP) as a transport medium for certificate enrollment protocols, such as
EST and CMPv2, as well as a transport for authentication protocols such as
EAP, and standardize as needed.
"""

Yours,
Daniel

On Sat, Dec 12, 2020 at 12:37 PM Dan Garcia Carrillo <[email-masked]>
wrote:

> Hi Mališa,
>
>
> El 11/12/2020 a las 19:45, Mališa Vučinić escribió:
>
> Hi Dan,
>
>
>
> Thanks for the clarification regarding minimal-security. The points that
> you mention below, e.g. flexible authentication or the fresh generation of
> the PSK, were never in the design scope of our work.
>
>
>
> While I fail to understand what exactly do you plan on using EAP-over-CoAP
> for, I do not object on this work being done in ACE if you are willing to
> spend cycles on it. I do have reservations on the lightweight aspect of
> this, however, considering that the sequence diagram that you depict in
> Fig. 2 in draft-marin-ace-wg-coap-eap-06 spans 3 pages and consumes 2 round
> trips just to get things started! Surely, we can do better?
>
> Yes, we will submit an updated version of the draft.
>
> Best Regards,
>
> Dan
>
>
>
> Mališa
>
>
>
> *From: *Dan Garcia Carrillo <[email-masked]> <[email-masked]>
> *Date: *Friday 11 December 2020 at 18:41
> *To: *Mališa Vučinić <[email-masked]>, Michael Richardson
> <[email-masked]> <[email-masked]>, EMU WG <[email-masked]>
> <[email-masked]>, "[email-masked] WG ([email-masked])"
> <[email-masked]([email-masked])> <[email-masked]> <[email-masked]>,
> "[email-masked]" <[email-masked]> <[email-masked]> <[email-masked]>
> *Cc: *<[email-masked]> <[email-masked]>
> *Subject: *Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?)
>
>
>
> Hi Mališa,
>
> My intention was not to turn this conversation into a criticism of your
> work. “deficiencies” was not the most appropriate word.
>
> What we had in mind was a way of providing authentication  to the variety
> of IoT devices with different capabilities, limitations or different types
> of supported credentials. A way of doing that is to provide different
> authentication methods. Since in IoT there are different technologies we
> looked for a link-layer independent solution. Additionally, since some
> technologies are very constrained, we needed a very constrained protocol to
> carry out the process.
>
> EAP provides flexible authentication, and it has EAP Key Management
> Framework which is well specified and working for many years, from which
> you can generate generate a fresh pre-shared key (MSK) dynamically. This is
> even possible if you do not want to interact with AAA infrastructures
> running EAP in standalone mode.  Having said this, another thing that we
> looked into was to give support to large scale deployments. We can ease
> this process with EAP and its interaction with a AAA infrastructure, which
> gains relevance in Industrial IoT and 5G.
>
> All these characteristics can be provided by the use of EAP, if we of
> course have a lightweight EAP lower layer to transport EAP from the IoT
> device. Then we considered the usage of CoAP as EAP lower-layer.
>
> In this sense, we saw minimal security did not fit our view (no potential
> interaction with AAA , flexible authentication, fresh generation of PSK).
> In fact,  the provisioning of the PSK was out of scope.
>
> At some level, we could even consider the work complementary. EAP over
> CoAP could be a way of providing the PSK for the work of minimal security.
>
>
> Best Regards,
> Dan.
>
> El 10/12/2020 a las 18:43, Mališa Vučinić escribió:
>
> Hi Dan,
>
>
>
> Could you be more specific on the point below, what deficiencies do you
> have in mind?
>
>
>
> Mališa
>
>
>
> *From: *core <[email-masked]> <[email-masked]> on behalf of
> Dan Garcia <[email-masked]> <[email-masked]>
> *Date: *Thursday 10 December 2020 at 10:06
> *To: *Michael Richardson <[email-masked]> <[email-masked]>,
> EMU WG <[email-masked]> <[email-masked]>, "[email-masked] WG ([email-masked])"
> <[email-masked]([email-masked])> <[email-masked]> <[email-masked]>,
> "[email-masked]" <[email-masked]> <[email-masked]> <[email-masked]>
> *Subject: *Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?)
>
>
>
> As you comment , draft-ietf-6tisch-minimal-security - offers minimal
> security and has several deficiencies that can be solved by using EAP and
> AAA infrastructures.
>
> -->
>
> -->_______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

-- 
Daniel Migault
Ericsson

-- 
Daniel Migault
Ericsson