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

Daniel Migault <mglt.ietf@gmail.com> Mon, 22 February 2021 15:03 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 38BD13A1CE1 for <ace@ietfa.amsl.com>; Mon, 22 Feb 2021 07:03:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.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_HI=-5, 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 VyCjCgFt9iHH for <ace@ietfa.amsl.com>; Mon, 22 Feb 2021 07:03:00 -0800 (PST)
Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (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 BF0383A1492 for <ace@ietf.org>; Mon, 22 Feb 2021 07:00:32 -0800 (PST)
Received: by mail-ua1-x92f.google.com with SMTP id a22so860578uao.9 for <ace@ietf.org>; Mon, 22 Feb 2021 07:00:32 -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=uPknaehGAtrHpJp6nIw26vCSdOADXNJudnlijHhRK20=; b=CETnWM+2TLFEjzlb0PVs01o+R8cUjn4vEjB5wOyGnFJPC6vbtopcsxwsWuMWboNwEB 3M6U7LgpI82zXEGkL2nRNT5IyNf/14Sgf1C/cK7K/BbmpFo1xUOLhxQ2xU/Z2gnZFtXR Zr0gpxRuMefqUv0/T3xRJtJlpqrnq1gmULGCxoiG41E88ybio2si0kgaDfIh8h9bRrKY Zh2iC06CpPcBV2gnL645lgg7YAFfdL7lQMwEQMyHCUXTfGznNPvudRUM1VzSIIH1DlSf C2mXoR/gur0QHRW2qaLWuNc05qFFluKsNZL03bUbfPvXhkxwMWQXbCd+y3OaU5REAeXs xK3g==
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=uPknaehGAtrHpJp6nIw26vCSdOADXNJudnlijHhRK20=; b=SnspYkEkY0YaPoOwwoZOp5jiLBdsCL1ijLRwnrOY41gcPlG5TisOQ/9XDb7Q8XpIAh NYZi3mRZzXXCz4OYqVOCehC5dGi3bgYO1SKQcCGwO1+wyU+lqndt796UTKHH6fV+FSu1 8gO44gjzfqLGm4mAf4EogSwP4CDgWnF/ydnDHnu42uvAxIDCS+ZdJwjeOF6Ot0bhIJSK nT4FPUSji9KezkuDEaGi044FOnv0IZ8wZsp4mizR8olJ1VGzMu1o0+OZRnO60NyQIe+4 c71M4SApM5sBqdylcTruEcMFnFOnGnlDNBe44iX4Jxc0v2GozSrLwF1JKC+w4+gp/s/R qGEg==
X-Gm-Message-State: AOAM5308Bb+//YWuXCWuzzmVEObTtCEdeb93pp2qOZiEKALK1Mvc8T8D EBcOzB/8lLJcH7FzWCBkM2jRtYlVz+KLq8+TO2A=
X-Google-Smtp-Source: ABdhPJx97grBvgEk+WaBy5HF0UR+Dc8fVi2wTPBWWNXvHjbcEdBW6Gy27LbQ5imEVsE1MsNcXOn9QLLrwcM9RQkDBTE=
X-Received: by 2002:a9f:31ad:: with SMTP id v42mr15322856uad.42.1614006031790; Mon, 22 Feb 2021 07:00:31 -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>
In-Reply-To: <F6B1D3C5-DE79-42B4-8CEA-620C86EABF4B@ericsson.com>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Mon, 22 Feb 2021 10:00:20 -0500
Message-ID: <CADZyTk=y7Zf3Atvt7d5c17KEbnc5CESoOyBsa0TgpMchX4FcPQ@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="00000000000030b74e05bbee10ab"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/OCGCb7lHoQ4SXjElXSwsYo1RrS0>
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, 22 Feb 2021 15:03:08 -0000

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