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

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