Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy

Seitz Ludwig <ludwig.seitz@combitech.se> Thu, 17 September 2020 06:00 UTC

Return-Path: <ludwig.seitz@combitech.se>
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 56F063A0783 for <ace@ietfa.amsl.com>; Wed, 16 Sep 2020 23:00:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 qsMLyKp9g-P9 for <ace@ietfa.amsl.com>; Wed, 16 Sep 2020 23:00:04 -0700 (PDT)
Received: from weald.air.saab.se (weald.air.saab.se [136.163.212.3]) (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 506013A08BB for <ace@ietf.org>; Wed, 16 Sep 2020 23:00:01 -0700 (PDT)
Received: from mailhub2.air.saab.se ([136.163.213.5]) by weald.air.saab.se (8.14.4/8.14.4) with ESMTP id 08H5xwvf010553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Sep 2020 07:59:58 +0200
DKIM-Filter: OpenDKIM Filter v2.11.0 weald.air.saab.se 08H5xwvf010553
Received: from corpappl16256.corp.saab.se (corpappl16256.corp.saab.se [10.12.13.175]) by mailhub2.air.saab.se (8.13.8/8.13.8) with ESMTP id 08H5xjoh015425 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 17 Sep 2020 07:59:45 +0200
Received: from corpappl16595.corp.saab.se (10.12.12.127) by corpappl16256.corp.saab.se (10.12.13.175) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Thu, 17 Sep 2020 07:59:45 +0200
Received: from corpappl16595.corp.saab.se ([fe80::3c3e:6470:4c56:a86f]) by corpappl16595.corp.saab.se ([fe80::3c3e:6470:4c56:a86f%4]) with mapi id 15.01.1979.006; Thu, 17 Sep 2020 07:59:45 +0200
From: Seitz Ludwig <ludwig.seitz@combitech.se>
To: Stefanie Gerdes <gerdes@tzi.de>, "ace@ietf.org" <ace@ietf.org>, John Mattsson <john.mattsson@ericsson.com>
Thread-Topic: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy
Thread-Index: AQHWhnwA43bpZmaNe02CEHxKiGnz1alf9ztG///zq4CAABqpAIAAuEYAgACtxwCAADy4AIAKuOZQ
Date: Thu, 17 Sep 2020 05:59:45 +0000
Message-ID: <6c5c1fed199e45c6a8224e43e30f7d26@combitech.se>
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> <a3b290cd909f487690e718dee4b94ab0@combitech.se> <1fc88f97-dc69-54f0-bde1-6ddd37b7aad0@tzi.de>
In-Reply-To: <1fc88f97-dc69-54f0-bde1-6ddd37b7aad0@tzi.de>
Accept-Language: en-SE, sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.12.13.211]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Saab-MailScanner-Information: Please contact the ISP for more information
X-Saab-MailScanner-ID: 08H5xjoh015425
X-Saab-MailScanner: Found to be clean
X-Saab-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.5, required 5, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -0.50)
X-Saab-MailScanner-From: ludwig.seitz@combitech.se
X-Saab-MailScanner-Watermark: 1600927185.71558@99RoU/8O6tsnHACmsVR3Bw
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (weald.air.saab.se [136.163.212.3]); Thu, 17 Sep 2020 07:59:58 +0200 (CEST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/W0C3F1eCWq_TansC8S2gVN3WFQE>
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, 17 Sep 2020 06:00:07 -0000

Hello John,

Steffi made some suggestions to improve the sections you criticized (see also https://github.com/ace-wg/ace-oauth/pull/177).

Do you think they address your issues?

Does the WG have an opinion on the way forward? (Chairs? Ads?)

/Ludwig


> -----Original Message-----
> From: Ace <ace-bounces@ietf.org> On Behalf Of Stefanie Gerdes
> Sent: den 10 september 2020 14:11
> To: ace@ietf.org
> Subject: Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address,
> DoS, and privacy
> 
> Hi Ludwig,
> 
> comments inline.
> 
> On 09/10/2020 08:49 AM, Seitz Ludwig wrote:
> > Seeing that the mechanism was introduced to bootstrap a client that
> doesn't know which AS to talk to for a specific RS and given the issues raised
> by John,  what other options do we have that are more secure?
> 
> The mechanism in itself does not have a security problem. If C would
> communicate with an AS that is not authorized for this RS that would be a
> problem, but as section 6.5 states, C must be able to validate that.
> This point is really important for the security of the solution, regardless of the
> discovery mechanism. The privacy problem that AS URIs may pose should be
> mentioned in the privacy considerations. I made a text proposal in my
> response to John [1].
> 
> >
> > a.) A resource directory lookup? I'm not knowledgeable enough on RD to
> answer whether that is more secure, but Steffi or Olaf or Carsten should
> have more insight on this.
> >
> > b.) A callback to a trusted entity (say the client owner). The issue here is
> that we have not defined any interactions for that entity yet.
> >
> > c.) John suggested something with DNS in the first mail. I have no idea how
> this would work, John what did you have in mind there?
> >
> > For the draft I see two ways forward:
> >
> > 1.) Remove the whole discovery mechanism and just state that at this point
> we assume that the knowledge of the right AS is pre-configured/supplied
> out-of-band to the client. This leaves room for future work that specifies an
> in-band method.
> >
> > 2.) Try to fix this (e.g. by specifying one of the methods a-c above).
> >
> > I do not have the time to do 2 so I clearly prefer option 1, but if any of my
> co-authors can put in the work I'd be very glad.
> 
> I already made text proposals that hopefully clarify the problems that John
> brought up [1]. I think it is really important to address these problems in
> sections 6.4 and 6.5 in the draft and not just ignore them or leave them for
> later. That would leave the framework open for attacks. Developers will have
> difficulties to close this gap on their own.
> 
> We also should decouple the AS request creation hints from the explanation
> of the AS discovery mechanism. The hints have the additional purpose that
> they may contain the resource server's cnonce that the resource server can
> later use to validate the access token.
> Therefore, the AS URI should be optional in the AS request creation hints,
> and we should make section 5.1.1 section 5.2.
> 
> Viele Grüße
> Steffi
> 
> [1]
> https://mailarchive.ietf.org/arch/msg/ace/0639BdkMvJZdUjLBJIX21EiSvbw/
> 
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace