Re: [Ace] bringing draft-selander-ace-ake-authz to ACE?

[Göran Selander <[e-mail]>]

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" <[e-mail]> wrote:


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

    Göran Selander <[e-mail]> 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://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

    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   [
    ]     [e-mail]  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    [