Re: [Ace] Review of draft-ietf-ace-key-groupcomm

Francesca Palombini <francesca.palombini@ericsson.com> Wed, 06 November 2019 12:49 UTC

Return-Path: <francesca.palombini@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 14B9212088B; Wed, 6 Nov 2019 04:49:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 Ebk3E7sdnRdN; Wed, 6 Nov 2019 04:49:48 -0800 (PST)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10045.outbound.protection.outlook.com [40.107.1.45]) (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 DDB36120888; Wed, 6 Nov 2019 04:49:47 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jQ+crIij59/ji3U8KiJgRtT8gin+v84a3/5YYmCsk1jl+tSdFtyr6Aj4aG4qe0n1jtTRAWFRMN4AvnpJqA1hwnALo/HcjLj1Jnk0EPgd51q2ZBEpavvxGaZc6Xi88QmCXsAbkR5RUBMhlmZHuKI1YgUwaBj6BpW+NpjFun9iwLCUNLRKG/xTmu49JBC0ukee2kRFm+sni02WSr1EMLCsFgUnZKQY/5aIml9/5e3WKKfQf8Ong9a2m75Tg1sG7a7HZdORXamLv4s00hGgdLEr07KAF1ISka5jm1XcLpivDZxxdT6LdOFVJjk9D/t9cxm8CPFAhDCumXyBo8DKkw83YQ==
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=g8SMFmuT/9eFU3DG0WXBB6FQdscB6hzVpgyUwRvYORs=; b=AaIyvDykI3iNa4ZB2m7uuCUjbFYtXsJw9X0izVYklBgWO1uikRTrt7Ai3O23EPj2TR78G0iipw5Z5rUsY4/ckiscDndfzHel7oZonxSSQI9EkSykdFeUIi8VILPjXyXdwHAX5IwZpBBdQTHtvVs6VvNFX8IYFBrRUl2OJ3Xuua434XIAtxox1dlv6L6Z5jr1IbGeFupj5bOHd1nmG8LDMalXra4SIQ/KWC3Nwh3WFuE5+cuPsyHBIIaYkMgu22I3W8IhlMoiotsYZmG/O2KOo9ovLG+JUG6oU+muCETBb8qXjpIGvoor4I1/sWnVZyDAEUnUjJDO7iIbh8CAPg7OwA==
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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=g8SMFmuT/9eFU3DG0WXBB6FQdscB6hzVpgyUwRvYORs=; b=BKImzeYgA+julTt2MijKxZnKCuVh8yfKpNcIticKCunakQyGaYVRvAOvdNvrOXqDuuWFmCk9I8ZoISoJqHoHybO9WthvCk1utDQBrIQc58BZEPsiUVqqIF5E01XD4AwAXWyGUe6C7SfWJ+banF6lN0gS/Y1bipWpL+mtQsaBs5E=
Received: from VI1PR07MB5469.eurprd07.prod.outlook.com (20.178.14.214) by VI1PR07MB6157.eurprd07.prod.outlook.com (20.178.120.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.13; Wed, 6 Nov 2019 12:49:44 +0000
Received: from VI1PR07MB5469.eurprd07.prod.outlook.com ([fe80::a8d5:a784:a19:5c76]) by VI1PR07MB5469.eurprd07.prod.outlook.com ([fe80::a8d5:a784:a19:5c76%6]) with mapi id 15.20.2430.017; Wed, 6 Nov 2019 12:49:44 +0000
From: Francesca Palombini <francesca.palombini@ericsson.com>
To: Jim Schaad <ietf@augustcellars.com>, 'Ludwig Seitz' <ludwig.seitz@ri.se>, "ace@ietf.org" <ace@ietf.org>
CC: "draft-ietf-ace-key-groupcomm@ietf.org" <draft-ietf-ace-key-groupcomm@ietf.org>
Thread-Topic: [Ace] Review of draft-ietf-ace-key-groupcomm
Thread-Index: AQHVPiQplIgMsLYvtU2keDvcPHncYabYL4uAgKamQoA=
Date: Wed, 6 Nov 2019 12:49:44 +0000
Message-ID: <9F48C1A6-5F79-411D-AB1F-11FDB891EEBF@ericsson.com>
References: <7000332e-9853-fcc5-c98f-b2d8f2fb4060@ri.se> <01aa01d54155$eef81900$cce84b00$@augustcellars.com>
In-Reply-To: <01aa01d54155$eef81900$cce84b00$@augustcellars.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com;
x-originating-ip: [158.174.219.143]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2ecebc36-37a8-405e-8a05-08d762b7cc50
x-ms-traffictypediagnostic: VI1PR07MB6157:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <VI1PR07MB615723BF19F450181C61613698790@VI1PR07MB6157.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02135EB356
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(39860400002)(376002)(136003)(346002)(199004)(189003)(13464003)(478600001)(66066001)(966005)(71190400001)(71200400001)(86362001)(14454004)(26005)(6512007)(6306002)(476003)(186003)(4326008)(2616005)(5660300002)(25786009)(2501003)(64756008)(66946007)(91956017)(76116006)(66556008)(66476007)(66446008)(2906002)(305945005)(7736002)(81166006)(6116002)(3846002)(6486002)(36756003)(6436002)(11346002)(446003)(44832011)(8936002)(486006)(8676002)(110136005)(33656002)(102836004)(6246003)(99286004)(6506007)(53546011)(316002)(14444005)(81156014)(76176011)(256004)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB6157; H:VI1PR07MB5469.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: gK0DLRpW6iaBHm/roMoNyBRsSW6GYyrw/V7mqT4CQVn28l8XhJataYc1oxYfpv68Mb4Td+OH2XPI+IAnFRvqlGBm0qPjpEB+m8xU7dVy5lD9aIanrTl41PS+TLvNQVaM735H1A0CcFjVamHNMzmPy9HECeAGUi5DMRygyChi/1iriZymTYbJXyM8JO4zBmDMPQjjJ4fCgl0mezrIQOpYiG+SIqSIcfTr1Q1nGo+JyZWZrZFfadsYbl4Hj1wxxqotG/CEI3m7140bihrgAZu103Nl6cfV2azjvzFjAS1Ix6ZqB2MNzc2UTwp5bOMJ82rdOLrRRQzv1GuEfT0HxaCSPDwPUYrlc/W/5gDPAcciRJYrzsbc2qg6KN/Y1Ls8PaLTAPcblS0IiMsBKKar7lNI9Qg2X2jZmIyx9trpObyU2mmlvRh5Y0g+VZBMoB08ILIP86DuLkb4y7hpRLrN2lis6cyC5DKnFtFJWu0xz12lhm8=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <2E9627ACB09D7546B254BF1AAE8C5E40@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2ecebc36-37a8-405e-8a05-08d762b7cc50
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2019 12:49:44.2192 (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: TtHKwPtXnBTF+md3h8Vd2xjXR5ANFHoDSD6EVEZitmEGQQSRn1SmI2si2te7pnGy2VTCJVJzVJoO7E29hKGIChLUJO8PSE540p3YKA+5hIGWRO672VF40PyLvhKqv1FV
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6157
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/1lApkud1cc54BpaI2NT1QxIGF0M>
Subject: Re: [Ace] Review of draft-ietf-ace-key-groupcomm
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: Wed, 06 Nov 2019 12:49:51 -0000

Hi,

Answering the one issue left from Ludwig's review, including Jim's reaction inline.

Thanks,
Francesca

On 23/07/2019, 14:56, "Ace on behalf of Jim Schaad" <ace-bounces@ietf.org on behalf of ietf@augustcellars.com>; wrote:
    
    -----Original Message-----
    From: Ace <ace-bounces@ietf.org>; On Behalf Of Ludwig Seitz
    Sent: Friday, July 19, 2019 7:22 AM
    To: draft-ietf-ace-key-groupcomm@ietf.org
    Cc: ace@ietf.org
    Subject: [Ace] Review of draft-ietf-ace-key-groupcomm
    
    Hello Francesca, Marco,
    
    I have finally managed to read the whole of draft-ietf-ace-key-groupcomm and have a few comments for you:
    
    
    ==
    5.2
    
    "If the leaving node wants to be part of a group with fewer roles, it 
    does not need to communicate that to the KDC, and can simply stop acting 
    according to   such roles."
    
    There are legitimate cases where a node might want to explicitly 
    deactivate roles it is currently using (principle of least priviledge) 
    and not just stop using them.
    
    [JLS] I trimmed because I only wanted to address this one topic.  I totally agree that there are cases where a node might want to deactivate roles, however in the case of group communication I don't see how this could be done in a reasonable manner.  
    
FP: I agree with Jim that I am not sure this can be done "in a reasonable manner" (where reasonable means "worth the effort").

    If a node says - please stop advertising my public key because I am no longer a publisher, that is reasonable for a KDC to start doing.  However, there are currently no provisions in the protocol for a KDC to advertise that fact to all of the subscribers.   Even if a key roll over were to occur, as the node still is part of the group, it can produce the correct key material and sign a message.  A subscriber with the signature key would successfully validate the signature and accept it the message, only those subscribers which had not yet pulled down a public key would fail to validate the message.
    
    This would require a new mechanism for the purpose of asking if a public key is still associated with a specific key identifier (which is a good reason for the note about keeping the same key ids when rolling keys).  I am not sure that the traffic would be worth the effort for this small gain.

FP: The KDC keeps track of nodes being in the group now, and for each node it has an associated token with authorization information, so the KDC knows what roles each node has within the group. A possible new mechanism to solve this would be: we could add
*  an (observable) resource at the KDC that allows any member of the group to get information about nodes’ roles, say POSTing an array of node identifiers to the KDC and getting back the roles, or observing it and getting any changes it might happen, and 
* another resource where a node can POST updates to its own role
But I am not sure that is very useful/worth the effort vs the amount of traffic generated. The node requesting to “leave a role” could still request to “get the role” again, if it is still authorized to do so (for example, a publisher could decide to suddenly only be a subscriber, but could still get back its publisher role if it wanted to). I am interested in hearing more opinions about this (“no we don’t need this” “yes we need this and why”).

    
    Note that for a gated transmission system such as a pub-sub server, the node can get lesser privilege for the gate system without getting less privilege for the KDC.
    
    Jim
    


 
    /Ludwig
    
    
    -- 
    Ludwig Seitz, PhD
    Security Lab, RISE
    Phone +46(0)70-349 92 51
    
    
    _______________________________________________
    Ace mailing list
    Ace@ietf.org
    https://www.ietf.org/mailman/listinfo/ace