Subject: [Ace] Agenda for next monday

From: Jim Schaad <[email-masked]>
Date: Tue, 1 Sep 2020 09:11:58 -0700

The chairs need to start building the agenda for next Monday.  If you want
to be on it then you need to let us know.  We are more interested in seeing
items which need to have decisions made than summaries of what has been
done.

Topic
Presenter
Expected Time

Jim

---

From: Francesca Palombini <[email-masked]>
Date: Wed, 2 Sep 2020 14:48:33 +0000

The OSCORE profile needs around 10 minutes to agree on the IANA registration of new parameters. I'll be presenting (but don't need slides).

Francesca

On 01/09/2020, 18:12, "Ace on behalf of Jim Schaad" <[email-masked] on behalf of [email-masked]> wrote:

    Topic
    Presenter
    Expected Time

    Jim

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

---

From: Daniel Migault <[email-masked]>
Date: Fri, 4 Sep 2020 22:34:43 -0400

Hi,

Here is the current agenda with all necessary links [1]. We still have some
available slots.

Yours,
Jim and Daniel

[1] https://codimd.ietf.org/notes-ietf-interim-2020-ace-10-ace

On Wed, Sep 2, 2020 at 10:48 AM Francesca Palombini <francesca.palombini=
[email-masked]> wrote:

> The OSCORE profile needs around 10 minutes to agree on the IANA
> registration of new parameters. I'll be presenting (but don't need slides).
>
> Francesca
>
> On 01/09/2020, 18:12, "Ace on behalf of Jim Schaad" <[email-masked]
> on behalf of [email-masked]> wrote:
>

-- 
Daniel Migault
Ericsson

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Sep 2020 21:04:03 -0400

I'm sorry that I missed today's meeting.
I guess this wasn't on the agenda in the end?

Göran Selander <[email-masked]> wrote:
    > But you are right that the draft is not just a new ACE profile. The
    > voucher concept fits into ANIMA, but is carried as an ACE access
    > token. It also makes use of the auxiliary data and other elements of
    > EDHOC. But neither ANIMA nor LAKE seems to be the right working
    > groups. ANIMA is not using the ACE framework, and LAKE is for the
    > nearest future only concerned with the basic AKE.

ANIMA BRSKI is not using the ACE framework, but that's because I don't think
it was clear when we started the work that vouchers were semantically similar
to JWT/CWT.  Well, I tried to move things that way, but it was just too soon.

When we started, I thought that the thing that the AS (W) returns to V is an 
RFC8366 semantic voucher (encoded to CBOR a la draft-ietf-anima-constrained-voucher).
However, in the document it has taken on it's own life.
I think that we tried to make it close to an ACE token.

This is where the connection comes in.

Jim:
    jim>     I have been sitting this to try and make a decision and figure out
    jim> what my feelings are with this draft.  I did a fast read through the
    jim> document, too fast to actually understand what it is trying to do, and
    jim> I immediately ran into the question of why this document would be part
    jim> of ACE.  It is using the concepts of a voucher, which is not currently
    jim> an ACE concept, as one of the fundamental concepts.  That combined with
    jim> the use of an AKE makes me very wary of this document.  (I have not
    jim> spent enough time embedded in the ECIES and HPKE world to understand
    jim> this well.)

I think that the ECIES and HPKE part is not particularly significant.
There are some links at:
   https://www.sandelman.ca/SSW/ietf/brski-links/

The link:   Generic Animation of BRSKI - Bootstrapping Remote Secure Key
            Infrastructure (ODP) (screencast) (enterprise/IoT screencast)
points to:  https://www.youtube.com/watch?v=Mtbh_GN0Ce4 which is only 5
            minutes long.

I should redo this for ACE-AKE-AUTHZ, aka Ultra-Constrained enrollment.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Göran Selander <[email-masked]>
Date: Wed, 9 Sep 2020 08:40:26 +0000

Hi Michael, and all, 

No, this hasn't been discussed in ACE yet. But since you brought it to the list, we may restart the discussion here.

We have been working on lightweight procedures for an IoT device to join a network. The join process may include a number of components such as authentication, remote attestation, authorization, enrolment of locally significant certificate, etc. Much of current standards are based on doing things in sequence, one thing at a time. This may be a good idea but it introduces some redundancies. One way to reduce overhead is to reuse elements from the authentication protocol in the authorization or certificate enrolment processes. So, instead of passing public keys and signatures multiple times between the same endpoints over constrained links during different phases of the joining procedure, we try to make more use of the authentication protocol while ensuring that the security properties are as expected.

The draft in the subject is looking at third party authorization. It uses the "auxiliary data" extension point of EDHOC, and reuses the client ephemeral key/nonce with the authorization server. The actual authorization information is carried in a "voucher" using the ANIMA terminology, but is requested and retrieved as an 8 byte access token using a new ACE profile. This enables mutual authentication and authorization at completion of EDHOC, and with little additional overhead compared to EDHOC.

A certificate enrolment request may in a similar way be included in message 3 (not covered in this draft) since authentication and authorization of responder takes place at reception of message 2. In order for sending back a certificate (or a reference to a certificate) to the initator, a fourth message needs to be added, but the overall join procedure could be completed in two round trips.

The question is if ACE is the right place to discuss this topic.

Göran

On 2020-09-08, 03:04, "Michael Richardson" <[email-masked]> wrote:

    Jim:

    I think that the ECIES and HPKE part is not particularly significant.
    There are some links at:
       https://protect2.fireeye.com/v1/url?k=245f61e6-7affa3a3-245f217d-8692dc8284cb-0438c9725de3a5ae&q=1&e=43232919-eac0-44fe-9b22-4dd1e1e25947&u=https%3A%2F%2Fwww.sandelman.ca%2FSSW%2Fietf%2Fbrski-links%2F

    -- 
    ]               Never tell me the odds!                 | ipv6 mesh networks [
    ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
    ]     [email-masked]  https://protect2.fireeye.com/v1/url?k=d54ae6c7-8bea2482-d54aa65c-8692dc8284cb-93b42ef9756fce01&q=1&e=43232919-eac0-44fe-9b22-4dd1e1e25947&u=http%3A%2F%2Fwww.sandelman.ca%2F        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Sep 2020 11:32:06 -0400

Göran Selander wrote:
    > We have been working on lightweight procedures for an IoT device to
    > join a network. The join process may include a number of components
    > such as authentication, remote attestation, authorization, enrolment of
    > locally significant certificate, etc. Much of current standards are
    > based on doing things in sequence, one thing at a time. This may be a
    > good idea but it introduces some redundancies. One way to reduce
    > overhead is to reuse elements from the authentication protocol in the
    > authorization or certificate enrolment processes. So, instead of
    > passing public keys and signatures multiple times between the same
    > endpoints over constrained links during different phases of the joining
    > procedure, we try to make more use of the authentication protocol while
    > ensuring that the security properties are as expected.

...

    >     The link: Generic Animation of BRSKI - Bootstrapping Remote Secure
    > Key Infrastructure (ODP) (screencast) (enterprise/IoT screencast)

    >     I should redo this for ACE-AKE-AUTHZ, aka Ultra-Constrained

Thinking a day later, I think that presenting a well animated view of
ACE-AKE-AUTHZ at an ACE virtual interim and listening to feedback about what
fits into ACE and what does not, would help out small design team
clarify/debug our message, should we go to secdispatch, or whatever.
[Jim: does that answer your question better?]
I mean, we could also just hold our own virtual meeting too :-)

I am personally more interested in writing code than wrangling documents from
WG to WG in the next ~4 months.  I think that some other things in the IETF
will sort themselves out in that timeframe, and a path forward will become
clear.
In the meantime, explaining things to others helps me get it right.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Jim Schaad <[email-masked]>
Date: Wed, 9 Sep 2020 15:40:29 -0700

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Michael Richardson
Sent: Wednesday, September 9, 2020 8:32 AM
To: [email-masked]
Subject: Re: [Ace] bringing draft-selander-ace-ake-authz to ACE?

...

    >     I should redo this for ACE-AKE-AUTHZ, aka Ultra-Constrained

Thinking a day later, I think that presenting a well animated view of ACE-AKE-AUTHZ at an ACE virtual interim and listening to feedback about what fits into ACE and what does not, would help out small design team clarify/debug our message, should we go to secdispatch, or whatever.
[Jim: does that answer your question better?] I mean, we could also just hold our own virtual meeting too :-)

[JLS] Yes this does a much better job of telling me what you are trying accomplishment.  Having an idea of what the document is trying to do and what the problem that you are trying to solve makes it easier to slot in time for this.   I am more than willing to have ACE sponsor a different time slot if you want to have a known amount of time up front for the presentation.  I am willing to schedule it into the next meeting.  But you never know how much time is going to get consumed dealing with adopted documents.  

[JLS] I still need to do a deep read on this document.

Jim

I am personally more interested in writing code than wrangling documents from WG to WG in the next ~4 months.  I think that some other things in the IETF will sort themselves out in that timeframe, and a path forward will become clear.
In the meantime, explaining things to others helps me get it right.