Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)

Ludwig Seitz <ludwig.seitz@combitech.com> Tue, 06 July 2021 06:22 UTC

Return-Path: <ludwig.seitz@combitech.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 1CB943A14EA; Mon, 5 Jul 2021 23:22:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=combitechcloud.onmicrosoft.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 Lfv5ZsupCV5t; Mon, 5 Jul 2021 23:22:18 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80040.outbound.protection.outlook.com [40.107.8.40]) (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 325A33A14ED; Mon, 5 Jul 2021 23:22:17 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YU4/WEbcqweLWer78bfxE7NOCgE4HAYmVIW8LonzNlsxKcn+t7PS4XXaJKvsYVIETO3uTbxHMIoZzLfnazJ74bmo4QGDd6vHVmqqdsPeikA28cxuG6uhUuJdICSCDDz3t2O5yq9M3eM916IhjgE2EJKiDu9tsiDT3dT8qa4uszECLdqX4af72n2nSZly1ASzHcCt6AuxzWOJRz4UZwis1iomOR/fjR7MjeTj7gUwOMgLRdz2XxxVfCpzsOp2imi5K4bn7w84anVTUouA0ZRsF147Nml81RUV1zrvivfO9+IcTMgl6jgFDeJTpsTFY5+888wabHgIMh5nKjygZIL2ZA==
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=gC7qFWr3XPoTHYadaefe3DjrmBFBhuU4Ku+V/rgA1as=; b=V/e5838Ae9w0OSjr0wr27qPppflEyhvrzyV+spGw06dt7pK7OZ6nyERnD97oEdoyl5+VD3iPGtXAlsq+tEW3Cu/twgVuA8ZCxXUTc9tVIqer/eT2ueJwZQxgdjT1t3oG6RHUJMHHlahTkoY/sxqKnt4KrpFMHxbMTiP5hL6VOctvrGzdlUPxPtdfFerw2kBjuaapBcvZKGe4YKrZSAK9bxw6y/3Ni73J13RCp+YsQglwh7iyo/EaerMyIVkQ1DVVHnUztCzp1xwGfblotp9xgYx+8R2DWvMr0PIcKb902JtgErF3/4JsDzfvNTLpiA6l9r1SDS5WkVqtSetzy+WkJw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=combitech.com; dmarc=pass action=none header.from=combitech.com; dkim=pass header.d=combitech.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=combitechcloud.onmicrosoft.com; s=selector1-combitechcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gC7qFWr3XPoTHYadaefe3DjrmBFBhuU4Ku+V/rgA1as=; b=w1nw5UI1UKNOSVgAYsLpVkKIU4ocv6tccExfskqUhnyVEQjpyVgsTkzOf6/g6r7sHK3rsw4DuEij+6+E4Oz2LZM8lX/knu3dO+vRgn+6dxWh/FdDaQe9QwijRXrHh5v9Y9WdAMx5VfEuXXA7PM8+VTcdcTBFypQc56uDBgHWw1I=
Received: from AM0PR0302MB3363.eurprd03.prod.outlook.com (2603:10a6:208:c::21) by AM0PR03MB4514.eurprd03.prod.outlook.com (2603:10a6:208:d0::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.33; Tue, 6 Jul 2021 06:22:13 +0000
Received: from AM0PR0302MB3363.eurprd03.prod.outlook.com ([fe80::50c3:52c1:d1a8:ea87]) by AM0PR0302MB3363.eurprd03.prod.outlook.com ([fe80::50c3:52c1:d1a8:ea87%3]) with mapi id 15.20.4287.033; Tue, 6 Jul 2021 06:22:13 +0000
From: Ludwig Seitz <ludwig.seitz@combitech.com>
To: Francesca Palombini <francesca.palombini@ericsson.com>, Carsten Bormann <cabo@tzi.org>
CC: Daniel Migault <mglt.ietf@gmail.com>, Cigdem Sengul <cigdem.sengul@gmail.com>, =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= <goran.selander@ericsson.com>, "ace-chairs@ietf.org" <ace-chairs@ietf.org>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] [EXTERNAL] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)
Thread-Index: AQHXXP8z1upufOVKmUeiNAajfIF22qsLfRbggAstAQCAFMBAgIAAPD4AgAjAu4CAAAjN0IAAGjWAgAAL/4CAAAXLgIAAJ/SAgADZ3qA=
Date: Tue, 6 Jul 2021 06:22:13 +0000
Message-ID: <AM0PR0302MB33635AEFE7CE8642EDEE3B039E1B9@AM0PR0302MB3363.eurprd03.prod.outlook.com>
References: <161659738410.3239.3955409176349739508@ietfa.amsl.com> <5634f824f7b14878b5d7d1fdd3b2ed33@combitech.se> <EE1CBB56-8951-473C-A006-875D49BEE350@ericsson.com> <AM0PR0302MB3363E4EB817969E6B34FBBCF9E369@AM0PR0302MB3363.eurprd03.prod.outlook.com> <F44C49D2-C08E-4C04-A751-05ECBBB1DBA9@tzi.org> <AM0PR0302MB3363C4C6DBD796E67986BD079E369@AM0PR0302MB3363.eurprd03.prod.outlook.com> <43222AD5-BA56-423F-98C7-65128A6C35B6@tzi.org> <CADZyTknQEYbv=3vo_MfjGeWmJOcU-QfkFua-ZGnFHfXhni=omQ@mail.gmail.com> <3AF922BD-D6D7-4D20-AA39-5E0D5BEC8A29@tzi.org> <a040239b-fc8c-b2a3-c055-481246f4397c@tzi.de> <AM0PR0302MB3363B7DBB026447BE536D61D9E1C9@AM0PR0302MB3363.eurprd03.prod.outlook.com> <A15462D1-DD0F-4B3C-8C59-7652C6A5F471@ericsson.com> <78BAB6EA-0DDE-4C6C-A923-815E73F1B197@tzi.org> <F329D30F-EF2A-4BE3-B29A-8425CE44A6D2@tzi.org> <15769C3B-A3B5-46E6-AD3A-9FBA63783EAD@ericsson.com>
In-Reply-To: <15769C3B-A3B5-46E6-AD3A-9FBA63783EAD@ericsson.com>
Accept-Language: en-US, sv-SE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_71cffee6-aa30-4f5a-bbc3-434e7067f7b3_Enabled=true; MSIP_Label_71cffee6-aa30-4f5a-bbc3-434e7067f7b3_SetDate=2021-07-06T06:22:11Z; MSIP_Label_71cffee6-aa30-4f5a-bbc3-434e7067f7b3_Method=Standard; MSIP_Label_71cffee6-aa30-4f5a-bbc3-434e7067f7b3_Name=Company Confidential; MSIP_Label_71cffee6-aa30-4f5a-bbc3-434e7067f7b3_SiteId=0d11ac4a-ef5e-423a-803b-e51aacfa43d6; MSIP_Label_71cffee6-aa30-4f5a-bbc3-434e7067f7b3_ActionId=3058a17a-8475-407e-9053-aff53a0ff317; MSIP_Label_71cffee6-aa30-4f5a-bbc3-434e7067f7b3_ContentBits=0
authentication-results: ericsson.com; dkim=none (message not signed) header.d=none; ericsson.com; dmarc=none action=none header.from=combitech.com;
x-originating-ip: [84.217.44.37]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: fa3c6cff-bd18-4445-55f0-08d940466502
x-ms-traffictypediagnostic: AM0PR03MB4514:
x-microsoft-antispam-prvs: <AM0PR03MB4514B40753EFF37FF1BDD9EB9E1B9@AM0PR03MB4514.eurprd03.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: /YTfELITWs+cusff7+ue5QKW7ywtOfBV2XzhcxRutZCp1E5ySxsA0jAqRwZizodlJ/pQetN1WU1Fm+HSKtM/L5p0WDdTo4RSIqh/l6v3ke2rg76P4tTYe3o6QxUn8o5loum9WtP4md7v2r7tx6w05Ix8CMmSN6nZ2hWWBDTi3Dj5W8CaLjOCRLdwiWRYYeMsuAMJd5fwRBNWb9CTkTATPe9l+Dz+1qL1A4wmlLKqjZybE4MkKBIiDycwJsIUuN/V/Iv/0pyHG+wa9WsALe6lPURl45aBDC0VVvzAfMngVMKkw60qFf4hH3lcNeXCRzynSxTggWdDG8yKyLlhhiU1bIkqwtAc4pUtnNhWr65Hb0BM7tZL4lMXGN7Oc1vSQk7CVgCPE3kpiuMKQTY0JzTNv6jzDfErAqJjiIDhCAhylp3flqB5KVb7xj0TDs56ZhfZwbCzPdrE64vcNsvQBVTpc0zoh8a6LnjvacAMhiXN8ZhDamUGZoI6ERamV4hMMa7gauo51DuNd1mkoDxLixSmkk/ESSpH+Ux4VVhFL8Hjm7X1oMBNyiUF09q6Y8xSIdnxZ1GfBVI0+TqUHFVIvRfIn/gFbZ90vEeRgGd1FLxGmehOvVYYHvLZRALhDMzfwvEXfZte3nO6hfAzjb/SYUUg3w==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR0302MB3363.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(366004)(39840400004)(136003)(396003)(64756008)(186003)(52536014)(83380400001)(66556008)(44832011)(76116006)(66476007)(26005)(2906002)(33656002)(54906003)(66946007)(8936002)(110136005)(316002)(66446008)(71200400001)(122000001)(38100700002)(4326008)(66574015)(86362001)(53546011)(478600001)(5660300002)(8676002)(6506007)(55016002)(7696005)(9686003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?VE0zYlp0U1JRb0hOZFNPM1hSdzRLczBNM1l2Rzl2c2dFeXRVa0hDZkl6ZUw1?= =?utf-8?B?eklVTVlmZ1QwMmlMZHNHN3JxdVdyZUY4NlUxZ05NaDBkdndZdVdudGllSDhB?= =?utf-8?B?WTdYemlhTlVCWkYwWDAzQWxhbTlycEdhdmhvSVVUZFhRR1BjVFN0QmNpWUtt?= =?utf-8?B?NG1OdkphWXlYdUhqVDVTbFh1OER1TWw5enZnYXk2WXNqVTV2QzIrdVhETVJQ?= =?utf-8?B?VjhDS3k4SERjY3ZSb1pUcDJYU0ZJanozVW5ZUTF2VTJFODlFSkp4Vm9VZTU5?= =?utf-8?B?MGpUQ2VxL1Jpem1PWlNiT01oZ2NpeXpybTI1NnJ4azVVMis2WFFHd044N3RM?= =?utf-8?B?L0hsZzlsbUVvS0t1ZlpabGQ4bTZxc2hzVG9KSWt1SHFlRWpXOFFvYjlXMUh1?= =?utf-8?B?TUxxeTdUbG1sblV5ZVhZS09hWDl5bGpPZ2hVWVp1RkEwMEZMemFFcTFVbElp?= =?utf-8?B?ekM1OHFIcmZxUmExUVhQTWljbWV5VXFCS3kyeFV0U1RqcWdzN1VrTU1UcEEz?= =?utf-8?B?MXZPcmJuWUt0NUgwcHlvV0hnV0FjNHJudURhbkdoM2JjeG9XeHIvYTh6RHY1?= =?utf-8?B?b2FndmJvNEp2QTFSR0IwWUxMeUxZRkpxNUdLL2UyK1RmWUJ1aW43VjZ1Sys2?= =?utf-8?B?cFFaVWpzUEo5WXExbFhXeW85NldrSzdRRTRDTmVwOXFJRHlqZGhrbkFraEpa?= =?utf-8?B?dDN3YUs3Z1UrZTkzd2VPSzd1MVlQbFRoeWpJbFZLa2RRVDFCUDhTV1cweUta?= =?utf-8?B?U2JidHBlWnZQQzZmeDBkMkFqQ1d0R1Y0U2dRSzd1WW4zcUM5NHo2QXVKRlV6?= =?utf-8?B?ZElrSkIzdVpqREI2TlFHdkVWK09aek1qbUFTQ0FRaExtcmpRUDFrQjdpbFdY?= =?utf-8?B?Z2N4TldVak5iZVZjVklISmJhLzYzaVlBOENhVVE5ZFNXa1pDTFFGc3RzRStP?= =?utf-8?B?THBpRGxKZGsyZ3BTeDlFSFQ2TXRHM0lPM3VsMG1HQkJNQjVqTGhXSHZXcXQ3?= =?utf-8?B?cEpIaUI4M0RrVzlGRFBjcGNDRFB4NE5ZdTJPRHR1T0FqR0xZOHliTW5CWWk5?= =?utf-8?B?eVpvMjJzYi92M2xGR2xkQTMreUxTc0YzYU1Ya1ZuL3JlR3lMYUtCMFB6QzRl?= =?utf-8?B?YzgwaTJLQk1xV1JyT1lhQlZrYVdDQi9Fek8vUXlpdlkycDJ2cS9rZmhSdGUv?= =?utf-8?B?NnhUQ0QzakV2UTNuU3dJZ0h2T0hIYlpYTlMwWDY1OUZmNmc4aEIrTXdYYVND?= =?utf-8?B?U0t1VDhZSlk5QW9KTzFCYlBRbmhtckVYV1ExdlMrQlpVNWYxY3N1WVlSTmp0?= =?utf-8?B?ckx5c2xPNUM1YllXNkVUamtPckNHUmM3M1RCV2J1TFRZMGl1RlRhYlpNK0o0?= =?utf-8?B?cUpNWnFnM1dPZnNJRTdkc0xsdnc1dXdtUzNoeEQvdk8xTnRJbFQvYkRlQVVR?= =?utf-8?B?RUVaUlluZGgyK2JvNkI4MnBkVUloTWVJbjNodkdZclVSMkJkWWtkSWd3UWdk?= =?utf-8?B?dGc2d2hyUThyRUgweFlhUjRnaTY3VTRPeW56VFYySHNHZVNvUm82cmxrbmFp?= =?utf-8?B?TGtMcWxMUDVjc2w2V0R3ZnorZUg3MDU0RjVaWXI0R3RBSm85Mkh1MDJGVEla?= =?utf-8?B?SUFweFQ4Q081enRUaXZtY2oyM0J0b2dIT2I1cWtSSXZ1V1ZYcHhHeDBOMWxE?= =?utf-8?B?YXJQMTdTMFhWbi8zNklqZ09rYmFlQml3c0xUOEg1eWZGcXE1OFBiSGw3RHJB?= =?utf-8?Q?xE6PkxVbrWsyd4+jrA=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: combitech.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR0302MB3363.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fa3c6cff-bd18-4445-55f0-08d940466502
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2021 06:22:13.4577 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0d11ac4a-ef5e-423a-803b-e51aacfa43d6
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: qAXx+p1LwU8t9BVAOFe/5+hxO/qUmg7gUrcPSSgWIfmJpyGbg5cair1Jgyt6Rw/jTgN6yBr/4BeFJfM78GNjy1U6CMWLqJGPKmMA/pwf8eg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB4514
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/wWR-FmuIpdhkI2IOrh1zniHzo04>
Subject: Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)
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, 06 Jul 2021 06:22:24 -0000

Hello Francesca, Carsten,

Sorry but I do not like what you did in the first sentence. Combining profiles does not necessarily equate to creating a new one, and I still don't see why we should needlessly request that it be so. Given an example use case where a client talks dtls-profile to the AS and gets token and parameters for an oscore-profile back for the client-RS leg, why should there be a need for a new profile to support this?

I also do not like that you removed the requirement to design profiles so that the security for the different legs of the communication (C-AS, C-RS, RS-AS) stands on its own.
What could happen now is that someone designs clever protocol foo that has a dependency between the C-AS and the C-RS communication for its security, and thus breaks when it is used on only one leg of this communication. I don't think you need to know all possible future profiles to design yours to be secure in that way. Note that the framework puts requirements on the security of future profiles, so you can assume e.g., that communication will be secure.

I propose the following alternative for discussion:

NEW^4:
There may be use cases where the transport and security protocols defined by different profiles are used for different steps of the same authorization flow. For example, an implementation could use the CoAP-DTLS profile for interactions between the client and the AS, obtaining the token and parameters for an OSCORE-profile interaction with the RS.
The security of a profile MUST NOT depend on the assumption that this profile is used in all steps of the authorization flow (C-AS, C-RS, RS-AS). 


/Ludwig

-----Original Message-----
From: Francesca Palombini <francesca.palombini@ericsson.com> 
Sent: den 5 juli 2021 18:59
To: Carsten Bormann <cabo@tzi.org>
Cc: Ludwig Seitz <ludwig.seitz@combitech.com>om>; Daniel Migault <mglt.ietf@gmail.com>om>; Cigdem Sengul <cigdem.sengul@gmail.com>om>; Göran Selander <goran.selander@ericsson.com>om>; ace-chairs@ietf.org; ace@ietf.org
Subject: Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)

Hi Carsten,

I like your proposals! I changed a "define" to "specify" to remove some repetition, so finally the text change would be the following:

OLD:
   There may be use cases were different profiles of this framework are
   combined.  For example, an MQTT-TLS profile is used between the
   client and the RS in combination with a CoAP-DTLS profile for
   interactions between the client and the AS.  The security of a
   profile MUST NOT depend on the assumption that the profile is used
   for all the different types of interactions in this framework.

NEW:
   There may be use cases where different transport and security protocols
   are allowed for the different interactions , and, if that is not explicitly 
   covered by an existing profile, it corresponds to combining profiles into a new one.
   For example, a new profile could specify that a previously-defined MQTT-TLS profile is used between the
   client and the RS in combination with a previously-defined CoAP-DTLS profile for
   interactions between the client and the AS. It is REQUIRED of the new profile to specify the
   combination and to make sure interoperability and security properties are achieved.
   A profile MAY want to prepare for being combined with others by clearly specifying 
   its security requirements.


Francesca

On 05/07/2021, 16:36, "Carsten Bormann" <cabo@tzi.org> wrote:

    On 2021-07-05, at 16:15, Carsten Bormann <cabo@tzi.org> wrote:
    > 
    > The last sentence is kind of obvious (I hope that the same applies to non-combined profiles), but Section 6.7 is short, so a little superfluity does not hurt.

    In offline communication, I have been reminded that adding this sentence would appear to be appropriate :-)

    NEWNEWNEW:
    A profile MAY WANT TO prepare for being combined with others by clearly specifying its security requirements.

    (Using an RFC 6919 keyword.)  I wish I didn’t have the strong feeling that this sentence may actually be required.

    Grüße, Carsten