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

Daniel Migault <mglt.ietf@gmail.com> Fri, 05 March 2021 21:23 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 E38AC3A0E2D; Fri, 5 Mar 2021 13:23:09 -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, 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 9ueJ0pbjcTWt; Fri, 5 Mar 2021 13:23:07 -0800 (PST)
Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 C64D13A0E30; Fri, 5 Mar 2021 13:23:06 -0800 (PST)
Received: by mail-qk1-x72a.google.com with SMTP id g185so3481906qkf.6; Fri, 05 Mar 2021 13:23:06 -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=CEg3hEup5FoUCJZc7q3KX9V/yXj82vJnt6ah0KBYuzY=; b=dIuBvL6KMm+b3DBbK7Umb1qV/dXVfdsPl5Lz2WyjydA1HFyxLEvHSQU47Kau5k4rft WLE54/W00/LOu2/qwTXU87wt1yJulpUL6ko1R4mz0OOyC6rtqeeqt1qsrE4zFmhgUih0 KuSm+bau69OCO+xWxw8O1mmJ9zXYbuh497DNI2B02pnEj2ARF+qDCyebYAxjOAXBePzL DL4qWIg4fsXvMIVd36jTzqDSvfTmG7xu4fGBLbsekekBxaeIFXYJmIc6FekstjPpVYT+ VzAAYioIPH+7k2DecudwQLAp/NU4tI+1MBCZhhb5SEezAfbq4Qgv6QPZesTcQxMFUvgp To4A==
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=CEg3hEup5FoUCJZc7q3KX9V/yXj82vJnt6ah0KBYuzY=; b=N20XXS2e0URqCzDaabA/ISVL+L1twbi5QIofKvfAQpgm22bpSUs0MWvxcU7UTjMSuY /1JYEwQQOdRSrwOAdlnUEVc0n8JoQymmCOPG2zJWXJWiQwmQb5qstZRKGcJh8Q2gdj98 D23IJXj4F5XOU3O2nyrFhvbZeigsmObUHZDTpFxpx3D8+X/ee90yKa5fJ+3NHC2oiDz8 qYMUYR5x+nBO+ho+Jc/WGZ4/2/3m0SL1DCorWk8/M2kfu7fHqxCXRbnjXp8zhfTNm7LB x4ArMmHI7GgOuNwPzL+qBNN5jAz5NBbNo7V2YCp90z/n++YNmIlGEUdmY/VWo97OG951 LdaA==
X-Gm-Message-State: AOAM532E0yrLx3+tSMGa+wqyUmDtrJJw+9DP8QR/IuZwbJm1WOfTFRmB 84wEGPmHXMTOz1gtWj2lfHHsG3HY3G16jBv62eg=
X-Google-Smtp-Source: ABdhPJwwWRIOINhe3qO9e5NfB3D287nTr2wqkB5pH0r9e1IjLrPToN5xrfUZhogcaUgOqtTBxoQm/AtxQQed4OJs54Q=
X-Received: by 2002:a05:620a:15d4:: with SMTP id o20mr11023901qkm.81.1614979383948; Fri, 05 Mar 2021 13:23:03 -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>
In-Reply-To: <0C8BC190-95F3-4A88-B683-09E22EBD54AB@ericsson.com>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Fri, 5 Mar 2021 16:22:53 -0500
Message-ID: <CADZyTkmyRpQWYsM+-XeOmKf=dUvjP1Oe2WdEN69hVbhi_-rLuQ@mail.gmail.com>
To: Francesca Palombini <francesca.palombini@ericsson.com>
Cc: =?UTF-8?Q?G=C3=B6ran_Selander?= <goran.selander@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="0000000000007ffa5a05bcd0b050"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/MQvSOxJ3y4u3nJ6nQ2tb2TPDAxI>
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: Fri, 05 Mar 2021 21:23:10 -0000

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