Re: [Ace] OSCORE Profile status update and way forward

Daniel Migault <mglt.ietf@gmail.com> Fri, 23 October 2020 23:58 UTC

Return-Path: <mglt.ietf@gmail.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333EA3A0ADD; Fri, 23 Oct 2020 16:58:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kXsKSd_PLwl; Fri, 23 Oct 2020 16:58:21 -0700 (PDT)
Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D81D3A0989; Fri, 23 Oct 2020 16:58:21 -0700 (PDT)
Received: by mail-vs1-xe2c.google.com with SMTP id b129so1818509vsb.1; Fri, 23 Oct 2020 16:58:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Gdl7bdo1qBZmTwHjEn1LarHxZTgOLtR76Z95sXsZ1Fk=; b=mmS0KPDytmQ426YhbBk498ysL/Rwd51FQoZjqhaQop0M9ppYky04o3io85ZJDDzDyq LO3FFhyOZVPNv69cX7ZC8UT7QpJzRG5RYeslmv5L1wGEn0IVSWPhfsFQ8/i8JBPdm5WQ zxqeWxDYDcWEV4t+OIaDC4uyC/QSRM90kbQSpplN/jp883GAxwgRlYOxeIYQUsivi38y Ov9kv+W33PVLxI9uj0lOkov8UUOr1N9ih/Uu8WABVGxfHVIVfP0CWwRuxpUVwV92GyvN GQfa6THToxdqCfQFqrfaNnZsA+psGp/v69ZFAcLsQKKcJljxL3og5UFuDTFt0khpEIHb Kk3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Gdl7bdo1qBZmTwHjEn1LarHxZTgOLtR76Z95sXsZ1Fk=; b=k+zJ+had3HRH3IU4XWl+Sy5GGjLD3upYoJjm2Gy3KYeGA/2qRaz5bIiyDG7icuEowd Lg/Q69RxnSRvLl1m9oXz6C86z8OXzEeLS8T/a9tqO6z/H+h/p24VVllN8BpOUUsZOzH9 ISNUAoWE2wj5ygfyWAGYoQ9J9vyHh7nAZvZVpA84fOBcWJU30K5P40MsSawblK76+Mpa VHAZXflla8kLC+iCCyYXQpW0oxFW91KNv9wvEsoMVyBd7EaGvbu5jbGDGhwDlUTvM1hc PWnRVE5dPRVYBV2i6FaJ4x7UWPqQZkdGOYjbgdLzYgg+zhG4H6Kh+X/g6d8HnCaMatkL /0/A==
X-Gm-Message-State: AOAM531t31pk5B1MCLIjNnFZspMWS/dpquJ310vfzIwFEN9/SUORJ67M JWydOCGJyfBsozNj/ZnYd8LimA6tMJuSsIPhe2Ds4E2v46k=
X-Google-Smtp-Source: ABdhPJwq4o1NUv8K9W5hct/SRDJPgqdmSnevq5yUhqfOsTUs1GIBVQ6JCOyWtrIluTOvMRFE0FoB0t6BBniFiG0Bm0A=
X-Received: by 2002:a67:1e02:: with SMTP id e2mr4886937vse.40.1603497500188; Fri, 23 Oct 2020 16:58:20 -0700 (PDT)
MIME-Version: 1.0
References: <2D021116-D240-4EE8-9223-83E9F9D4A4EB@ericsson.com> <20201009154454.GA1050533@hephaistos.amsuess.com> <809D1CE3-A75E-4871-9E1D-48260E787762@ericsson.com> <E3D11940-7AD4-4F3F-B24A-6DE5CA9FD5A9@ericsson.com> <CADZyTkm_QRd4mvV2VfcY813cJq9Tvp=PJEgJqyyp7ucvhCKUyQ@mail.gmail.com>
In-Reply-To: <CADZyTkm_QRd4mvV2VfcY813cJq9Tvp=PJEgJqyyp7ucvhCKUyQ@mail.gmail.com>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Fri, 23 Oct 2020 19:58:09 -0400
Message-ID: <CADZyTk=UT_6W7tXXcb78MRX6JWDtr6VYfXdrFb_RPGGWmHR+SA@mail.gmail.com>
To: Francesca Palombini <francesca.palombini=40ericsson.com@dmarc.ietf.org>
Cc: =?UTF-8?Q?Christian_Ams=C3=BCss?= <christian@amsuess.com>, "draft-ietf-ace-oscore-profile@ietf.org" <draft-ietf-ace-oscore-profile@ietf.org>, Ace Wg <ace@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e5a1b205b25f5aa9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/mcVOamNA20Y7viXksn3CsnrqAnE>
Subject: Re: [Ace] OSCORE Profile status update and way forward
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Oct 2020 23:58:23 -0000

I am not hearing anyone opposing the proposed way to move forward. Once we
will have the update from Francesca, we will be able to start a WGLC. On
the other hand, we will need reviews to move the document forward, so
please remain committed for the last miles!

Yours,
Daniel

On Mon, Oct 19, 2020 at 4:45 PM Daniel Migault <mglt.ietf@gmail.com> wrote:

> Thanks Francesca for the reply. Other members of the WG, if you have an
> opinion, please let the WG know asap. We set October 20 to get comments on
> which path to take.
>
> Yours,
> Daniel
>
> On Mon, Oct 19, 2020 at 11:52 AM Francesca Palombini <francesca.palombini=
> 40ericsson.com@dmarc.ietf.org> wrote:
>
>> Hi Christian, Daniel,
>>
>> Daniel: I agree that what you describe is the best way forward. Once the
>> PR regarding the negotiation of Ids is merged, I can only see a minor
>> addition to the draft, to clarify what Christian has brought up. By the end
>> of this week we should have Christian's comment implemented as well. After
>> that, we're ready for another round of reviews, and I think a WGLC is
>> warranted.
>>
>> Christian, let us know if there is anything else except some more
>> considerations covering what you are saying. Göran summarized it well, but
>> basically no, there is no particular benefit. The sentence was added as the
>> response from a review comment, but it seems like a good idea to add more
>> context to it.
>>
>> Thanks,
>> Francesca
>>
>> On 15/10/2020, 20:01, "Göran Selander" <goran.selander@ericsson.com>
>> wrote:
>>
>>     Hi Christian,
>>
>>     The purpose of the update was to clarify that Appendix B.2 of RFC
>> 8613 could be used in conjunction with the ACE OSCORE profile. But as you
>> point out, the use of B.2 would need to be understood between the client
>> and server beforehand. There are slight differences: With B.2 there is no
>> need to transport the access token again. And B.2 can be triggered by the
>> (resource) server, if it understands that it does not have the right
>> context (which can happen even if there is no ID context in the request).
>> Just using the ACE OSCORE profile, the client would need to understand that
>> the context is lost and run the protocol again. So, there is a difference
>> but essentially the same functionality can be obtained.
>>
>>     Would it be sufficient to clarify the differences as above to address
>> your comment?
>>
>>     Thanks,
>>     Göran
>>
>>
>>     On 2020-10-09, 17:45, "Christian Amsüss" <christian@amsuess.com>
>> wrote:
>>
>>         Hello Francesca, hello ACE group,
>>
>>         On Mon, Sep 21, 2020 at 01:48:33PM +0000, Francesca Palombini
>> wrote:
>>         > - clarified that Appendix B.2 of OSCORE can be used with this
>> profile,
>>         > and what implementers need to think about if they do.
>>
>>         I understand B.2 to be something that the involved parties need
>> to agree
>>         on beforehand; after all, the ID context may be something the
>> server
>>         relies on (at least for the initial attempt) to find the right
>> key,
>>         especially when multiple AS are involved. (For example, the RS
>> could
>>         have an agreement that the AS may issue any KID as long as they
>> use a
>>         particular ID context). If the server expects B.2 to happen
>> (which, as
>>         it is put now, it can as long as it supports it in general), it
>> needs to
>>         shard its KID space for the ASs it uses. (Generally, B.2 is
>> mutually
>>         exclusive with ID contexts's use of namespacing KIDs).
>>
>>         Is the expectation that clients that do not anticipate B.2 by the
>> time
>>         they are configured with their AS just don't offer B.2 to their
>> peers?
>>
>>         Given B.2 is in its current form client-initiated only (AFAIR we
>> had
>>         versions where ID1 could be empty in draft versions, but
>> currently it
>>         reads as client-initialized), does B.2 have any benefits for
>> ACE-OSCORE
>>         clients? After all, they could just as well post the token with a
>> new
>>         nonce1 to the same effect.
>>
>>         Kind Regards
>>         Christian
>>
>>         --
>>         To use raw power is to make yourself infinitely vulnerable to
>> greater powers.
>>           -- Bene Gesserit axiom
>>
>>
>> _______________________________________________
>> Ace mailing list
>> Ace@ietf.org
>> https://www.ietf.org/mailman/listinfo/ace
>>
>
>
> --
> Daniel Migault
> Ericsson
>


-- 
Daniel Migault
Ericsson