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

Daniel Migault <mglt.ietf@gmail.com> Tue, 02 March 2021 14:27 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 E7DD33A18F4 for <ace@ietfa.amsl.com>; Tue, 2 Mar 2021 06:27:18 -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 ZBflho_pwMOO for <ace@ietfa.amsl.com>; Tue, 2 Mar 2021 06:27:16 -0800 (PST)
Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 DBB863A18F3 for <ace@ietf.org>; Tue, 2 Mar 2021 06:27:15 -0800 (PST)
Received: by mail-vs1-xe2d.google.com with SMTP id o186so10684126vso.1 for <ace@ietf.org>; Tue, 02 Mar 2021 06:27:15 -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=ODSUfOLW0c7q6ET99tFl0GC+alcA7beuCMUeIVld36U=; b=S1tbFLfWYOHRnY1PRvte/eUG3qclfRqLcM9Dz1+yxZ/dBrh05t8aUF+fGR02shi7Cx AUZDrqqAGZsXa4Bre6oTKORWyJwLkC6MS5tCISfnk3upvjYn/M/HuJx6DGuKoOyP3uWq jsZuzP5MUD3EFxEKRP4Lli7aP//6vbspqrLBvCmhOXEqIIvGBP9c7crkSly3hdVGQYjT F5/UhtvsP6tr1pKcquizS8AK3tZdt22yq6RhLWrIgZ/rDu+Bxh9Qs/5VNHBintJMfJiv +up8MxLWVhefcMWwhqIOCygLP4KDqgWYX2LezujBGaA9neATLAppPxhfE7P2CfCceeYj i74A==
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=ODSUfOLW0c7q6ET99tFl0GC+alcA7beuCMUeIVld36U=; b=KNzT1P/NN8B2Vvwak0BwBuvSMMJl9qYuXk35WPnW2Hn2r6WgiDg2v0+J0RnQydebNe j5dtHOgYYHR7GKs8UVXUzmFBIgANEO/6bsJ695uHhgZdq0lAW/wzh8Dw1Zig2XjjU72C m3XK4p/Qo3xGGHb/uDkNBFeL9s/0z/v3lFurPiQOW7GiL9R+XoPz+RFdA7TWvF9uSfZZ cXf8mdrfZQAkXt7haDjxAFFu4lGPSGGgyY92NXohN542caw8PIxSJMF57eojDeyqAQBB VZad/kt1PCcFvJMYEECFDQTsdkkioWqSse6s97cIkdJKb4oUmGMJo8heFa1tcnCoXLrA LGwA==
X-Gm-Message-State: AOAM532uSXIHjk5ll44lmj6MR3NulbbazHsGFDR8qMMvYWnADfY0R/sd mS9Kp5EeLTkQH0lzJ1WppDwQh94SMjBjvfaU9N0=
X-Google-Smtp-Source: ABdhPJwvlsygYBPtTdYHhjpV1XJ7l1IhBTgvazlgKGjJVxvVWiohrj/LspqXQb1BTWmU4VybD0hrP94dAP8bpwz0LdE=
X-Received: by 2002:a67:c903:: with SMTP id w3mr706232vsk.20.1614695234023; Tue, 02 Mar 2021 06:27:14 -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>
In-Reply-To: <CADZyTk=y7Zf3Atvt7d5c17KEbnc5CESoOyBsa0TgpMchX4FcPQ@mail.gmail.com>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Tue, 2 Mar 2021 09:27:02 -0500
Message-ID: <CADZyTk=gc8ybr5+wQhN0P_Vyz2P+g6TtwWcAGYGbofeMeq0cjQ@mail.gmail.com>
To: =?UTF-8?Q?G=C3=B6ran_Selander?= <goran.selander@ericsson.com>
Cc: Daniel Migault <daniel.migault=40ericsson.com@dmarc.ietf.org>, Russ Mundy <mundy@tislabs.com>, Stefanie Gerdes <gerdes@tzi.de>, Francesca Palombini <francesca.palombini@ericsson.com>, Olaf Bergmann <bergmann@tzi.org>, "ace@ietf.org" <ace@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d83a5305bc8e87cd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/89SC4zkES4KqJGVrMqLT7Gm4Ih4>
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: Tue, 02 Mar 2021 14:27:19 -0000

Hi everyone,

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.

Yours,
Daniel

On Mon, Feb 22, 2021 at 10:00 AM Daniel Migault <mglt.ietf@gmail.com> wrote:

> Thanks Gorand,
>
> I think the text goes in the right direction. I am reading this as
> the framework defines the protocol should be used between the client and AS
> or client and RS. It is not mandatory, sure, but at that point, my
> understanding is that it makes it clear that if you do not follow the
> recommendations you are at your own risks and so that interoperability is
> provided by this recommendation.
> I am wondering if the framework prevents a profile to mandate a protocol
> ?. I assume not
>
> The one point I need to document in my shepherd is why recommendation is
> sufficient to provide interoperability. I am happy to hear why the WG
> thinks it is sufficient other than we want to leave that open.
>
> 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.
>
> Yours,
> Daniel
>
> On Mon, Feb 22, 2021 at 4:53 AM Göran Selander <
> goran.selander@ericsson.com> wrote:
>
>> Hi Daniel and all,
>>
>> It seems to me that there is no full consensus, so we probably have to
>> inform the AD about the disagreement. However, we do seem to agree that we
>> want to clarify some parts of the framework. Here is yet another proposal:
>>
>> 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 a
>> communication security protocol RECOMMENDED to be used between RS and AS
>> that provides the features required above."
>>
>>
>> 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."
>>
>>
>> If there is an unequivocal positive response from the WG then I may be
>> able to publish a new version today.
>>
>> Göran
>>
>>
>>
>> On 2021-02-18, 23:03, "Daniel Migault" <daniel.migault=
>> 40ericsson.com@dmarc.ietf.org> wrote:
>>
>>     Hi Russ,
>>
>>     Thanks for the follow-up. I was waiting clearer agreement from eth WG
>> before pinging you back. I think I agree with your understanding. My
>> understanding is that the WG is willing to specify one way (RECOMMMEND) and
>> not leave that unspecified while not preventing other configurations (MAY).
>> This obviously results in implementation not following the RECOMMENDED way
>> do not interoperate with those following these recommendations.
>>
>>     The question remains open on whether we should favor openness or
>> inter-operability. I suppose that this will be raised at the IESG so we
>> need to address this issue clearly.
>>
>>     Going back to the profiles, it would be good to 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.
>>
>>
>>
>>     Yours,
>>     Daniel
>>
>>     ________________________________________
>>     From: Russ Mundy <mundy@tislabs.com>
>>     Sent: Thursday, February 18, 2021 3:38 PM
>>     To: Daniel Migault <daniel.migault@ericsson.com>
>>     Cc: Russ Mundy <mundy@tislabs.com>om>; Stefanie Gerdes <gerdes@tzi.de>de>;
>> Daniel Migault <mglt.ietf@gmail.com>om>; Francesca Palombini <
>> francesca.palombini@ericsson.com>gt;; Göran Selander <goran.selander=
>> 40ericsson.com@dmarc.ietf.org>gt;; Olaf Bergmann <bergmann@tzi.org>rg>;
>> ace@ietf.org <ace@ietf.org>
>>     Subject: Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14
>>
>>     Hi Daniel & others,
>>     Thanks for the continuing effort to make the documents more clear and
>> understandable.
>>
>>     I think that there may be a fairly fundamental difficulty
>> understanding (possibly on my part) about the intended relationship between
>> the ACE framework and profile documents.  It seems appropriate to me that
>> the framework would define the overall requirements (especially security
>> requirements) that implementers need to meet and profiles provide the ‘how’
>> for implementers so the result is secure, interoperable implementations
>> potentially from multiple different implementers of the framework using a
>> particular profile for that framework.
>>
>>     If I’m following the discussion correctly, the changes being proposed
>> to the framework would only require a profile to define one ‘example (or
>> description)’ definition that met the security requirements of the
>> framework (even if it was the RECOMMENDED protocol set) but other protocol
>> set(s) could be used (MAY) within the definition of a profile.  Including
>> what amounts to unspecified protocol set(s) that do not define how they
>> will meet security requirements of the framework will likely result in
>> different implementations that comply with the profile but do not
>> interoperate from either a protocol or a security basis (or both).
>>
>>     Regards,
>>     Russ
>>
>>
>>     On Feb 17, 2021, at 11:16 AM, Daniel Migault <
>> daniel.migault@ericsson.com> wrote:
>>
>>     Hi,
>>
>>     I think that could work for me. If the changes address the initial
>> concerns, we may publish these changes in the coming days.
>>
>>     Yours,.
>>     Daniel
>>     ________________________________________
>>     From: Stefanie Gerdes <gerdes@tzi.de>
>>     Sent: Wednesday, February 17, 2021 8:51 AM
>>     To: Daniel Migault <daniel.migault@ericsson.com>om>; Daniel Migault <
>> mglt.ietf@gmail.com>gt;; Francesca Palombini <
>> francesca.palombini@ericsson.com>
>>     Cc: Göran Selander <goran.selander=40ericsson.com@dmarc.ietf.org>rg>;
>> Russ Mundy <mundy@tislabs.com>om>; Olaf Bergmann <bergmann@tzi.org>rg>;
>> ace@ietf.org <ace@ietf.org>
>>     Subject: Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14
>>
>>     Hi Daniel,
>>
>>     On 02/16/2021 04:53 PM, Daniel Migault wrote:
>>
>>     > Section 5:
>>     > OLD
>>     > "Profiles MUST specify a communication security protocol that
>> provides
>>     >    the features required above."
>>     > NEW
>>     > "Profiles MUST specify at least one communication security protocol
>> that provides the features required above."
>>     >
>>     > <mglt>
>>     > I have the impression that with MUST specify one expects a
>> mandatory protocol to be provided. Would the following text be acceptable ?
>>     >
>>     > NEW2:
>>     > "Profiles RECOMMENDs at least one communication security protocol
>> that provides the features required above."
>>     > </mglt>
>>
>>     I don't understand it like that but I see your point. But I think
>>     "RECOMMENDS" leaves too much wiggle room :). The profiles could then
>>     omit the protocols completely, which I think is a bad idea.
>> Implementers
>>     should have at least one example how the communication between C and
>> AS
>>     is protected. Since we don't provide it in the framework we must have
>> it
>>     in the profiles. How about:
>>
>>     NEW3:
>>     "Profiles MUST specify at least one communication security protocol
>> that
>>     provides the features required above as an example how the respective
>>     communication can be secured."
>>
>>     Viele Grüße
>>     Steffi
>>
>>
>>
>>
>>
>>
>>
>>
>
> --
> Daniel Migault
> Ericsson
>


-- 
Daniel Migault
Ericsson