Re: [Ace] Comments on ace key groupcomm -01

Francesca Palombini <francesca.palombini@ericsson.com> Mon, 29 October 2018 08:48 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 15342130DF6 for <ace@ietfa.amsl.com>; Mon, 29 Oct 2018 01:48:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.77
X-Spam-Level:
X-Spam-Status: No, score=-4.77 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=KwNSMpqI; dkim=pass (1024-bit key) header.d=ericsson.com header.b=WO3GY1co
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 CzPOELAsFNoA for <ace@ietfa.amsl.com>; Mon, 29 Oct 2018 01:48:24 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 1CAC3130DF4 for <ace@ietf.org>; Mon, 29 Oct 2018 01:48:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1540802901; x=1543394901; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZYuV73c9MKuTNhhsH+wOdIavxQh8Ob8hx6rNvLdRvac=; b=KwNSMpqIWYnDr3Lf9oDYYsrNz/BzkpjW8mSXlLCj7cMGG4TZ1sskarBYamq5CV9q II72J1ZrfDSMhCIx+9ozCUVNbdtIZ10gcPoSkyfGw9G5K9a9YSrQh33cIDqnfCCY f7rDYExF+JdfIonPnc3KPRKocH5jSnqt9P3vGjPjnBg=;
X-AuditID: c1b4fb30-671b09e000007d19-8a-5bd6c955d38f
Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D2.A3.32025.559C6DB5; Mon, 29 Oct 2018 09:48:21 +0100 (CET)
Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 29 Oct 2018 09:48:20 +0100
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 29 Oct 2018 09:48:20 +0100
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=ZYuV73c9MKuTNhhsH+wOdIavxQh8Ob8hx6rNvLdRvac=; b=WO3GY1coQTCJ5C7f0o2bQk9uoD+1RspDPz62UILcbdBGGG0iltdK0Jmr1qgHEAGL7DK3Kbs2C2nK3nDFgfW49HEr6rk1KFJ9jEQRPOjp3MuOpwOC3PT7xlB9LOBrEQPayBzfQQXdqYeUSqAU/XbTpJ4qWGC9ZTaZDSflpcrc/kc=
Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.188.140) by HE1PR0701MB2556.eurprd07.prod.outlook.com (10.168.187.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.14; Mon, 29 Oct 2018 08:48:19 +0000
Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::5d31:ff09:b9ba:29c3]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::5d31:ff09:b9ba:29c3%9]) with mapi id 15.20.1294.015; Mon, 29 Oct 2018 08:48:19 +0000
From: Francesca Palombini <francesca.palombini@ericsson.com>
To: Jim Schaad <ietf@augustcellars.com>
CC: 'ace' <ace@ietf.org>, "draft-palombini-ace-key-groupcomm@ietf.org" <draft-palombini-ace-key-groupcomm@ietf.org>
Thread-Topic: [Ace] Comments on ace key groupcomm -01
Thread-Index: AdQaKsDewY+WehuqT9eenvy1Jp1rRxVQcQsA
Date: Mon, 29 Oct 2018 08:48:18 +0000
Message-ID: <AA38ECA9-5946-4624-9BA9-8BC30D95727B@ericsson.com>
References: <013e01d41ad8$b2ce7540$186b5fc0$@augustcellars.com>
In-Reply-To: <013e01d41ad8$b2ce7540$186b5fc0$@augustcellars.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com;
x-originating-ip: [192.176.1.80]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2556; 6:ZElik2LecwyGmNk8w09U6db4j0yQrogrJBolvn98ClMZLg3oNq5yu9Nr4sfXgVPNHkcuCAgBeCjNbNU/TBMNSrKuo6KMA6H3Ft0XjIYM9drk5danPBvpRDzMeHNTve4H6mJGXgmLXeiYThvztqI3PlB2j/oXNN3X/y/vGs1BPIBhcubOFbmQ5Ir76OtInBNYE8XAp0goe9Gu37uJpXI+9hNNm2jk3plgNYMaGbXLjCRLE+BitxzTE35+WifUQKklDlzK1FyVksvdUf5JblBfjUxnS6iLNbEP2hDbR17eJVGnm6MtxLsLKvK6glDHUWEZCaR2xiPmJ3fEPl5HdYlZZdQZ/TICATUo12POWmffA24X02a+61q/zIVmhwLIerDGQIsu7rVg4COvxxTwXZ0QQvSdMvap5uIj/1xKjLt4bsTp0pjSsTGlJUmdJYFuA60ySFq+yg4cTvZqfMwsZmfA2w==; 5:H4IhHzrYNASnooYmyzID5r9zUx4ll4APJ/eJP1cx5X75UWRx3eNnv93l7Uy27EwWGGdaATd5J0yjZ8wfRCXrX8doDXBmty6gI4pMxujvKQB1lsTp1RaQV9I5+QIYqXC6/A8/fglEzzPhBZnqfV5MaD+kANWrDL8PLNXuT8CL95w=; 7:ZUvSxg+RPJoCGtS/7ED6wkG6xCzgv3Hrc8UwxofZfzMB9/7hy6dxAjrBlvJ2lTjgOyw07F4PVLChJlv8gHU8DhiQFrOzfrrb+k5T95LsP89h/qpfAcHrsBue9d/xxHKYEBYQnn/4jVTrGv9MZ+scFw==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 2b83e63f-95d6-46ee-0179-08d63d7b4665
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2556;
x-ms-traffictypediagnostic: HE1PR0701MB2556:
x-microsoft-antispam-prvs: <HE1PR0701MB25561C30A16F754F446C7CB598F30@HE1PR0701MB2556.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(190756311086443)(192374486261705);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231382)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:HE1PR0701MB2556; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2556;
x-forefront-prvs: 084080FC15
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39860400002)(136003)(396003)(366004)(189003)(199004)(186003)(82746002)(305945005)(44832011)(7736002)(86362001)(25786009)(81156014)(81166006)(8676002)(26005)(6506007)(106356001)(2900100001)(4326008)(256004)(102836004)(229853002)(105586002)(316002)(8936002)(68736007)(11346002)(446003)(476003)(486006)(2616005)(14444005)(53546011)(54906003)(6916009)(36756003)(478600001)(6306002)(6512007)(66066001)(33656002)(14454004)(53936002)(76176011)(6436002)(5250100002)(6486002)(83716004)(71200400001)(3846002)(6116002)(71190400001)(97736004)(99286004)(5660300001)(6246003)(2906002)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2556; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: aKCoM9mvTrzMWpNGHv0C8zqtCL9R4PHLetmmDATnydHQd1e4mkUNYnIDDNhlnhP1G5RnEn/JFc43fzL+ATlokP7gn89HdaF6HKKkIrF/RKO4r5SPtOFQ3mELsxMpmjQGe6OkY+W/bmaBVmlWbcfya7lqdfK2r91Vbe3mIJAZwI7H8YIbFiOP2iQbwfL3rry6hirXsYaKae1SIt3ghalc76QgagKbhdwnZUlVQ4mYU3DhZbm1bER5HQPYSOKI8wTvMGpiKBOefFYM03DwmUicbw4ayUcwU2NlCXN7WS9dj0cAvSpWy0cO2R1wlLWyWlyxfXEBg9gto51GYe+wHsIwo4JBt4wS3VrQ9EtuZcQyqJg=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <9458E60D37D88D429B09C377DF48843C@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 2b83e63f-95d6-46ee-0179-08d63d7b4665
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2018 08:48:18.9550 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2556
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTYRTHed6br+Lwad4OpmKDCCMvrYx9sLSM2oduH8pEP7Spr7rSKXu9 pERMQ6NZZql4SVHsLchV3rVGId6oSZmoiLeilRQLSaOlpBltvhP69jv/8z//8xx4WFJaRfux Gm02p9Oq02WMG1Ub15sXcs48lRBuG3JXrK7cJBVFI4NIYaxeZaJJZXt9NaMUhN/EGSLeLTKZ S9fkcrqwQyq3tBvF3VTWUNzltpJpQo+aYg3IlQW8H5qfCLQBubFSPIRgseg2JRYrCDYm+kmx EAgYbBgkHAWFy0nQj0w7Z2oIqFx965z5gmDs+TDhSGZwJIxZlmgHe+Fd0G2c2dRJnAN9bY3I gFjW0769d85HtETAy6fXKJHlUNP1gXQwhXfCe1MJ5bBLcBSUdsc4ZKkdr3+f30x0xdGw3GFC DkY4AGyFRlLc5AuzC42EeCcG4cU7UmRvsH7+S4v+JJicK3MR9SAQbHecHADjjaXIcRbgaQbe dFgYsRECy1VVzqCTcP/TL0I0mREUCyu02NgDrZ1rzqRMMFVsDZ+AspoGSuRAaLllocqRvO6/ x9bZ7yRxMLSawkRZCRXfml1E3gGVpZZNluBtYK5doJoQ3YK8eY5PzEiVy0M5nSaJ5zO1oVou uwPZP0t/13r4M2T9engAYRbJ3CX+r6YSpLQ6l8/PGEDAkjIvCX5tlyTJ6vwCTpd5QZeTzvED aDtLyXwlilOd8VKcqs7mLnFcFqfb6hKsq58eGVIqPa0aZlH9o94SVDt7JTQ4Vu5xvGKd75T2 3J1UKU77PmxInuP6VI+jHpVWpdUZIwrX5j/eKzzPjC8lnp1uVZIJVn3ssFChlPaMqujAfQfj UtaObjwYMfsWhEzkhOWPWn/GBBxh9Cm2Yx6KvBn/qxcT/8QfmCj3i/TxWGw/I6P4NPXe3aSO V/8DBYOeVSgDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/-Nd8aRs-yUIoIP4KVMifW9MUf3o>
Subject: Re: [Ace] Comments on ace key groupcomm -01
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, 29 Oct 2018 08:48:26 -0000

Hi Jim,

Thanks a lot for your detailed review, as you might have seen we have included most comments in the latest version: https://tools.ietf.org/html/draft-palombini-ace-key-groupcomm-02 
Please note that this version includes also review comments from Peter, which in some cases overlapped, so some text might be reformulated to include both inputs.

Inline, detailed comments and some questions.

Thanks,
Francesca

On 13/07/2018, 20:38, "Ace on behalf of Jim Schaad" <ace-bounces@ietf.org on behalf of ietf@augustcellars.com>; wrote:

    * Section 2 - client  - write rights and/or read rights.  Unless you think
    that write implies read in which case you should state that
    
FP: Right, we now specify: " It can request write and/or read rights."

    * Section 2 - KDC - should also say what it does in the later parts -

FP: Ok, we added the following text: " During the second part (Section 4), which is not based
      on the ACE Framework, it distributes the keying material." We also added details about the role of the KDC for redistribution of keying material.
    
    * Section 2 - Dispatcher - If this is a bus, then you are not really
    communicating with it securely.  Anybody can write on it, but people will
    just ignore what comes out the other end.
    
FP: Right, reformulated in " entity through which the Clients communicate with the
      group and which distributes messages to the group members."

    * Section 3-  A brief description of all of the operations would be
    appreciated.
    
FP: we have now added several sections to describe the operations. In section 2 (starting with " This document specifies the message flows and formats for:") we describe the high level operations. At the beginning of each section (3. and 4.) we also give an overview of the exchange described in the subsections.

    * Section 3.1 - Can I get authorization for multiple items at a single time?
    
FP: In theory, it would be possible, and that would require to change the format of scope, going from [ group-id, [role1, role2] ] to [ [group-id1, group-id2], [[role1, role2], [role1]] ]. We haven't implemented this change, because it seems to cause a lot of overhead and complexity, for what seems to be a corner case. But if people think this is a valid use case, we can reconsider. We have added a placeholder comment in the md for this.

    * Section 3.1 - Does it make sense to allow for multiple audiences to be on
    a single KDC?  
    
FP: I am not sure I understand the scenario, could you expand on this? (We have added a comment in the md for this as well)

    * Section 4.x  - cnf - text does not allow for key identifier
    
FP: Did you get the section wrong? In 4.x we do not use cnf. In which section exactly would you send the kid in the cnf? That should be defined in the Ace framework (and params)...

    * Section X.X - Define a new cnf method to hold the OSCORE context
    parameters - should it be a normal COSE_Key or something new just to makes
    sure that it is different.
    
FP: This is the same comment as in the OSCORE Profile. Again, I am not sure why we really need a new structure since COSE_Key is general enough to transfer all the keying material, with the addition of the couple of new parameters defined. But if you think this is necessary, we can definitely change.

    * Section 3.X - I am not sure if write or POST is a better answer for what
    the role being requested is.

FP: Again, I don't understand this comment. We don't really define what one should use as role, write or POST are both possible.
    
    * Section 4 - Should one talk about the ability to use OBSERVE as part of
    key distribution?
    
FP: We added a comment as a placeholder for this in the md. Observe was just briefly mentioned before and not really elaborated. Although it would work, it seems not useful to have it together with a proper rekeying scheme where the KDC takes the initiative anyway.

    * Section 4.x - I am having a hard time trying to figure out the difference
    between a group and a topic.  The text does not always seem to distinguish
    these well.

FP: It was our purpose to keep the text high level enough so that it would apply to both. Does that create any problem/confusion?
    
    * Seciton 4.1 - POP on client key  esp if bound to an identity (Note using
    it to access the KDC is one POP)

FP: Now added the following text at the end of section 4.: " Note that proof-of-possession to bind the access token to the Client	
	   is performed by using the proof-of-possession key bound to the access	
	   token for establishing secure communication between the Client and	
	   the KDC."
    
    * Section 4.2 - why not use the exp field from OAUTH in the response

FP: the exp field from the AS in the response relates to the token. This exp relates to the keying material. Yes, when the token expires the keying material should expire (and that is specified e.g. in the OSCORE profile), but it could expire before/independently as well.
    
    * Question - does somebody talk about doing key derivation for a new kid
    showing up and by the way where is the gid
    
FP: It's in oscore-groupcomm that we describe how a new Recipient Context is derived. This document keeps a high livel perspective (so it does not talk about Gid), while in ace-oscoap-join we explain how the current Group ID is provided to a joining node (in the 'serverID' parameter of the COSE Key in the Join Response).

    * Seciton 4.2 - if you are using profile, then you should return it

FP: The Key distribution request and response, although inspired by ACE, do not use ACE, so "profile" is not really defined here. The profile is used in the first phase, between C - AS - KDC, and it is returned there.
    
    * Introduction - introduce the concept of a key management protocol and
    point to some.  Give some basic properties expected from one.
    
FP: Some text was added at the end of the introduction: "   If the application requires backward and forward security, updated
   keying material is generated and distributed to the group members
   (rekeying), when membership changes.  A key management scheme
   performs the actual distribution of the updated keying material to
   the group.  In particular, the key management scheme rekeys the
   current group members when a new node joins the group, and the
   remaining group members when a node leaves the group.  This document
   provides a message format for group rekeying that allows to fulfill
   these requirements.  Rekeying mechanisms can be based on [RFC2093],
   [RFC2094] and [RFC2627]."

    * Section 5.2 - What is the message to leave - can I leave one scope but not
    another?  Can I just give up a role?

FP: We have now added a TBD: format of the message to leave the group placeholder in Section 5.2. We will address this in a future update. The leave is intended per group, so one scope at the time losing all the roles in that group. Giving up a single role while remaining in the group does not require any particular interaction with the GM. It's just sufficient to stop behaving as that role.
    
    * Seciton 6.1 - assumes scopes are unique across all audiences.  Or assumes
    that I look up the correct token - should have an argument about why this is
    possible so that people can implement it right
    
FP: We already had the check for the access token for a first time key distribution. We have added the following text in section 6.2: "the KDC receiving a Key Re-Distribution Request MUST check that it is storing a valid Access Token from that client for that scope." We also have added a TODO: defines error response if it does not have it / is not valid. Would that be enough?

    * Comment somewhere about getting strike zones setup correctly for a newly
    seen sender of messages. Ptr to OSCORE?

FP: Sorry I don't understand what you mean by strike zones. Could you expand on that?
    
    Jim
    
    
    
    _______________________________________________
    Ace mailing list
    Ace@ietf.org
    https://www.ietf.org/mailman/listinfo/ace