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

Göran Selander <goran.selander@ericsson.com> Mon, 08 February 2021 21:21 UTC

Return-Path: <goran.selander@ericsson.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 7FFD53A160D for <ace@ietfa.amsl.com>; Mon, 8 Feb 2021 13:21:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.351
X-Spam-Level:
X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 o1gDHfhc7Zxk for <ace@ietfa.amsl.com>; Mon, 8 Feb 2021 13:21:34 -0800 (PST)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00085.outbound.protection.outlook.com [40.107.0.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A0FD3A15F6 for <ace@ietf.org>; Mon, 8 Feb 2021 13:21:34 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZBleqH+3NnG/g8fbkUKIZrKNSukQgz+d25USCManap7JlV1g7T7udG6K4S/HsK2yyYQGZNhAaaaWomGEe1fMjyl29YTIWInIf2Erq8ThS3n1Mgvzxp1ijW0QOJA1EKW37Aic8q+3FjZvT4ioUugwPZz3k3LXvMyy9vnDU4yCTqXgN3R66QnCjLpZhOadqWr6JCEx7cLg4JoB2JFAj/UCOgJb8Fu5ZO3dbeTkjUSeCYWyYDnGvXoDrtHzLXDbZAWKjpKkh/g9ddIu7vyxEaMdLlnz9zaXx6HU5cMYyVcJYGdtp89NQWiiYXpiA81qkCpKyU4LzWc3/oXxpB6ZZQ8KLA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gAvytEYDARB+7bvp9xu7qfNIm1lrsbVruUehwTw6/pk=; b=gv4Y0gHLkQXoAqKtCHHuHUoFvRk87qJEQGgRQAA3iKNY3GVZDGcdRbTaEzt1Rv46D3L3c1RHzIZ/c6BHeHqwuxm/gpkHsDuOYedCxTQjgfkxaZtVp0AzRN7OKyjjUPn34RyzbRVrCj2Dg8YgcuzhhoPkRcWba1qkjQdqr4oSwlvN2B2N9MdIZOAbVbAALdRjK7kpjW8Un0nbhEh3Vq+ahTM/tLtQCMSOqiZWP3mO5I+Pc75Z5NDrPYKUpjMJkzBWyIj29rUc4l1xsXnsSroB6B7NmLClYI+ig/bZ/SGHBZPzEHVPGeGHdWHFReUv2paReL1qmVYcy1zxVCefgQnIoA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gAvytEYDARB+7bvp9xu7qfNIm1lrsbVruUehwTw6/pk=; b=IYK03DqX6Wou+ar0Nza8iBcON+enwlMmzS+G357MWisQdypcZUb7Vh5CiOC+p5jWeR+g8OB3DSArl+tDEBOdPyNYl/AgHVqG7nKjZxtD/R2ifYy5FtTinZ9p7qLC97rvJINeqxITNsV1AizocAOhp2LBJSL8v5ppEW4YPWV94uc=
Received: from (2603:10a6:7:82::14) by HE1PR0701MB2748.eurprd07.prod.outlook.com (2603:10a6:3:9a::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.15; Mon, 8 Feb 2021 21:21:31 +0000
Received: from HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::588f:43b1:d981:5bc8]) by HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::588f:43b1:d981:5bc8%5]) with mapi id 15.20.3846.021; Mon, 8 Feb 2021 21:21:31 +0000
From: Göran Selander <goran.selander@ericsson.com>
To: Olaf Bergmann <bergmann@tzi.org>, Russ Mundy <mundy@tislabs.com>
CC: "ace@ietf.org" <ace@ietf.org>, Daniel Migault <daniel.migault@ericsson.com>, Francesca Palombini <francesca.palombini@ericsson.com>
Thread-Topic: [Ace] [Russ Mundy] Re: secdir review of draft-ietf-ace-dtls-authorize-14
Thread-Index: AQHW/kCCJWXd6onrY0+dF03WvwRJiapO1P4A
Date: Mon, 08 Feb 2021 21:21:31 +0000
Message-ID: <FD569111-85F8-40A2-8C97-764977309B87@ericsson.com>
References: <871rdqihww.fsf@wangari>
In-Reply-To: <871rdqihww.fsf@wangari>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.47.21020100
authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [83.249.67.87]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: fa5a6b35-7b47-4deb-5865-08d8cc778160
x-ms-traffictypediagnostic: HE1PR0701MB2748:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR0701MB27487555B876688E54E512C6F48F9@HE1PR0701MB2748.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: y0MmZv8iBK0rr21piTkILNebkQMOeHRusn4Iz6/tkYRF4VcFlSxryiAemPdnKmiLuA//v4npF40oJEQBXraoEHUsvAVkOW0F8O502YQwEECpKNKc7fSVv0cH/hOahYUf1lyK6oIgMQz6X1kLvaf+YxcniG+Cpul5iZrUHrS0jM5nlVktZlGA9vnzL60+8bxx+npUOB3uvYKqiu38kHKaxqV5emsEKTvjyaQDhe/qJEEdTWGx7mUVON+ILhpGO/rg3TqTfNC2zeYthTiIF7Ir+3hknhr0agKBEhVWg/oEAhb/ZKS2f42c/XOAuUM3igSL06BR2wIwvhU8fy+w+Q0iZYWZk2YKjqRBu+RYI7q5qX5NMxqF8fwqUKZ6cigJnKn1nGVTM1Vj8gdX1m6pE9ULWMMRo7KWvp41dWj2l27EhffJ2VTwrGi1iqJmiVm8SEvn+6aYzqgF7Pj012jmXdxFxwgknMRWSpl1Gcx34fG5HZSxmlrTwKKhZ3DLf/xo1xZR+3mKVG9wpYrYv6YjmmsSjMh+RqYz6k4yZnwu+krpO0Bfj4NckLqq2wxxrzHX8mVFlZR85DPCobbpLRQdXOxqTi2colI8Ibw7obVJK7QEoukLRenL5fQJnXDS91j5ONqW4kQ5zni8cSMM126dZg27/Q==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3674.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(346002)(136003)(376002)(366004)(396003)(8936002)(76116006)(5660300002)(33656002)(316002)(107886003)(86362001)(66446008)(85182001)(6486002)(36756003)(71200400001)(66946007)(8676002)(478600001)(53546011)(966005)(66556008)(2616005)(64756008)(85202003)(6506007)(83380400001)(26005)(2906002)(186003)(6512007)(66476007)(66574015)(4326008)(54906003)(110136005)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: BAEMhs3h4CWTvNsIozXpuoy4WyuiOvBWd8DRH2+mjBi82KXKWXMyX9q/e/7D+uYurPlvRPFyvLIXLlpvijMVWS6F6J6imBue3g+bJCegTp/HHl15/C2ict6aHzBlyJ3FIh4Oz+KFd/WNyrbQWxLz0Yzzkcegb1Ket/RqZl+VsTAryMKstt4kWwfCctKd4q8bdtsgYcvkb6WbRAdUqt92EcrPYRwm7wmgIUrcvfPHNb7T4+zU2bEVsOMJ612sZf1+fkUtUap8UxPcVWxawVCCaEGfksF1wkxmi41DtDPP+z6YDhF1FVZWUUgosgEm5cMlStoqg1CiLDK0wLRBH3VVMoAAh+AibeHFKSXzRrhE5GUgy3TXF2Yiiic4Ld/mfvbbzFJ8UNQ0SevFrQtcshSTFjTjdPQCNq91sSrQK3iznlb5kiG6HOsCwtXqEvAWkNYi2VQgowvDguUXReOVSfNosOgFOj9csVFIP95HRPMgIu/qxv8ndLXc+2tWt7G9hwxAtp3aDJxdwi0a/RaqiJK3VQHd3QVIv1IxSOi3lDqm7lK1Sd3Sq5MduaxgLVjeLve+BPnjBkROE7WuA5mO09xSx3MASxzeWv6cw4X95gOWxJEa7qtnb05uqNCxQg62qXNElFZ2u+1L/OejpsX4EyKvAnKLckPFU7NiQRcwr+Cpbn189NBryA1cjPIRpwOAdZa5Z8LMi1s7dkZ/KmtFGvcoRoOMF4rq6tAK1ZMKg1fUlzOM5P2490u2g8WBe9Ccxd0vk20oArQ3zI/vm5CoyHndtx9VLDqjABC3i0O7O2G0KStBKCiUJ2ECW32GRa0vplwTDblJEwoj3jge+eioPYinLBWnm5d1rBBZa2MdBb5PrAckezzXjUWCVrd3u2qOaNmoiqycJyttsp88nOy7kwOVuhGMIZT9k1Bbeby+to18nYojNIjdemYNeqtw0kVzC7XqJWRkSlw3y4mcP52DTPRODy746O4+HLw2wun4Fld+Wqxbw4+Da6uJ0xqwD7RR49a6AEQG4QOvGLTm3b+CXANgvhAq8KNuzwuUplmU7wsq1HDmuTz5JOTI1w2jGKXF/yY1GrkZ73u4L8Hgzu/fDLr19P/aLZnIOWSLfCoQBn8Uvh8XxX6YJdgtwj/4Eo+vSa5fGfyugUEZsZc5jQodr7oFkAGjWovNPar70Mc1wLwZ2FwjvvRVPW9l1ppcmPMutme07HXCe2gfT06eA4fpqU7p53ry9ZoOF5lDnC9MiXsKxWxLAMqduP95bUPVfOEm/DwqKAiBiVH/hzuW1pOxGh5Us5rTF/WpktNC57umpI4bcGM+yeo3IzUMJDouocZAzU1T
Content-Type: text/plain; charset="utf-8"
Content-ID: <BCD98EC586FB9A41B73BC6895EC11618@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3674.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fa5a6b35-7b47-4deb-5865-08d8cc778160
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2021 21:21:31.4056 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ULO+VlKGJuJtBWXyN2rZX9IwvSFLUS1fXXhOoHpipz13S1m/FC1GjhcMSk65D+i+aw8Ap4i7TymYFgq/LY2fM4y2wj+ecRRO8jY0T568Pu4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2748
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/fBgjqhaoP_DF5FzD4y-a-hGwmXs>
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: Mon, 08 Feb 2021 21:21:37 -0000

Hi,

Russ commented on a formulation in [I-D.ietf-ace-dtls-authorize] (which also exist in [I-D.ietf-ace-oscore-profile]) that he characterizes as a deviation from the MUST requirement of 6.2 of [I-D.ietf-ace-oauth-authz]: 

  "Profiles MUST specify how communication security according
   to the requirements in Section 5 is provided."
	
which in turn is referencing the requirements in Section 5:

"(---) it is REQUIRED that the
   communications named above are encrypted, integrity protected and protected against message replay.  
   It is also REQUIRED that the communicating endpoints perform mutual authentication.  
   Furthermore it MUST be assured that responses are bound to the requests in the
   sense that the receiver of a response can be certain that the
   response actually belongs to a certain request.  Note that setting up
   such a secure communication may require some unprotected messages to
   be exchanged first (e.g. sending the token from the client to the
   RS).

   Profiles MUST specify a communication security protocol that provides
   the features required above."

As I recall the intent with the text in Section 5, its purpose is to ensure that there is *at least* one common secure protocol complying with the requirements.

Furthermore, I think the formulation in section 6.2 is unfortunate - there is no need for additional normative text since it is referring to a section where the relevant requirements are stated. So, rather than change the text in the DTLS/OSCORE profiles, I propose we make a clarification in the ACE framework.

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."

All: Does this accurately account for the intent of the framework?
Russ: Would this address your concern?


Göran


On 2021-02-08, 18:33, "Ace on behalf of Olaf Bergmann" <ace-bounces@ietf.org on behalf of bergmann@tzi.org> wrote:

    Hi Francesca, Daniel,

    I did check with Russ if the new text will resolve his concerns. As the
    new wording still does not seem to be sufficient, I am forwarding Russ's
    response here as I am not entirely clear how to proceed. 

    Any ideas?

    Grüße
    Olaf

    -------------------- Start of forwarded message --------------------
    Subject: Re: secdir review of draft-ietf-ace-dtls-authorize-14
    From: Russ Mundy <mundy@tislabs.com>
    Date: Sat, 6 Feb 2021 16:01:00 -0500
    Cc: Russ Mundy <mundy@tislabs.com>,
            Daniel Migault <daniel.migault@ericsson.com>,
            "draft-ietf-ace-dtls-authorize.all@ietf.org" <draft-ietf-ace-dtls-authorize.all@ietf.org>
    To: Olaf Bergmann <bergmann@tzi.org>

    Hi Olaf,

    Thanks for the follow up and the additional suggested revision.  

    Unfortunately, the NEW: wording does not resolve my concern. In my view, this newest suggested wording has the same fundamental problem as the original wording, i.e., it does not meet the MUST requirement from [I-D.ietf-ace-oauth-authz] to define how "other protocols" meet the requirements in Section 5.  

    I certainly understand that there are a number of choices that implementations can make for various parts of the ACE framework. However, the framework does seem to be very clear that profiles have to define how communications security requirements of  [I-D.ietf-ace-oauth-authz] are met.  Even though other protocol combinations can meet the security requirements in Section 5 of  [I-D.ietf-ace-oauth-authz], the ACE framework requires that profiles define how these requirements will be met.  So the problem remains with the current profile only defining how communications security requirements are met for CoAP and DTLS but both the NEW: and OLD: wording would permit "other protocols" to be used under this profile without defining how the "other protocols" meet the security requirements in Section 5 of  [I-D.ietf-ace-oauth-authz].

    Given the requirements of [I-D.ietf-ace-oauth-authz], it seems like any protocols allowed by a profile have to define how the framework communications security requirements are met when using the allowed protocols.  

    Sorry but it seems like including "other protocols" in a profile that have no ACE framework profile defined is a significant deviation from the MUST requirement of 6.2 of [I-D.ietf-ace-oauth-authz].

    Regards,
    Russ


    > On Feb 4, 2021, at 5:26 AM, Olaf Bergmann <bergmann@tzi.org> wrote:
    > 
    > Hi Russ,
    > 
    > On 2021-01-19, Olaf Bergmann <bergmann@tzi.org> wrote:
    > 
    >> Thank you, Russ, very much for your review.
    >> 
    >> I am perfectly happy with your suggested change to make CoAP over DTLS
    >> REQUIRED for this profile.
    > 
    > as it turned out, people felt that making CoAP over DTLS a requirement
    > would be too restrictive. The reason is that the ACE framework generally
    > allows for different protocols to be used between the different legs of
    > the communication. Usually, the ACE profiles focus specifically on the
    > communication between the Client and the Resource Server. Both entities
    > may communicate with the Authorization Server to retrieve the required
    > information to establish this communication.
    > 
    > Now, if the CoAP over DTLS was required for the communication between
    > the Client and the Authorization Server (or the Resource Server and the
    > Authorization Server, respectively), a combinatory number of additional
    > specifications was required to enable the Client and the Resource Server
    > to use a different protocol for communicating with the Authorization
    > Server, e.g. HTTP over TLS.
    > 
    > We therefore propose the following change, referring to the requirements
    > set by the ACE framework document on the security of the communication
    > with the Authorization Server:
    > 
    > OLD:
    > 
    >  The use of CoAP and DTLS for this communication is RECOMMENDED in this
    >  profile, other protocols (such as HTTP and TLS, or CoAP and OSCORE
    >  [RFC8613]) MAY be used instead.
    > 
    > NEW:
    > 
    >  The use of CoAP and DTLS for this communication is RECOMMENDED in this
    >   profile, other protocols fulfilling the security requirements defined
    >   in Section 5 of [I-D.ietf-ace-oauth-authz] MAY be used instead.
    > 
    > Does this resolve your concern?
    > 
    > Best regards
    > Olaf

    -------------------- End of forwarded message --------------------

    _______________________________________________
    Ace mailing list
    Ace@ietf.org
    https://www.ietf.org/mailman/listinfo/ace