Re: [OAUTH-WG] New draft: Mix-up prevention - adding "iss" parameter to the authorization response

Aaron Parecki <aaron@parecki.com> Mon, 26 October 2020 17:03 UTC

Return-Path: <aaron@parecki.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5887E3A0D6D for <oauth@ietfa.amsl.com>; Mon, 26 Oct 2020 10:03:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki.com
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 HiLyY-YFNt3g for <oauth@ietfa.amsl.com>; Mon, 26 Oct 2020 10:03:22 -0700 (PDT)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 702873A0D6E for <oauth@ietf.org>; Mon, 26 Oct 2020 10:03:22 -0700 (PDT)
Received: by mail-io1-xd36.google.com with SMTP id r9so10820416ioo.7 for <oauth@ietf.org>; Mon, 26 Oct 2020 10:03:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DPR6TBV6Ko3i0LP4AnefmqkKkehMjQITfDTWFfoggo4=; b=Llvjh6dtetlKxIORHej8lR8qZUYnOWOwD4uPhfO8o5BO6sGMGhqUsMC3ifGp7vgeR1 cHfCTnpCMgomhW0qhQBKnACBc8ElOvLTafgTab6Qc3POt4vm1RZeNJOHRgYw0osv9ovo FKPoxLalq1af2kdYJzUyOdevovzdG87UU5iJDV8zb4ELMsrmUzgYppO8fIcAaZJ9dfHP yQZMYhTSbQbflZ3KLnWJ3DSBkzeeT4Owf0IGpuNkaFFV2MddhfotWqwFQysog65wJpcC WPahKJrjYsYiXqI95YScIH5oksAXjdMoboyPdYKboBd5MMHkMjzu9Ri4VgmqkS8sIeVp Iniw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DPR6TBV6Ko3i0LP4AnefmqkKkehMjQITfDTWFfoggo4=; b=SIL/8YkWrN3E6nSEzKyOA/Ty6QUrusB0Rfd4dTyh2IDyQsaWpEONK39BloccAWdEaD st6YHNmTjf3fxiMBqDDMY5o9WQt+QpJQmLTGEK0A9ixGEou+acgtua5D4BRGFUjRRH3e zeL/8qE+9OrS9zsVpAdtoNbgFJMvQryhmj2D/dnMqIzfXEVC2Xqwl8t+RfOYF6T8b5QR xE9V0cbc3ab2EhqVtxvRmXvocdvbaJO3mLD/Xh5FDTzCviwFvpP12HohjaJRObeIIgdq 0F2D9YrDN8cU0f4astumoFhmCVldEufrNoGLL0gOBLKI90NehVcoaywDTpcWmQWMDWVT n+0A==
X-Gm-Message-State: AOAM532XDqqoBCES10tGjkPeQX3oWz9ILTqj7Ng/DBXO2KuZP2Ja8nRZ PWsikCXXzIYihzN/AzgO0ciU6dgsX4CWfg==
X-Google-Smtp-Source: ABdhPJwSnZCKuLW5QJZJUo1opvHWyWaf6t9o7yfHG9In6GRD9Rr++A5PKno2+2jdhzdbiLBuCZ1T3w==
X-Received: by 2002:a5d:8853:: with SMTP id t19mr10858711ios.164.1603731801050; Mon, 26 Oct 2020 10:03:21 -0700 (PDT)
Received: from mail-io1-f53.google.com (mail-io1-f53.google.com. [209.85.166.53]) by smtp.gmail.com with ESMTPSA id z15sm5971117ioj.22.2020.10.26.10.03.20 for <oauth@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2020 10:03:20 -0700 (PDT)
Received: by mail-io1-f53.google.com with SMTP id p15so10835203ioh.0 for <oauth@ietf.org>; Mon, 26 Oct 2020 10:03:20 -0700 (PDT)
X-Received: by 2002:a02:892:: with SMTP id 140mr12603733jac.38.1603731799756; Mon, 26 Oct 2020 10:03:19 -0700 (PDT)
MIME-Version: 1.0
References: <6604cde2-a936-7e66-034b-9282380205a6@hackmanit.de>
In-Reply-To: <6604cde2-a936-7e66-034b-9282380205a6@hackmanit.de>
From: Aaron Parecki <aaron@parecki.com>
Date: Mon, 26 Oct 2020 10:03:08 -0700
X-Gmail-Original-Message-ID: <CAGBSGjpbjzwgEPP4Y1D_p6UGLQc1MAD00mbcL2sJEd0VDtArTA@mail.gmail.com>
Message-ID: <CAGBSGjpbjzwgEPP4Y1D_p6UGLQc1MAD00mbcL2sJEd0VDtArTA@mail.gmail.com>
To: Karsten Meyer zu Selhausen <karsten.meyerzuselhausen@hackmanit.de>
Cc: OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003d543305b295e891"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/0gzI9hWWFCRJ50b3tFy3uTh-ao4>
Subject: Re: [OAUTH-WG] New draft: Mix-up prevention - adding "iss" parameter to the authorization response
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Oct 2020 17:03:24 -0000

To capture my comment from the interim meeting call, I would like to see
some explicit text in this draft (as well as the Security BCP section that
will reference this draft) that clarifies this parameter is not needed and
this attack is not relevant if a client only interacts with one
authorization server.

More broadly, I would like to make sure the scope of the attacks that this
prevents is clarified so that people may better understand when they do not
need to worry about this and don't need to use this new parameter.

---
Aaron Parecki
https://aaronparecki.com


On Mon, Oct 26, 2020 at 7:33 AM Karsten Meyer zu Selhausen <
karsten.meyerzuselhausen@hackmanit.de> wrote:

> Hello WG,
>
> adding the issuer identifier to the authorization response as a
> countermeasure to mix-up attacks is well-known on this list and already
> part of the security BCP (see 4.4.2
> <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-4.4.2>
> ).
> However, the "iss" parameter is currently not properly specified. Daniel
> and I wrote an ID to solve this issue.
>
> We would like to ask the working group to give us feedback on our first
> draft version:
> https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-00
>
> Abstract
>
>    This document specifies a new parameter "iss" that is used to
>    explicitly include the issuer identifier of the authorization server
>    in the authorization response of an OAuth authorization grant.  If
>    implemented correctly, the "iss" parameter serves as an effective
>    countermeasure to "mix-up" attacks.
>
>
> The need for a proper specification of the "iss" parameter was discussed
> in this thread:
> https://mailarchive.ietf.org/arch/msg/oauth/DQR2ZXtGKfa-8UGtuPYyZoAaBIc/
>
> Best regards,
> Karsten
>
>
> --
> Karsten Meyer zu Selhausen
> IT Security Consultant
> Phone:	+49 (0)234 / 54456499
> Web:	https://hackmanit.de | IT Security Consulting, Penetration Testing, Security Training
>
> Does your OAuth or OpenID Connect implementation use PKCE to strengthen the security? Learn more about the procetion PKCE provides and its limitations in our new blog post:https://www.hackmanit.de/en/blog-en/123-when-pkce-cannot-protect-your-confidential-oauth-client
>
> Hackmanit GmbH
> Universitätsstraße 60 (Exzenterhaus)
> 44789 Bochum
>
> Registergericht: Amtsgericht Bochum, HRB 14896
> Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>