Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy
Benjamin Kaduk <kaduk@mit.edu> Wed, 16 September 2020 01:28 UTC
Return-Path: <kaduk@mit.edu>
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 725873A0B4C for <ace@ietfa.amsl.com>; Tue, 15 Sep 2020 18:28:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 iPn697RZz6dE for <ace@ietfa.amsl.com>; Tue, 15 Sep 2020 18:28:19 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 2824C3A0B48 for <ace@ietf.org>; Tue, 15 Sep 2020 18:28:19 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 08G1SEGI028342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 15 Sep 2020 21:28:16 -0400
Date: Tue, 15 Sep 2020 18:28:14 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: "ace@ietf.org" <ace@ietf.org>
Message-ID: <20200916012814.GA89563@kduck.mit.edu>
References: <8CF8DD8C-895F-489D-8D21-FE2048B550EA@ericsson.com> <21607.1599763603@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <21607.1599763603@localhost>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/QP00FsUYMQ0NiXSJZV8k9oRarcU>
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: Wed, 16 Sep 2020 01:28:20 -0000
On Thu, Sep 10, 2020 at 02:46:43PM -0400, Michael Richardson wrote: > > John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org> wrote: > > - 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/” > > > The requirement "the client MUST be able to determine whether an AS has > > the authority to issue access tokens for a certain RS. This can for > > example be done through pre-configured lists, or through an online > > lookup mechanism that in turn also must be secured." indicates that C > > is required to have another mechanism to determine the AS for a > > specific RS and that the unauthorized AS address is completely > > redundant. > > This is a hard problem. > Q: "Who are you?" > A: "Depends upon who is asking! Who are you?" > A: "Depends upon who is asking! Who are you?" > ... > > The DNS-SD WG produced rfc8882, but as I understand it, > https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-privacy-05 > was abandonned because the WG did not see implementation/energy. > I can't seem to find the thread discussing that state. Interestingly, the corresponding requirements document was just published recently as RFC 8882. "A problem with no solution is a hard problem"... -Ben
- [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