Re: [Ace] remarks on draft-tiloca-ace-oscore-gm-admin-00

Marco Tiloca <marco.tiloca@ri.se> Wed, 15 January 2020 17:21 UTC

Return-Path: <marco.tiloca@ri.se>
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 C630F120885; Wed, 15 Jan 2020 09:21:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.76
X-Spam-Level:
X-Spam-Status: No, score=-1.76 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_SBL=0.141, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.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 uTd_eGX7d300; Wed, 15 Jan 2020 09:21:07 -0800 (PST)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30040.outbound.protection.outlook.com [40.107.3.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 46D871208A9; Wed, 15 Jan 2020 09:21:07 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MM2ixrlbpgH3rWMEt+ZN5BCXnPkqoySIpUdvZ7foASvwICvbWYHMGYx/Pt0Rz31lTXmkBhfh02AD36tFVfnIwW+/KPk/nhSjkfn7j5yWlB/N2XhOOmktbh6M7GyRp6IbfBuOCh8qSArmib3OfZ1NCPQEw+hICkWHFrfxXGy8L8PcB68xCynSkxaQm2RKmucGOqJgDuoEzzAHDQMofOXFMm27fZk+vrV8KFzgCqQaheFYKkTvDQa8JIk/tELIynnE9O+UrqmMpF+cCW/zOAYpYl8Obnr0etaGdnUu+pTpaWMKyKJWzkJLgppZszjug/u9nX3/cJjJooYC1qtVN2ihbg==
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=90xPxXPr+MoxJIFYvQeIKDRR/m2mbnOwHUGOicrehjs=; b=X9SRaaUS/xGqLL32m/kFCO8bDjyJg5USJdw5zS3tbLG7Rpbgm2xmyfUdl5s6YsPyNa3VLwqgAWrP5Wx+kfpO8EfUL05S8oI33pVGhq1OMCUOP/2m6MyD5NB4zhX76BJgibWKD/itXtZJqCxCdGioZbe23VByQu9omFz0VDdbX+W9huIFM8fYd56s5MDK6u+K4fKhUubNgqyeyqttnkJhvGIkxuzTBfqE7uUs+VzKGK/3CsbHCM0jLyWhAlfBYkf5Pwpcr5O1GnDelX8/0zNThvkIN+7ewrEUcwEujZIw1oJILAtAGlfW//Mup1/5L6P/fJ+b/6+b9mi2quwL2zgNOg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=90xPxXPr+MoxJIFYvQeIKDRR/m2mbnOwHUGOicrehjs=; b=JQTR/syY6A4wHLKeU4AT3c3zPNI4OxGdek3d4ssR90TOt3yk86X8aNTo5iwzROk932WXHbAlKsbslZ/UFhT1GsHnbY9olz4C9TLj9pRFoIOd9tHv4n1/1YGyyAEgUeQcUqghANmHVOKCsa+85KBEqkflGXZKoj2D9XaJoEw3ymI=
Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (10.165.195.159) by VI1P189MB0478.EURP189.PROD.OUTLOOK.COM (10.165.189.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.10; Wed, 15 Jan 2020 17:21:04 +0000
Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::3485:ce83:891b:469]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::3485:ce83:891b:469%4]) with mapi id 15.20.2623.017; Wed, 15 Jan 2020 17:21:03 +0000
Received: from [10.8.8.24] (196.196.244.5) by HE1PR1001CA0002.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:3:f7::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.20 via Frontend Transport; Wed, 15 Jan 2020 17:21:03 +0000
From: Marco Tiloca <marco.tiloca@ri.se>
To: Jim Schaad <ietf@augustcellars.com>, "draft-tiloca-ace-oscore-gm-admin@ietf.org" <draft-tiloca-ace-oscore-gm-admin@ietf.org>
CC: "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] remarks on draft-tiloca-ace-oscore-gm-admin-00
Thread-Index: AdWfJkCd54YEkIoYSoqR2Q9ieECPkwnF3wsAAKzrB4AAta7/gA==
Date: Wed, 15 Jan 2020 17:21:03 +0000
Message-ID: <ce2e9771-b73a-2fd9-0188-c17a3c3f19cf@ri.se>
References: <01b401d59f2e$ff406560$fdc13020$@augustcellars.com> <a5e579e1-a1cf-ab20-4af7-38d54ee6cf3a@ri.se> <000001d5c8f1$6b0c7630$41256290$@augustcellars.com>
In-Reply-To: <000001d5c8f1$6b0c7630$41256290$@augustcellars.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-clientproxiedby: HE1PR1001CA0002.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:3:f7::12) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=marco.tiloca@ri.se;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [196.196.244.5]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: cd6e3252-b632-41b1-fc56-08d799df4c67
x-ms-traffictypediagnostic: VI1P189MB0478:
x-microsoft-antispam-prvs: <VI1P189MB0478CCFA72520AB04F79B93E99370@VI1P189MB0478.EURP189.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:983;
x-forefront-prvs: 02830F0362
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(136003)(376002)(396003)(346002)(189003)(199004)(26005)(186003)(44832011)(31686004)(956004)(66574012)(81156014)(16526019)(66556008)(2616005)(31696002)(66616009)(66476007)(30864003)(5660300002)(81166006)(64756008)(66446008)(71200400001)(8936002)(4001150100001)(16576012)(5001810100001)(478600001)(110136005)(316002)(4326008)(52116002)(8676002)(966005)(66946007)(53546011)(6486002)(86362001)(36756003)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P189MB0478; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ri.se does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: WBKbnpPI4Tv2Fp3ve8Ndsc374+Ec1B4gXmEO/S4TvqJASvlu2fZhcQNcEUo9tKhACwScxByNcVV+ItmRH2YyTDg5fbSgduiaLqs1stxpNBwdeXo7YKZyxcRayl1tes7OuPZON6HnmAU2Fb8lhmoo0JEe4im0RK0VGqCQJCjV6YLfN+0alh06WYiBSOBeeuquhbnNgQlujWOrBAmfrGr1WXCzMXa5c0VGFPZHJF1oANjvZmsGUHHTC66BRNuNydRuSP6PcinDKM42+RiXztYYOj60FE+kMcBd9ury5IPoZ3cSMdlr4VeJnhoPxggkSmwvn2t6s5FavT7LmDgE6R3TK5wwP/SykKEZcV6g54x1gdS5Xzdb/jxyvDX8uSH8bEBPDa4mjeHugcy5skyLMl3N2smg07NISeDwIyTJltD5lRBsCzYx1lIzni6WiBZfYZc+BIZ5nOE+qkctIQAkvomwuCGLRgPgVhSe5e0/afihe9M=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="MHeBmcVC2eiWX5u4bAeVeuMUrwcYk9OmA"
MIME-Version: 1.0
X-OriginatorOrg: ri.se
X-MS-Exchange-CrossTenant-Network-Message-Id: cd6e3252-b632-41b1-fc56-08d799df4c67
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2020 17:21:03.7942 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 1kwpYFpJEXRxZ1DXmihCeGuUFyvYuL2JOZmDL5A1+owoijkhCQ+8ALhgLua4D9Yx0wGsABJQwdDw0BJPK8X8nA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0478
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/j9axVukcbMiOrCL-74S7IrsROYk>
Subject: Re: [Ace] remarks on draft-tiloca-ace-oscore-gm-admin-00
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, 15 Jan 2020 17:21:12 -0000

Hi Jim,

Thanks for your reply, see more comments inline.

Best,
/Marco

On 2020-01-12 03:38, Jim Schaad wrote:
>
> -----Original Message-----
> From: Ace <ace-bounces@ietf.org> On Behalf Of Marco Tiloca
> Sent: Wednesday, January 8, 2020 8:08 AM
> To: Jim Schaad <ietf@augustcellars.com>; draft-tiloca-ace-oscore-gm-admin@ietf.org
> Cc: ace@ietf.org
> Subject: Re: [Ace] remarks on draft-tiloca-ace-oscore-gm-admin-00
>
> Hi Jim,
>
> Thanks a lot for this review!
>
> We have been working on an updated version accessible at [1], which is already taking into account your comments on CoRAL.
>
> Please, find below inline some more replies and open points.
>
> Best,
> /Marco
>
> [1]
> https://gitlab.com/crimson84/draft-tiloca-ace-oscore-gm-admin/blob/v-01/draft-tiloca-ace-oscore-gm-admin.md
>
> On 2019-11-20 00:13, Jim Schaad wrote:
>> This is just going to be a high level review on how things are done 
>> rather than a detailed review on each line of text.
>>
>> 1. - Go and read that CoRE Pub-Sub update document - you know the one 
>> that Klaus and friends have not managed to get written since the model 
>> proposal was done way back when.
> <MT>
> Yes, we are now relying on an akin interface, along the lines of the now published draft https://datatracker.ietf.org/doc/draft-hartke-t2trg-coral-pubsub/
> </MT>
>
>> 2.  Re-write this to use CoRAL - Yes I know that this makes another 
>> dependency on getting it published from the CoRE group, but I don't 
>> want to do things multiple times.
> <MT>
> We have now also added examples in CoRAL, for all the interactions between Administrator and Group Manager, now also extended with FETCH for filtered retrieval.
> </MT>
>
>> 3.  I think that this document really needs to be able to be used with
>> HTTP/JSON as well as CoAP.   If you can get the JSON version of CoRAL from
>> Klaus then this falls out without any work.
> <MT>
> We are now saying the CoRAL examples are in text format, but they are in CBOR or JSON on the wire, with no particular additional effort. Is this enough?
> </MT>
>
> Sounds good.
>
>> 4.  Are you making it a requirement that the group name be the same as 
>> the group identifier assigned by the "group_name" parameter?  If so 
>> then having some type of title and description would seem to be almost mandatory.
> <MT>
> They are in fact the very same thing. The "group_name" parameter specifies the group name, as intended to identify the OSCORE group both by the administrator and the joining nodes in the other related documents. We can use only "invariant name" rather than "invariant identifier". Are we missing something? If so, what do you suggest we should give a title and description to?
> </MT>
>
> If you are looking at "group_name":"GP00123", then as a configuration agent it is difficult to know just what this group is supposed to be.  In this case some type of title or description helps to figure that out.

<MT>
We can add a new group configuration parameter 'group_title', as a CBOR
text string. This specifies a human-readable descriptive name of the
group, suggesting what it is about.
</MT>

>
>> 5.  There needs to be some parameters around pointing to the correct 
>> AS and so forth.  The management API may reject because it does not trust the AS.
>> Don't assume that this is a single value for the AS either.
> <MT>
> This is good and also aligned with other related drafts.
>
> If we interpret your suggestion correctly:
>
> 1) The POST request to /manage may specify also an optional 'as_uri'
> parameter, with the link to a suggested AS. The GM may accept the suggestion or not. If not, it has to think of an alternative AS, as valid issuer of tokens for joining that group.
>
> 2) The GM must have one more parameter in the group configuration with the effective AS URI, i.e. either one provided by the administrator and accepted, or one otherwise decided.
>
> Do you think of any additional related parameters to be included in the POST request, other than 'as_uri'? Perhaps the public key of the suggested AS if applicable?
>
> Do you think the suggestion in the request should actually be a list of AS, out of which the GM may pick up at most one?
> </MT>
>
> I have put something into draft-schaad-core-reef which starts thinking about this.  I think that we need to sit down and do a brainstorming session to figure out what items should/should not be put into such a structure.
>

<MT>
With pleasure, and thanks for the pointer :-)

Out of my hat, I can think of: the URI of one AS and its /token
endpoint; the profile(s) that the Group Manager have to use (if it
supports them) for letting joining nodes enter the group; the public key
of the AS if applicable; the ACE audience that the Group Manager has to
use for this group.
</MT>

>> 6.  You are missing a lot of management detail on the POST to the 
>> group node.  Some of the things that are missing would be:
>> a)  Is the group active or inactive
> <MT>
> We can have one more parameter on the group-configuration resource for this.
>
> We are interpreting active/inactive as follows. Ideally, upon creating the group, the request can specify the initial status as active or inactive. Upon later updating the group by sending a request to the group-configuration resource, the administrator can change the status (or read it through a GET).
>
> Then the active/inactive status has two parallel scopes:
>
> 1) one scope is for the GM alone, i.e the GM would allow the joining of new group members only if the group is set as active.
>
> 2) when the group is set as inactive, the current group members should refrain from sending and should not expect receiving any message protected with that group key material. However, there is no way to actually force them to.
>
> In support to scope (2), when the status changes to inactive, the GM should inform group members about that. To this end, the group-membership resource intended for group members would also include a parameter reflecting the group status and aligned in value with the one in the group-configuration resource. Then, there are two ways to inform the group members of a status change.
>
> a) A way is to have the group members observing the group-membership resource (that they may have been doing already anyway for notification-based rekeying).
>
> b) A second way is for the group members to have a dedicated local resources for this (and other) kind of control communication (e.g.
> rekeying). This is something we are also considering in
> ace-key-groupcomm(-oscore) for receiving individual rekeying messages.
> In either case this would require either: i) each node to provide the GM with the URI to such local resource, in the join request; or ii) the GM to include in the join response to each joining node a same multicast address targeting a local resource that that node has to create to receive control messages.
> </MT>
>
> I don't remember for sure what I was thinking about when I wrote this.  I think that I was more interested in if one can or cannot join a group when it is inactive and what happens.  If you set a group to inactive, are all members of the group removed or does the group just stop issuing new keys?

<MT>
Building on the previous reply, an inactive group would mean that: i) no
new members are admitted, thus no new keys to new members; ii) stop
issuing new keys for current members; iii) current members are expected
to stop communicating (which should rely on informing them) but are not
removed. So the group is temporarily inactive but still exists.
</MT>

>
>> b) How does the server react if you change a the content encryption 
>> algorithm, is this a simple re-key operation or is it more complicated
> <MT>
> An easy answer would be rekeying the group, just as for any other triggering reason. I agree this should be mention in this draft.
>
> However, I think a more elaborated description of what happens if the algorithm is changed (regardless why and how) should be actually better given in oscore-groupcomm (the what) and in ace-key-groupcomm-oscore (the how).
> </MT>
>
> Punting to a different document is fine as long as it really is there.  However, this is the place where it appears to be changed by an external source and thus seems to be a good place to talk about it.

<MT>
Agree, this document is in fact acting as a use case of its own for this.
</MT>

>> c) How does the server react if you change the signature algorithm?  
>> This would seem to be a much harder thing to do if the group is not 
>> empty or not active as everybody is going to need to re-join.
> <MT>
> Right. If the signature algorithm changes, the current public keys may be not compatible with it any longer. We see the following possible ways, assuming the current group members have learnt of the new algorithm in use.
>
> 1) The hard way, i.e. everyone leaving and re-joining.
>
> 2) A more lightweight way, i.e. relying on yet another operation for current group members on the GM, to upload a new public key consistent with the new algorithm. This would require to proof possession of the corresponding private key, as it is done upon joining. Probably, in this case, this can happen like we do in the Group OSCORE profile of ACE between the Client and the AS, see the bullet point on 'client_cred_verify' at [2].
>
> And again it looks like details on the way this is done fits better in other documents.
>
> [2]
> https://tools.ietf.org/html/draft-tiloca-ace-group-oscore-profile-01#section-3.1
>
> </MT>
>
> See comment above.

<MT>
As above, yes, something should be said here. Formally, the extended
keying material is distributed as in a rekeying, but the only difference
would be the signature algorithm. This is enough for the group members
to understand what happens and what to do.

If they leave and fully join again, it's just about following the same
procedure of ietf-ace-key-groupcomm oscore. The alternative (2) above
would require one more functionality exported by the Group Manager for
current group members to upload a new and compatible public key (and
this has to be followed by proof-of-possession). This may be achieved
with a new PUT handler to the group-membership resource
group-oscore/GROUPNAME/pub-key (see
https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-04#section-8
)
</MT>

>
>> d) Other parameter that are changed may be just as bad as changing the 
>> signature algorithm - how the re-key is done jumps immediately to mind.
> <MT>
> Yes, changing HKDF/Alg results in what discussed two replies above; changing anything else (thus related to signatures) results in what discussed in the reply above.
> </MT>
>
> Much of this may go to say that changing this parameters kicks everybody off the group and restarts from scratch.

<MT>
It seems better to leave the burden of a clear decision to the
Administrator. That is, if the Administrator has good reasons to update
those parameters, even though a rekeying will follow, so be it. Or, the
Administrator can delete the group altogether and create it again, if
believed to be better.

On the other hand, it sounds better to avoid that the Group Manager
itself decides to delete a group.
</MT>

>
>> 7.  Is there currently any way for a KDC to signal to all of the 
>> members that have joined that the key group no longer exists?  A 
>> DELETE would seem to indicate the need to be able to do this.
> <MT>
> Right, the DELETE of a group-configuration resource would trigger something like this. The current resource maintaining on the GM consists
> in: destroying both group-configuration and group-membership resource, then reply to the Administrator.
>
> That said, a possible extension to also inform current group members is akin to what we describe above about signaling that the group has moved to inactive state. That is:
>
> i) if group members observe the group-membership resource, a 4.04 notification is sent to them, upon deleting that resource.
>
> ii) if group members have their own local resource to receive control messages from the GM, a control message can inform about the deletion of such group-membership resource. This would be particularly convenient to be sent over multicast. This method (ii) would actually require the GM to send these messages to the group members first, and only afterwards actually delete the group-membership resource, in case information such as the destination addresses and URIs to consider are stored as part of the group-membership resource itself.
>
> A group member can of course discover what happened at any time, just by sending any type of request to the deleted group-membership resource and getting a 4.04 response back.
>
> The actual difference between an existing inactive group and a deleted group is that the latter has no way back, and would need to be re-created from scratch on the GM by the Administrator.
> </MT>
>
> Also could say that you can only delete a successfully inactivated group.

<MT>
Ok, this has two consequences:

1) We can add one more group-configuration boolean parameter 'active',
that the Administrator also controls.

2) Before issuing a DELETE to delete a group, the Administrator has to
change 'active' to FALSE, and get a confirmation response from the Group
Manager.

However, I wonder what you mean with "successfully". What can make the
Group Manager fail/hold from changing 'active' from TRUE to FALSE when
requested to do so by the Administrator?
</MT>

>
> Jim
>
>
>> Jim
>>
>>
>>
> --
> Marco Tiloca
> Ph.D., Senior Researcher
>
> RISE Research Institutes of Sweden
> Division ICT
> Isafjordsgatan 22 / Kistagången 16
> SE-164 40 Kista (Sweden)
>
> Phone: +46 (0)70 60 46 501
> https://www.ri.se
>
>
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www.ri.se