Re: [Ace] AS discovery in draft-ietf-ace-oauth-authz-35

Stefanie Gerdes <gerdes@tzi.de> Tue, 08 September 2020 09:33 UTC

Return-Path: <gerdes@tzi.de>
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 C6BEF3A11CD for <ace@ietfa.amsl.com>; Tue, 8 Sep 2020 02:33:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.845
X-Spam-Level:
X-Spam-Status: No, score=-2.845 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 T80m_BR-fHg8 for <ace@ietfa.amsl.com>; Tue, 8 Sep 2020 02:33:31 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABCF33A11C8 for <ace@ietf.org>; Tue, 8 Sep 2020 02:33:31 -0700 (PDT)
Received: from [192.168.0.115] (p508a4e5d.dip0.t-ipconnect.de [80.138.78.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Bm0M86tmRz10SC for <ace@ietf.org>; Tue, 8 Sep 2020 11:33:24 +0200 (CEST)
To: ace@ietf.org
References: <707E236E-14F0-4F99-A5CB-B0E5B5DB3F68@ericsson.com>
From: Stefanie Gerdes <gerdes@tzi.de>
Message-ID: <ecb13044-b01a-8a54-9db5-2755b95afba7@tzi.de>
Date: Tue, 08 Sep 2020 11:33:15 +0200
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <707E236E-14F0-4F99-A5CB-B0E5B5DB3F68@ericsson.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/leyB6bBTv2BzT9P6IxJWAqRp0VM>
Subject: Re: [Ace] AS discovery in draft-ietf-ace-oauth-authz-35
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: Tue, 08 Sep 2020 09:33:35 -0000

Hi John,

the hard-coded list of authorized AS' is only one possibility for
authorization on the client side. I think we agreed that it is not a
very good one. The client may also dynamically obtain if a certain AS is
authorized. In this case, it is useful for the client to know for which
AS it must search.

The unauthorized resource request mechanism also allows the server to
provide a nonce (the cnonce) to the client, that must afterwards be
present in the access token. A constrained server without wall clock
time and time synchronization mechanism can use it to determine if the
access token is fresh.

Viele Grüße
Steffi

On 09/08/2020 10:37 AM, John Mattsson wrote:
> Hi Stephanie,
> 
> Regarding the section that you quoted: "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."
> 
> Assuming C has access to a function M letting it determine whether an AS has the authority to issue access tokens for a certain RS, this would certainly partly mitigate DoS attacks. The attack would be a DoS attack on C and M, but the attacker could not choose M.
> 
> The problem is that:
> - if C has access to such a function M that can provide a link between AS and RS, the whole mechanism with sending the AS address in an error message seems completely redundant.
> - If C does not have access to such a function M, the mechanism with sending an address in a spoofable error message seems like a very dangerous attack vector for DDoS attacks.
> 
> The only implementation of M that would make use of an error message would be if the error message contained something like sign(AS, RS), but this is something that is not discussed in the draft.
> 
> Cheers,
> John
> 
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
> 

-- 
Stefanie Gerdes			Tel: +49 421 218 63906
TZI Universität Bremen		E-Mail: gerdes@tzi.de
Bibliothekstr. 1, MZH 5150
28359 Bremen, Germany