IETF Logo Mail Archive

Re: [core] Mail regarding draft-ietf-core-coap

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 21 July 2020 13:00 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 D29303A0824 for <core@ietfa.amsl.com>; Tue, 21 Jul 2020 06:00:21 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 USbIpJNJocPE for <core@ietfa.amsl.com>; Tue, 21 Jul 2020 06:00:20 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35CDB3A0822 for <core@ietf.org>; Tue, 21 Jul 2020 06:00:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E373438A0C; Tue, 21 Jul 2020 08:39:53 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2c-tZUv1w76g; Tue, 21 Jul 2020 08:39:53 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 3BAE5389F1; Tue, 21 Jul 2020 08:39:53 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 65E1F3F; Tue, 21 Jul 2020 09:00:18 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Kawai Wong <Kawai.Wong@fphcare.co.nz>
cc: "core@ietf.org" <core@ietf.org>, "draft-ietf-core-coap@ietf.org" <draft-ietf-core-coap@ietf.org>
In-Reply-To: <971C52B6-AFD8-4BC8-BEA4-9DA05E065217@fphcare.co.nz>
References: <971C52B6-AFD8-4BC8-BEA4-9DA05E065217@fphcare.co.nz>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Tue, 21 Jul 2020 09:00:18 -0400
Message-ID: <27060.1595336418@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/D55xm63oFguHmEe1E9uAlHs1j2c>
Subject: Re: [core] Mail regarding draft-ietf-core-coap
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: Tue, 21 Jul 2020 13:00:22 -0000

Kawai Wong <Kawai.Wong@fphcare.co.nz> wrote:
    > Our organisation is using CoAP and we have require a special use case
    > to provide authorization for CoAP requests, much like how there’s an
    > Authorization header for HTTP.

CoAP or coaps?
OSCORE?

    > We are wondering if we can get an Option number included for this
    > purpose as part of the standard? e.g.

    > *   Bearer Option with opaque option format for bearer tokens; Or
    > *   Authorization Option also an opaque option format

Thank you for thinking about this as a bearer token, rather than a password :-)

    > Please do let me know what your thoughts are and the considerations
    > taken into account for registering a new option number to be included
    > as part of the standard.

I can't help but think that if the bearer token is something both parties
already have, that you are better off using OSCORE with PSK authentication.

If the bearer token is something the client has and the server can
evaluate for correctness (it has structure meaningful to the server), then a
different consideration would be in order.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email