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