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

Stefanie Gerdes <gerdes@tzi.de> Thu, 11 February 2021 11:34 UTC

Return-Path: <gerdes@tzi.de>
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 004553A14E7 for <ace@ietfa.amsl.com>; Thu, 11 Feb 2021 03:34:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
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 dpUbRtevcWwc for <ace@ietfa.amsl.com>; Thu, 11 Feb 2021 03:34:56 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1B6D3A14E0 for <ace@ietf.org>; Thu, 11 Feb 2021 03:34:56 -0800 (PST)
Received: from [192.168.0.57] (p5b36f033.dip0.t-ipconnect.de [91.54.240.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4DbvgL0l9vzyV1; Thu, 11 Feb 2021 12:34:54 +0100 (CET)
To: Daniel Migault <mglt.ietf@gmail.com>, Göran Selander <goran.selander=40ericsson.com@dmarc.ietf.org>
References: <871rdqihww.fsf@wangari> <FD569111-85F8-40A2-8C97-764977309B87@ericsson.com> <CADZyTk=HB26o=mUpUdbYEhfhrGZar+oe28c5PZ2_j-vKYVA6xg@mail.gmail.com>
Cc: Russ Mundy <mundy@tislabs.com>, Olaf Bergmann <bergmann@tzi.org>, Francesca Palombini <francesca.palombini@ericsson.com>, "ace@ietf.org" <ace@ietf.org>
From: Stefanie Gerdes <gerdes@tzi.de>
Message-ID: <c6d42d18-f1f3-ec00-fff9-3540fa222d23@tzi.de>
Date: Thu, 11 Feb 2021 12:34:46 +0100
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CADZyTk=HB26o=mUpUdbYEhfhrGZar+oe28c5PZ2_j-vKYVA6xg@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/qrqHLsFcWItgsjKMCd7F0pDQzOI>
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 11:35:00 -0000

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