Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy
Michael Richardson <mcr+ietf@sandelman.ca> Thu, 10 September 2020 18:57 UTC
Return-Path: <mcr+ietf@sandelman.ca>
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 5EA2D3A0E5A for <ace@ietfa.amsl.com>; Thu, 10 Sep 2020 11:57:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 xyXQv3Hda6xP for <ace@ietfa.amsl.com>; Thu, 10 Sep 2020 11:57:47 -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 472363A0E47 for <ace@ietf.org>; Thu, 10 Sep 2020 11:57:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 194FD389D7; Thu, 10 Sep 2020 14:36:34 -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 MkryRckUUCGr; Thu, 10 Sep 2020 14:36:32 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B066C389D6; Thu, 10 Sep 2020 14:36:31 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 56580212; Thu, 10 Sep 2020 14:57:43 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: ace@ietf.org
cc: Jim Schaad <ietf@augustcellars.com>, 'Stefanie Gerdes' <gerdes@tzi.de>
In-Reply-To: <000201d686f6$2c4aba60$84e02f20$@augustcellars.com>
References: <8CF8DD8C-895F-489D-8D21-FE2048B550EA@ericsson.com> <877dt3l5u1.fsf@wangari> <C3C52EBE-CD20-4201-9E93-F7FB4D92D77C@ericsson.com> <04f797cb-ec58-a8f8-a9d6-6cdbf8878376@tzi.de> <000201d686f6$2c4aba60$84e02f20$@augustcellars.com>
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: Thu, 10 Sep 2020 14:57:43 -0400
Message-ID: <23864.1599764263@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/GCoEBUQYgOq8fEZTR1ynEWlDHJk>
Subject: Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy
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: Thu, 10 Sep 2020 18:57:50 -0000
sg> A compromised RS may use the hints for attempting to trick a client sg> into contacting an AS that is not supposed to be in charge of that RS. sg> Therefore, C must not communicate with an AS if it cannot determine sg> that this AS has the authority to issue access tokens for this sg> RS. Otherwise, a compromised RS may use this to perform a denial of sg> service against a specific AS, by redirecting a large number of client sg> requests to that AS. Jim Schaad <ietf@augustcellars.com> wrote: > [JLS] I do not know how C is supposed to be able to determine if AS has > the authority to issue access tokens for a specific RS. If it had the > ability to do that then it can go directly to the AS in question > without ever needing to use this mechanism. This mechanism is designed > to be used for the case where C does not have a priori knowledge about > which AS it will talk to get the token for RS. I was going to ask the same thing. This is variation of the onboarding problem, but also it ignores how devices got network access in the first place. If C and RS share some trust in some nearby third party, then that party could vouch. I say "nearby", because having them both trust google or azure or amazon doesn't help, because that anchor has no real knowledge about whether RS or RS' is actually nearby. RS' could be legitimately onboarded with "cloud", but just happens to be a device "next door". Or could it? yes, in theory, but the question arises about how C and RS are communicating? If one assumes that they are on the same L2, or different L2's managed by the same L3, then there is a local third party. In most cases, if RS' can spoof a response, it's because it is on the same L2, having the same L2 security as C. If C and RS are distant (you try to turn on your blood pressure sensor across the Internet) then yes, it could wind up with the wrong sensor. >>>> - That RS shares the AS address with anybody that asks can be a >>>> severe privacy problem. If RS is a medical device, the AS address >>>> can reveal sensitive information. If RS is a blood pressure sensor >>>> it could e.g. be “AS address = >>>> coaps://as.hopkinsmedicine.org/kimmel_cancer_center/” > [JLS] My first hope is that this RS would never return an AS address to > a client. Sending information which has secure privacy problems > amounts to a case where the rule should be: If C does not know what AS > to talk to, it has no business talking to me (RS). At which point, I wonder what the point of the AS is. > [JLS] This is the type of situation where that information itself is > going to be information to which access is to be restricted and where > you need to talk to an AS to get permissions to get that information. > In this type of situation I would expect that the information would > only be available either throw an already secure channel or from a DS > with the, not yet defined, AS attributes. So, RS could answer with some less specific AS, that deals with who C is? The, as it were, cloudflare of IoT? -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
- [Ace] draft-ietf-ace-oauth-authz-35 - unauthorize… John Mattsson
- Re: [Ace] draft-ietf-ace-oauth-authz-35 - unautho… Olaf Bergmann
- Re: [Ace] draft-ietf-ace-oauth-authz-35 - unautho… John Mattsson
- Re: [Ace] draft-ietf-ace-oauth-authz-35 - unautho… Stefanie Gerdes
- Re: [Ace] draft-ietf-ace-oauth-authz-35 - unautho… Olaf Bergmann
- Re: [Ace] draft-ietf-ace-oauth-authz-35 - unautho… Jim Schaad
- Re: [Ace] draft-ietf-ace-oauth-authz-35 - unautho… Seitz Ludwig
- Re: [Ace] draft-ietf-ace-oauth-authz-35 - unautho… Olaf Bergmann
- Re: [Ace] draft-ietf-ace-oauth-authz-35 - unautho… Stefanie Gerdes
- Re: [Ace] draft-ietf-ace-oauth-authz-35 - unautho… Stefanie Gerdes
- Re: [Ace] draft-ietf-ace-oauth-authz-35 - unautho… Stefanie Gerdes
- Re: [Ace] draft-ietf-ace-oauth-authz-35 - unautho… Michael Richardson
- Re: [Ace] draft-ietf-ace-oauth-authz-35 - unautho… Michael Richardson
- Re: [Ace] draft-ietf-ace-oauth-authz-35 - unautho… Benjamin Kaduk
- Re: [Ace] draft-ietf-ace-oauth-authz-35 - unautho… Michael Richardson
- Re: [Ace] draft-ietf-ace-oauth-authz-35 - unautho… Seitz Ludwig