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

Francesca Palombini <francesca.palombini@ericsson.com> Wed, 06 November 2019 12:43 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 02239120886; Wed, 6 Nov 2019 04:43:19 -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 oNSJZlIyVFFd; Wed, 6 Nov 2019 04:43:16 -0800 (PST)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30055.outbound.protection.outlook.com [40.107.3.55]) (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 AB0A112087E; Wed, 6 Nov 2019 04:43:12 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Zh028JMtQBTmwedthZnc8C+uHwxmACE9l1QbdROR6BKN+ZEJweeETeWH7B3x+tKWX3kvWsukZiSiVLs6m6+xatjATsDbAAlD24XpcIS8orODjTpIs2pUxL2kUg+9XPBSjnIl31cqjzyKeh4BPgHTJVK+zOS617nuprZzfoW7D5zd4mZJPVl96lYiBP74Y2EO2JTc6fsDuH4AXFA4d1E8Ia5NVTLqHpU3wGFuT23ZzWTkb2Eal5hDR7+d9WQ14tyNKXi9E0EVQR3joUP5lY/2oFSN8DRCcmZoWJHuEo2n6fZPRGvmY4FeRrtN5SA/NL+9jtokItrYqwQZmLAhNPXZLg==
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=/YulaD9IlwYrrYTGqdzntTUZlcX/zizUnSUzpeeL6BI=; b=S4oQNQh+dhfi1HJTAayXyTGMKcTLjnETTfJWNxw6BU52xzaNxbJ/eTH8FprMgB5dTtD0sqAxSF0pjLiHYmc8o0Hx1bT0JWmcebVvsHphJcXc4sNSjEWaE1tw58Kbs0dCdsfQ9NO7DBjYBN4lvHTYH7+zaxQ0nAUdRrKnOr4RMAX4Vt4bq0wv+cN4kPwdWeDlmJr1S9IE3Ax1hySuE1cTi91NbOaikBiSH1WGoIJWBECZZAn3nRq2NbocNu6MRi6Bj8Oy4g+vMDu1xaNJSGa74rmZocSPQ9YUhWY5ezEhz8PauBq5hvH6W8m6UJ2FKJTiKxcVg+Uqi3ns/32mzUPylQ==
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=/YulaD9IlwYrrYTGqdzntTUZlcX/zizUnSUzpeeL6BI=; b=cQUYWlkcNrGAux1oMM9Wuv79J8OZrOwHFGmIUUFN26AxVXlCw43kDSbbJhKukk6EORrofHOTcKYpXZoY+Bpy2pF5HDjj2w+X25vGRsMty4DqHBiwpDagkuFcN1qucVoKHqSOqbIK02t+0tLrVAGQqhJJCFj7vbQfzcrNpYvA+HA=
Received: from VI1PR07MB5469.eurprd07.prod.outlook.com (20.178.14.214) by VI1PR07MB3071.eurprd07.prod.outlook.com (10.170.239.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.16; Wed, 6 Nov 2019 12:43:10 +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:43:10 +0000
From: Francesca Palombini <francesca.palombini@ericsson.com>
To: 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: Review of draft-ietf-ace-key-groupcomm
Thread-Index: AQHVPiQplIgMsLYvtU2keDvcPHncYad+0/eA
Date: Wed, 6 Nov 2019 12:43:10 +0000
Message-ID: <7803195E-C22B-4EDE-BA68-A247E1D7A65D@ericsson.com>
References: <7000332e-9853-fcc5-c98f-b2d8f2fb4060@ri.se>
In-Reply-To: <7000332e-9853-fcc5-c98f-b2d8f2fb4060@ri.se>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: yes
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: ab9a57b3-783c-4a7b-d867-08d762b6e190
x-ms-traffictypediagnostic: VI1PR07MB3071:
x-microsoft-antispam-prvs: <VI1PR07MB30713A94D633B48CDAF1CE3D98790@VI1PR07MB3071.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 02135EB356
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(396003)(39860400002)(366004)(136003)(189003)(199004)(6116002)(6486002)(76116006)(2616005)(3846002)(2906002)(11346002)(446003)(6246003)(102836004)(6512007)(71190400001)(26005)(66946007)(99936001)(186003)(66066001)(14444005)(256004)(305945005)(33656002)(7736002)(229853002)(476003)(6436002)(486006)(44832011)(66616009)(91956017)(110136005)(316002)(66476007)(71200400001)(86362001)(8676002)(14454004)(36756003)(81156014)(8936002)(6506007)(2501003)(5660300002)(81166006)(25786009)(4326008)(99286004)(66446008)(478600001)(66556008)(64756008)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3071; H:VI1PR07MB5469.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-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: zSZe1VCtNXuZwgaS0QhnfiiFEc92dywlSow2Be+pNjo2d1VwniRoRZCrLEKwN3lbdEj1eUoYHob8O2YO5RUqb9Y0METKiXh+nqPYCPAdmgQMnLurrCTDr4yNGEpeqLlTepuOaHkreBIdmAblHo5L8fhZN68XPcP23gSvEI8HMi+C1uCz292Zm9etNTHNHHYxKa/zIdxi9rPQ4yT3JVRxyQWuZd1VTOS8xucnsxsnpATvYN/4osCk+eNRnsMsNzzlidicVMmGtHRjGlso4QrFtJwusGvpQtw1Y0hKuMwz6w5CuOGttZcDGZ5s7KgrYZuOnhI06qKMmxUlkttyd08lh6Es/BiKgqiWZ0Iuw/DJjFgQFRjyc9sem3G7WcGzRrA3HzDAma8dPVI36/JHUow6gRuHy4wYCSeZabyWsq3Htf6SlPtyioiP31j/HxE5gG7X
x-ms-exchange-transport-forked: True
Content-type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3655892589_1852886273"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ab9a57b3-783c-4a7b-d867-08d762b6e190
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2019 12:43:10.2651 (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: gCVDhu1RXNLsCVevH3drYehSugQEVrTJKdJUnuRrPRXTI5rmNc01/6Gz1QdM+LdZFS+VBelE+5HYMiksne1XFlnIy1qSzq2CAWxfpATZVar4XYcVQmS/hOc4YF85FAzI
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3071
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/2sHO1ttlHpJ88jr1Jj73HgOxhho>
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:43:19 -0000

Hi Ludwig,

Thank you so much for your detailed review! We have addressed your comments in the -03 update submitted. It might be a bit hard to see from the diff, as we also made a restructuring based on comments at IETF105, but I answer to detailed comments inline.

Thanks again,
Francesca

´╗┐On 19/07/2019, 13:21, "Ludwig Seitz" <ludwig.seitz@ri.se>; wrote:

    Hello Francesca, Marco,
    
    I have finally managed to read the whole of draft-ietf-ace-key-groupcomm 
    and have a few comments for you:
    
    
    Figure 2: I suggest you move the "Defined in ..." to the left
    they way it is now, it looks as if the Dispatcher was defined in the ACE 
    framework.

FP: Ok, done.
    
    ==
    "3.1.  MUST contain ... 'grant_type'"
    
    This is no longer true. Grant_type was made optional in one of the 
    latest updates of the ACE framework. When it is absent, 
    grant_type=client_credentials is assumed as default.

FP: Ah, we had missed this, thanks for pointing that out! So fixed as you suggest.
    
    ==
    3.3  "... and includes the following parameters: "
    
    How is that supposed to work? The framework defines sending of the token 
    to /authz-info as a CoAP POST, where the payload is the bytes of the 
    token. In order to include additional parameters you would have to 
    redefine this payload to be a CBOR map (as the OSCORE profile does).

FP: We do specify the content-format to be ace+cbor in that case, now we have clarified that the payload is a CBOR Map, containing token plus those parameters.
    
    ==
    The whole section 3 talks about parameters send back and forth between 
    the client and the KDC without defining how these are carried. It seems 
    to be implied that there are CBOR maps in the payload, but that should 
    be made explicit, especially where it differs from what the framework 
    defines.
    
FP: Yes, we have now clarified that.

    ==
    3.1  the text about the parameters in the client's post to the 
    /authz-info endpoint at the KDC talks about parameters "sign_info" and 
    "pub_key_enc" and claims they are specified in 3.3.1 and 3.3.2, but 
    these sections specify the parameters for the "AS request creation 
    hints" messages and not in this context. At least some clarification 
    should be added.
    
FP: Ok, we have now added some text about that at the end of sections 3.3.1 and 3.3.2.

    ==
    Section 4
    
    "If not previously established, the Client and the KDC MUST first
        establish a pairwise secure communication channel using ACE."
    
    This sentence is not strictly correct. Using what part of ACE? The ACE 
    framework just says that you should establish a secure communication 
    channel, it's the specific profiles that define how these channels are 
    established. Please add some clarification.
    
FP: Note that this text is now moved to section 4.2. We have clarified by replacing with the 2 following sentences: 
"   If not previously established, the Client and the KDC MUST first
   establish a pairwise secure communication channel (REQ15).  This can
   be achieved, for instance, by using a transport profile of ACE."


    ==
    
    "The Client and the KDC MAY use that same secure channel to protect 
    further pairwise communications, that MUST be secured."
    
    This is very questionable use of requirements language. How do I claim 
    or test conformance with the second MUST?
    
FP: Right. We have rephrased. The MUST was not supposed to be normative

" The Client and
   the KDC MAY use that same secure channel to protect further pairwise
   communications that must be secured."

    ==
    Section 4:
    "The same set of message ..." should be "messages"

FP: Ok, this text actually disappeared with the restructuring.
    
    ==
    "  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."
    
    This may or may not be true for a specific secure communication protocol
    (e.g. think of DTLS with X.509 certificates without client 
    authentication). You need to require this from the underlying secure 
    communication protocol.

FP: Thanks for pointing this out. We replaced the previous text with the following:
"   The secure communication protocol is REQUIRED to establish the secure
   channel by using the proof-of-possession key bound to the access
   token.  As a result, the 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."
    
    ==
    4.1 "The endpoint in the KDC is associated to the 'scope' value of the 
    Authorization Request/Response."
    
    Associated how? This is too unspecific to lead to interoperable 
    implementations. I would like to see this association specified in detail.
    
FP: This text disappeared with the restructuring. Now we do give "default" names for the endpoints at the KDC, similar to how ACE does it.

    ==
    4.2 "as defined in the "ACE Groupcomm Key" registry, defined in Section 
    11.5."
    
    If possible, rephrase this to avoid the double use of "defined".

FP: Ok, done.
    
    ==
    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.
    
FP: I will answer to this comment in a separate mail, to include Jim's point.

    ==
    6. "Then, if it wants to continue participating in the group
        communication, the node has to request new updated keying material to
        the KDC."
    
    should be "... keying material from the KDC."

FP: Ok, fixed.
    
    ==
    Sections 8. and 9.
    
    Would be nice if there also were back-references to where those 
    parameters are
    defined in the draft.
    
FP: Now added.
    
    /Ludwig
    
    
    -- 
    Ludwig Seitz, PhD
    Security Lab, RISE
    Phone +46(0)70-349 92 51