Re: [core] Questions and comments against the github version

Christian Amsüss <christian@amsuess.com> Wed, 19 December 2018 08:39 UTC

Return-Path: <christian@amsuess.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3704A130DC8 for <core@ietfa.amsl.com>; Wed, 19 Dec 2018 00:39:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 OzvqQOaRoKou for <core@ietfa.amsl.com>; Wed, 19 Dec 2018 00:39:54 -0800 (PST)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C3AC12008A for <core@ietf.org>; Wed, 19 Dec 2018 00:39:54 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 6D3F74253F; Wed, 19 Dec 2018 09:39:50 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id C3F38D7; Wed, 19 Dec 2018 09:39:47 +0100 (CET)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 6B10F6A; Wed, 19 Dec 2018 09:39:47 +0100 (CET)
Received: (nullmailer pid 31450 invoked by uid 1000); Wed, 19 Dec 2018 08:39:47 -0000
Date: Wed, 19 Dec 2018 09:39:46 +0100
From: Christian Amsüss <christian@amsuess.com>
To: Lauri Piikivi <Lauri.Piikivi@arm.com>
Cc: "core@ietf.org" <core@ietf.org>
Message-ID: <20181219083946.GA30229@hephaistos.amsuess.com>
References: <02dd01d490f8$6aea0dc0$40be2940$@augustcellars.com> <d00ab991b089fb28625cb455ab7c5bec@bbhmail.nl> <035e01d49178$b08a3e60$119ebb20$@augustcellars.com> <4ea547c2c838536e260fd222651ae446@bbhmail.nl> <VI1PR08MB37106E3F129E5012E9737D0CEBA70@VI1PR08MB3710.eurprd08.prod.outlook.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="sdtB3X0nJg68CQEu"
Content-Disposition: inline
In-Reply-To: <VI1PR08MB37106E3F129E5012E9737D0CEBA70@VI1PR08MB3710.eurprd08.prod.outlook.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/Qorz74Vn8QtKNUcfMndIADgHi5A>
Subject: Re: [core] Questions and comments against the github version
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Dec 2018 08:39:57 -0000

Hello Lauri,

On Wed, Dec 12, 2018 at 09:55:58AM +0000, Lauri Piikivi wrote:
> If a EP publishes itself in rd, no other ep, based on adequate
> authenticaiton, can overwrite it. If an earlier registered EP makes a
> new registration to the RD, where it does not include the location in
> the path, is an indication that the EP may have reset or otherwise
> wants a new registration (e.g. Due to changed attributes) in the rd.

Yes.

> Another ep trying to post to another ep’s url should get an error.
> This requires authenticaiton.

An new ep trying to post to an old ep's registration URL is what I'd
call "registration hijacking". It is not allowed, but begs the question
of how the RD would know that the hijacking endpoint is actually
different from the original one.

If the credentials are suitable, the only assumption the RD can make is
that the "new" endpoint is the same as the old one, and that it has only
just switched its network address.

Otherwise, the RD would reject the operation with 4.01 Unauthorized.

Best regards
Christian

-- 
The detailed semantics of CoAP methods are "almost, but not entirely
unlike" [HHGTTG] those of HTTP methods.
[HHGTTG]: Adams, D., "The Hitchhiker's Guide to the Galaxy", October 1979.
  -- Shelby, et al., Internet-Draft Constrained Application Protocol (CoAP)