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

Daniel Migault <mglt.ietf@gmail.com> Thu, 11 February 2021 16: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 1557F3A1713 for <ace@ietfa.amsl.com>; Thu, 11 Feb 2021 08:14:10 -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 LMS0Mw-cjUbA for <ace@ietfa.amsl.com>; Thu, 11 Feb 2021 08:14:08 -0800 (PST)
Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 1E3543A16D8 for <ace@ietf.org>; Thu, 11 Feb 2021 08:14:08 -0800 (PST)
Received: by mail-ua1-x936.google.com with SMTP id 30so1899520uac.7 for <ace@ietf.org>; Thu, 11 Feb 2021 08:14:08 -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=rUsbIQBVx3SBsKTWY9ishAc1niM4Y6MnCMfL0tRZfgU=; b=p0KLgHxPSSMnIDcHKRVCU48ZODLh1gcTGIhQmGoS7AHicKxhRAkYTnI11gHI/5h5JO 6dJAP0ZoCwNlpA3RSk/2D9GhUE3iFViCaKu0OhGLJYc4wvZfOf9h7K96YsPs4nysUkVf z5tPmGfQNn6QcSMX8JpJ3Hma6bXkXzTxGO4Nr1jYD2dgldUtONgn1YIU6MK7HUYz2BdX QB55HrNrrEQNEjUw0KzXTjcd0ro6NZ9TJ4DZnzW5WJ7tg6ON2QgMopRcCopUj11+uKvC GDkb59xQeUZslynDFeNMUl/28afngmG7wAMCdcSfs1BDNl3/17Lk5+ngleJfZnUOZ9gI iCYg==
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=rUsbIQBVx3SBsKTWY9ishAc1niM4Y6MnCMfL0tRZfgU=; b=FlmO3bfPPW/0G1HcWXGJEOqw4FRa0N4yScbLJcpaoKNPVT/0cnNHDCmzuEB4jvNaho i8xI20ArdByFmwgeK092/w6N+ZuqAVOrOFnpis9Tx8XRq7C8AgMHqEjZGuO8eAo3ASls YCj7UC9mN2y4XDDJUGHKbtoBkTuE4aAQO7G3ou4a3KdKODIqFui+LygUsY/y3TB7XXR4 AeP1lFXZ25CBYTqCprPnu++Euz/9fzOX0326NeEp2sk6gDv3l8KTHzHLn1iUUuJuybHc wlbt4W1vmrdO/LzIa3+DWQeKCh79iR4gezx3krIVrPDky4AsJeAXyXlFWCvq23G5ut/P wD7Q==
X-Gm-Message-State: AOAM530+W19b9xCL/ZqPz24gBv9xWvx+ulBsxu2B5OP2fQna96ZOc72b PpD6TCmYujN3mqCpquqSUbOkX0wb4MJJoL018gU=
X-Google-Smtp-Source: ABdhPJwckXlH6on9lQ/dvzuNNNUS8FIew5QHA3X8jAQ5G3OBcuIUMq8jwKHu6tWjPm687piscwf/FmMlmw5j1r9KgZQ=
X-Received: by 2002:a9f:31ad:: with SMTP id v42mr5848651uad.42.1613060047196; Thu, 11 Feb 2021 08:14:07 -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>
In-Reply-To: <9911269D-AA7F-458C-AA1A-2D59A79C5A00@ericsson.com>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Thu, 11 Feb 2021 11:13:55 -0500
Message-ID: <CADZyTkn=3GigtTiihQX0ORYyO0dV0qCfVMtTn37vbsqJuQUJxw@mail.gmail.com>
To: Francesca Palombini <francesca.palombini@ericsson.com>
Cc: Stefanie Gerdes <gerdes@tzi.de>, =?UTF-8?Q?G=C3=B6ran_Selander?= <goran.selander=40ericsson.com@dmarc.ietf.org>, Russ Mundy <mundy@tislabs.com>, Olaf Bergmann <bergmann@tzi.org>, "ace@ietf.org" <ace@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001d56d305bb11cf8c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/7nuhkhbz4yzlYYwmAMxDRw_zAws>
Subject: Re: [Ace] [Russ Mundy] Re: 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: Thu, 11 Feb 2021 16:14:10 -0000

Hi,

Thanks for the feed back Francesca. We have discussed this issue during the
interim meeting, so I would encourage Olaf and Stefanie to propose some
text that reflected the discussion before pinging Russ.

Yours,
Daniel


On Thu, Feb 11, 2021 at 10:02 AM Francesca Palombini <
francesca.palombini@ericsson.com> wrote:

> Hi,
>
> I am fine with Daniel's change to the DTLS profile (which wants to add
> motivation on why the DTLS profile is RECOMMENDED), and prefer Göran's
> formulation to the Ace framework.
>
> I had to think about it and figured out where the different
> interpretations come from, and hence what needs to be clarified:
>
>     "Profiles MUST specify a communication security protocol that provides
>        the features required above."
>
> Russ reads this sentence as: one (and only one) protocol MUST be specified
> *and used* between Client and AS.
> I (and others) read this sentence as: (at least) one protocol fulfilling
> the security requirements MUST be specified in the profile. (and as a
> consequence: One and only one of these protocols specified in the profile
> MUST be used between client and AS)
>
> I think Göran's modification clarifies the above, but hopefully Russ can
> let us know how to make his even clearer.
>
> Francesca
>
> On 11/02/2021, 12:35, "Stefanie Gerdes" <gerdes@tzi.de> wrote:
>
>
>     On 02/11/2021 04:26 AM, Daniel Migault wrote:
>
>     >
>     > OLD: section 6.2
>     >  "Profiles MUST specify how communication security according
>     >    to the requirements in Section 5 is provided."
>     > NEW:
>     > section 6.2 is focused on security but the security requirements are
>     > provided in section 5. We may simply remove this sentence.
>     >
>     > OLD section 5.
>     > "Profiles MUST specify a communication security protocol that
> provides
>     >    the features required above."
>     > NEW:
>     > Profiles MUST provide some recommendation on protocols used to
> establish
>     > these communications.
>     > These communications MUST meet these security requirements. As
>     > communications meeting these requirements may be established in
> multiple
>     > ways, profiles MUST provide some recommendations as to favor
>     > interoperability. In most cases the recommendations aim at limiting
> the
>     > number of libraries the client has to support.
>     >
>
>     The reason that this requirement on the profiles was included in the
>     framework is that the framework itself does not specify how
>     communication security is provided. For the security of the solution it
>     is important that the profiles fill this gap. I think that it is
>     important to emphasize this security requirement. I therefore prefer
>     Goeran's proposals:
>
>     Proposal 1 (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."
>
>     Proposal 2 (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."
>
>
>     Viele Grüße
>     Steffi
>
>

-- 
Daniel Migault
Ericsson