Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14

Daniel Migault <mglt.ietf@gmail.com> Mon, 08 March 2021 12:14 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 D9BB73A0D43; Mon, 8 Mar 2021 04:14:14 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 dUE3vxnEJs-5; Mon, 8 Mar 2021 04:14:11 -0800 (PST)
Received: from mail-vk1-xa30.google.com (mail-vk1-xa30.google.com [IPv6:2607:f8b0:4864:20::a30]) (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 92FDB3A0D01; Mon, 8 Mar 2021 04:14:11 -0800 (PST)
Received: by mail-vk1-xa30.google.com with SMTP id j188so2070718vke.13; Mon, 08 Mar 2021 04:14:11 -0800 (PST)
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=oaIA2fKjHZwy7aL/I18CBEIpP/3PUNN03BpYlNyo5MM=; b=hSxMxI7FMmSB+skGAEL+qgeuQvyXbYNsElS1NV9auyw3ncqjOy1EMY7S6GI1mSLEoc Jd/v7aaTBm+EAbjuPymrNCpQE8Yw/PnNEziszmrtV86rqiozXENvIvAmnWqfhUnmnHX8 nUf3Rls71NgJYZratF/sG1nupdtYBy2bmiF3e/chAuv0mlGhBMH+s8/WOQTPp3nLylDY dqcC6zYoujQw3pDiTjf7FuiOrwG7kRuF/iAzWsnOI/o3YnlF7wIdda1Ii+O6yoMT7LGZ u7ymeB870x7eKUnqG94MAw82ArEzNax6gs2vZIW+sELa0aeCyqWu2lEUFpMzNo8+SX9X jB/g==
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=oaIA2fKjHZwy7aL/I18CBEIpP/3PUNN03BpYlNyo5MM=; b=JPD4+SiVCSEbEhTK3Uc+YKQ3T3Y8prZAvlcuOE0L4jNlpAo+KWWec4JkRQ7G193bNi WrYOF8v95Ek5MokMj8TDSM5+A+tJfDYbaOwzmcqVRMehV11utH7O+KvwIukBi9YY8QIb WMcCLRunOvqyi+8wa4If/D48oDt8iTeD5VoCOQKKrAfYY161ytKpVY3kkeaaYbaKJZT0 qi2fG/cvqHjRTUqSvvvucsvcrI2E2ktgWdH9lVw4kh9vCBxWRmi7hTQ8QVIseJb9mAlO gqE4AEA4TcaKz4VNVnganWZ9gZsuIXoP3SEATi4JPF+f3TuEALPGs/aHl+1Iakj2VyBZ 7Dvw==
X-Gm-Message-State: AOAM531njRTHFbp4xgoDxWwMBN22cnwJJE7nD/RqblgjeQiPli8axAYX fA9nPippmLPjhbHrAgUYyiwvwfhM6NlFl50Zuqw=
X-Google-Smtp-Source: ABdhPJwaSImf5qHKIBA7pJokAGt/S/55REvmn6UucPG/EP67TOmJTC/J/v5F8eGQpcy0j7VnB5a0uQtrEjNMI3VDIqk=
X-Received: by 2002:a1f:cd42:: with SMTP id d63mr12780971vkg.19.1615205649899; Mon, 08 Mar 2021 04:14:09 -0800 (PST)
MIME-Version: 1.0
References: <871rdqihww.fsf@wangari> <FD569111-85F8-40A2-8C97-764977309B87@ericsson.com> <CADZyTk=HB26o=mUpUdbYEhfhrGZar+oe28c5PZ2_j-vKYVA6xg@mail.gmail.com> <c6d42d18-f1f3-ec00-fff9-3540fa222d23@tzi.de> <9911269D-AA7F-458C-AA1A-2D59A79C5A00@ericsson.com> <CADZyTkn=3GigtTiihQX0ORYyO0dV0qCfVMtTn37vbsqJuQUJxw@mail.gmail.com> <026242c2-2c6a-485b-cb51-34b2b2d70975@tzi.de> <DM6PR15MB23796DF01885DC7F86C15583E3879@DM6PR15MB2379.namprd15.prod.outlook.com> <6b5368a6-b8ba-81eb-0c10-6a052fcbad67@tzi.de> <DM6PR15MB23798EE51BDED9BB7D0438E3E3869@DM6PR15MB2379.namprd15.prod.outlook.com> <2C5A1AA5-6124-407B-A342-AA367CB6D536@tislabs.com> <DM6PR15MB23799382A92C9B2074B1BF42E3859@DM6PR15MB2379.namprd15.prod.outlook.com> <F6B1D3C5-DE79-42B4-8CEA-620C86EABF4B@ericsson.com> <CADZyTk=y7Zf3Atvt7d5c17KEbnc5CESoOyBsa0TgpMchX4FcPQ@mail.gmail.com> <CADZyTk=gc8ybr5+wQhN0P_Vyz2P+g6TtwWcAGYGbofeMeq0cjQ@mail.gmail.com> <87v9a94m60.fsf@wangari> <CADZyTkkf3qj=ZXvH1QYe1Kg=wUxMug2y6e=9-b31mkUAeC4Qrw@mail.gmail.com> <CADZyTknPLSvfixtM1JTXnKia6ooSwWssV-zAhWi-fPoBrwMBdA@mail.gmail.com> <1932F1CD-7296-4266-B234-1FD30A019522@ericsson.com> <CADZyTknSmX8tqhce7bfUvtm7S11GPru5Swuxx7fLkUTr-yaPqg@mail.gmail.com> <0C8BC190-95F3-4A88-B683-09E22EBD54AB@ericsson.com> <CADZyTkmyRpQWYsM+-XeOmKf=dUvjP1Oe2WdEN69hVbhi_-rLuQ@mail.gmail.com> <CDE70DE7-EFBF-44C6-A350-DE02B5587635@ericsson.com>
In-Reply-To: <CDE70DE7-EFBF-44C6-A350-DE02B5587635@ericsson.com>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Mon, 8 Mar 2021 07:13:58 -0500
Message-ID: <CADZyTkm2kcV0DV3NZ42cUWDMN_6Y+teA9MdEnRw9S4P0qSL1nQ@mail.gmail.com>
To: =?UTF-8?Q?G=C3=B6ran_Selander?= <goran.selander@ericsson.com>
Cc: Francesca Palombini <francesca.palombini@ericsson.com>, Stefanie Gerdes <gerdes@tzi.de>, Olaf Bergmann <bergmann@tzi.org>, Russ Mundy <mundy@tislabs.com>, "draft-ietf-ace-oauth-authz@ietf.org" <draft-ietf-ace-oauth-authz@ietf.org>, Loganaden Velvindron <loganaden@gmail.com>, Ace Wg <ace@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000000629405bd055f34"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/cwp9GBfycWqPtKuNqyUT_ZmLMy8>
Subject: Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14
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: Mon, 08 Mar 2021 12:14:15 -0000

Thanks Goran, It looks good to me. I believe that a new version can be
published to reflect the changes and close this issue.

Yours,
Daniel

On Mon, Mar 8, 2021 at 2:35 AM Göran Selander <goran.selander@ericsson.com>
wrote:

> Hi Daniel,
>
> Here is a proposed changed to the last sentence:
>
>     Section 5:
>     OLD
>         "Profiles MUST specify a communication security protocol that
> provides the features required above."
>
>       NEW
>         "Profiles MUST specify a communication security protocol between
> client and RS that provides the features required above. Profiles MUST
> specify a communication security protocol RECOMMENDED to be used between
> client and AS that provides the features required above. Profiles MUST
> specify for introspection a communication security protocol RECOMMENDED to
> be used between RS and AS that provides the features required above. These
> recommendations enable interoperability between different implementations
> without the need to define a new profile if the communication between C and
> AS, or between RS and AS, is protected with a different security protocol
> complying with the security requirements above."
>
>
> Göran
>
>
> On 2021-03-05, 22:23, "Daniel Migault" <mglt.ietf@gmail.com> wrote:
>
>     Thanks. "C/RS and AS" may not be very clear as it seems - at least to
> me -  to include the communication between the client and the RS. It seems
> to me that  only communications between Client and AS as well as between AS
> and RS are in scope. If that is correct, I would suggest expanding "C/RS
> and AS" accordingly.
>     Yours,
>     Daniel
>
>
>     On Fri, Mar 5, 2021 at 11:03 AM Francesca Palombini <
> francesca.palombini@ericsson.com> wrote:
>
>
>     Hi,
>
>     (Adding back the ace ml that was dropped at some point)
>
>     Here is a proposal for the paragraph in Section 5 with a different
> last sentence to hopefully clarify the need for recommendations but not
> mandate only one sec protocol per profile:
>
>     Section 5:
>     OLD
>         "Profiles MUST specify a communication security protocol that
> provides the features required above."
>
>       NEW
>         "Profiles MUST specify a communication security protocol between
> client and RS that provides the features required above. Profiles MUST
> specify a communication security protocol RECOMMENDED to be used between
> client and AS that provides the features required above. Profiles MUST
> specify for introspection a communication security protocol RECOMMENDED to
> be used between RS and AS that provides the features required above. These
> recommendations enable interoperability between different implementations,
> without the need to define a new profile if the communication between C/RS
> and AS is protected with a different security protocol complying with the
> security requirements above."
>
>
>     The proposal for the other section looks good to me.
>     Francesca
>
>     From: Daniel Migault <mglt.ietf@gmail.com>
>     Date: Thursday, 4 March 2021 at 17:49
>     To: Göran Selander <goran.selander@ericsson.com>
>     Cc: Stefanie Gerdes <gerdes@tzi.de>de>, Olaf Bergmann <bergmann@tzi.org>rg>,
> Francesca Palombini <francesca.palombini@ericsson.com>om>, Russ Mundy <
> mundy@tislabs.com>gt;, "draft-ietf-ace-oauth-authz@ietf.org" <
> draft-ietf-ace-oauth-authz@ietf.org>gt;, Loganaden Velvindron <
> loganaden@gmail.com>
>     Subject: Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14
>
>
>
>     HI Goran,
>
>
>
>     sure any wordsmithing / alternative are fine to me. For the second
> alternative the repetition of "with" may sound to me a bit strange.
>
>
>     Unless anyone objects that would be greatly appreciate to have a new
> version submitted. Thanks!
>
>
>
>     Yours,
>     Daniel
>
>
>
>
>
>
>
>     On Thu, Mar 4, 2021 at 11:12 AM Göran Selander <
> goran.selander@ericsson.com> wrote:
>
>
>     Hi Daniel,
>
>     The proposal coincides with the text I proposed Feb 22 except for one
> sentence:
>
>     "Such recommendations are expected, among others, to guarantee
> independent implementations interoperate."
>
>     This sentence does not read well to me, perhaps we can change it? For
> example:
>
>     "These recommendations are expected to enable interoperability between
> independent implementations."
>
>      . . . or even add the reason why it is only a recommendation:
>
>     "These recommendations are expected to enable interoperability between
> independent implementations, without preventing this profile to be used
> with other security protocols with the AS complying with the security
> requirements."
>
>     I can make the changes and submit a new version of
> draft-ietf-ace-oauth-authz in the beginning of next week when ID submission
> has reopened.
>
>     Regards
>     Göran
>
>
>
>     On 2021-03-04, 15:54, "Daniel Migault" <mglt.ietf@gmail.com> wrote:
>
>
>         Hi all,
>         I know everyone is very busy by now, but I am wondering if you
> could provide your input so that we can think of closing this issue before
> the IETF 110 - or at least as soon as possible. Our initial milestones were
> to send these doc in February ;-)
>
>         Yours,
>         Logan and Daniel
>         ---------- Forwarded message ---------
>         From: Daniel Migault <mglt.ietf@gmail.com>
>         Date: Tue, Mar 2, 2021 at 11:09 PM
>         Subject: Re: [Ace] secdir review of
> draft-ietf-ace-dtls-authorize-14
>         To: Olaf Bergmann <bergmann@tzi.org>
>         Cc: Göran Selander <goran.selander@ericsson.com>om>, Olaf Bergmann <
> bergmann@tzi.org>gt;, Russ Mundy <mundy@tislabs.com>om>, ace@ietf.org <
> ace@ietf.org>gt;, Stefanie Gerdes <gerdes@tzi.de>de>, Francesca Palombini <
> francesca.palombini@ericsson.com>gt;, Daniel Migault <daniel.migault=
> 40ericsson.com@dmarc.ietf.org>
>
>
>
>         Thanks for the feedbacks Olaf. So I understand why we need such
> flexibility on the client side. The main reason seems that the
> communication with the AS is seen as bootstrapping the communication
> between the client and the RS and as such we would like to keep them as
> independent as possible.
>         I see interoperability being achieved when a) client, RS, and AS
> implemented by independent vendors and b) all three follow the framework
> and the given profile is sufficient to make them work together. Currently
> the client - RS communication is well defined, but the client AS
> communication is left to a RECOMMENDATION.
>
>         RFC2119 defines RECOMMEND as follows:
>         SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>            may exist valid reasons in particular circumstances to ignore a
>            particular item, but the full implications must be understood
> and
>            carefully weighed before choosing a different course.
>         The question becomes how RECOMMENDED is sufficient or not.
>
>
>
>
>         It seems to me the definition above makes it clear that the
> recommended protocol is expected to be supported, and AS or clients that
> are independently developed are expected to support the recommended
> protocol. To ensure the implementers are well aware of the consequences of
> the implication we could clarify this explicitly. Of course this does not
> provide a formal proof for interoperability, but this seems acceptable in
> the scope of a framework.
>
>         From the latest suggestion, I would propose the following changes,
> - that I expect will reach consensus. Please let us know by Friday  March 5
> if you agree or disagree with the proposed changes.
>
>
>          Section 5:
>         OLD
>         "Profiles MUST specify a communication security protocol that
> provides the features required above."
>
>         NEW
>         "Profiles MUST specify a communication security protocol between
> client and RS that provides the features required above. Profiles MUST
> specify a communication security protocol RECOMMENDED to be used between
> client and AS that provides the features required above. Profiles MUST
> specify for introspection a communication security protocol RECOMMENDED to
> be used between RS and AS that provides the features required above. Such
> recommendations are expected, among others, to guarantee independent
> implementations interoperate."
>
>         Section 6.2:
>         OLD
>           "Profiles MUST specify how communication security according
>            to the requirements in Section 5 is provided."
>         NEW
>         "The requirements for communication security of profiles are
> specified
>         in Section 5."
>
>
>         Yours,
>         Daniel
>
>
>
>
>
>
>         On Tue, Mar 2, 2021 at 10:20 AM Olaf Bergmann <bergmann@tzi.org>
> wrote:
>
>
>         Hi Daniel,
>
>         On 2021-03-02, Daniel Migault <mglt.ietf@gmail.com> wrote:
>
>         > This is just a follow-up. I would like to be able to close this
> issue
>         > by the end of the week, and so far I have not heard any issues
> for
>         > profile mandating a protocol. On the other hand, not mandating a
>         > specific protocol comes with interoperability issues. So unless
> more
>         > feed back is provided, I am currently leaning toward ensuring
>         > interoperability.
>         >
>         > It  would be good for me to hear from the WG and understand what
> concrete deployment
>         > issues the two statements below would raise:
>         >     * OSCORE profile mandating the AS to support OSCORE and have
> the C <-> AS using
>         > OSCORE.
>         >     * DTLS profile mandating the AS to support DTLS and have the
> C <-> AS using DTLS.
>
>         I think the major issue is that a client that implements both
> OSCORE and
>         DTLS cannot just switch from one mechanism to the other because it
> must
>         stick to either one or the other. This also raises the question
> what
>         happens if an AS is contacted by the client via OSCORE but the RS
> only
>         supports DTLS: Is the client allowed to switch from OSCORE to DTLS
> if
>         the AS says so?
>
>         Another aspect is that we would need to add another specification
> if a
>         client implementing the DTLS profile wants to contact the AS via
> TLS. As
>         CoAP over TLS is well-defined, this would not make any difference
>         regarding the security or the handling in the application, but
> mandating
>         DTLS in the profile would currently preclude the use of TLS.
>
>         Grüße
>         Olaf
>
>
>
>
>
>         --
>         Daniel Migault
>
>         Ericsson
>
>
>
>
>
>         --
>         Daniel Migault
>
>         Ericsson
>
>
>
>
>
>
>
>     --
>     Daniel Migault
>
>     Ericsson
>
>
>
>
>
>
>
>
>
>
>     --
>     Daniel Migault
>
>     Ericsson
>
>

-- 
Daniel Migault
Ericsson