Re: [OAUTH-WG] Call for Adoption - AS Issuer Identifier in Authorization Response

Karsten Meyer zu Selhausen <> Wed, 09 December 2020 07:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A3B213A0D4B for <>; Tue, 8 Dec 2020 23:55:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Status: No, score=-2.088 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mLyFatVsGivH for <>; Tue, 8 Dec 2020 23:55:31 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 053FD3A0D50 for <>; Tue, 8 Dec 2020 23:55:30 -0800 (PST)
Received: by with SMTP id t4so618886wrr.12 for <>; Tue, 08 Dec 2020 23:55:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=kx+sDfshOiGp5BbdBMy+pDaRGRdPlhleNxeh6Q9kKJk=; b=cq0/a0NOtuxlfCtbeiWmF64eCUoki4ZLyYv0uC/BhaxUqSUsNc3fQN+25GiqOppMCU hwIb7E4ZZpgdjqC+Te4ApbgF2iojbP7+PvZCE4XKPVdJ7H/lr/iUNdqIcUd6yvpZabMI 9ezAlOQL7otQrDImPw9bcL1kaovEFWtptYUuErNqiSL3aDE3gnB21ychrvF2QPuH8rcj qUHBPjXB3moxRHhAErWwjWHhhi4K+JBbYyvT99pxepLzEgSVDXlBk4AmMEvzy1ad3XYL aLqYoT+8ZecUWADUfFHP08F5BQ4jS0f3EoniaBW0dFO3fzsYSbnBXgG0PlEkVMOmJ+Gy b+Gg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=kx+sDfshOiGp5BbdBMy+pDaRGRdPlhleNxeh6Q9kKJk=; b=PzkUPS7qTTyDpA5i/dLALLgztDJkzbwhRdrlMBsf1i4cQpzgrKQdDZ2wg0D9oRSmep XFUINNa4raKCnT5rJJsJDCUcT3YUfNzR36fSjeODUolFRdRgfI9It3t4JNHUvU6UnD6G vTrCa8v3W+HOg+z23u02ORVz2ZExytqFGMAIlLQGc7EQT/qcsAkhxPnygk66UW/S5YcG 9VBVWxhEkQNBmepDtZrt5DxiYOj5X2dJ+5L0G+ympVR7JLOAufOdOJfJMHYjlEuOAmBD Loe5q92Kqr2dtjTu7krx/2Oo54K85WGT/Tr3I4MPNzPNwoPru/W75qchBpvggOCPm1tS jyug==
X-Gm-Message-State: AOAM532txpB6oinbAxT6o53wMQ75QEKLP5vV06R0E4h5IJGTUwOMM1La 8+R/JXKO4eu17MTOVDlaGd9p3bDJ/5glOg==
X-Google-Smtp-Source: ABdhPJzcBgriexYTz6LVDoydEqeIY8W7sf6NQtKJpOl9myKizMUAkkb5UjEIRrBfsiOdw15/uDQkVA==
X-Received: by 2002:adf:fd84:: with SMTP id d4mr1134591wrr.383.1607500528737; Tue, 08 Dec 2020 23:55:28 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id c190sm1721270wme.19.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Dec 2020 23:55:22 -0800 (PST)
To: Warren Parad <>
Cc: Rifaat Shekh-Yusef <>, oauth <>
References: <> <> <>
From: Karsten Meyer zu Selhausen <>
Message-ID: <>
Date: Wed, 09 Dec 2020 08:55:20 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="O66mr07T1mGIT2wqnMvbzxZLniR1vBg5V"
Archived-At: <>
Subject: Re: [OAUTH-WG] Call for Adoption - AS Issuer Identifier in Authorization Response
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Dec 2020 07:55:35 -0000

Hi Warren,

I think there is some misunderstanding on how mix-up attacks work. I 
will try to clear things up.

Have a look at the following mix-up attack example (slide 4 
from the interim meeting):

I marked the important parts:

  * In step 1 the client stores the attacker's AS (A-AS) as the selected
  * Step 5: The authorization response is issued by the honest *(= not
    compromised)* AS, not by the attacker's AS. The H-AS will use its
    own correct issuer identifier as the value for the AS parameter.
      o In a mix-up attack the attacker cannot directly influence the
        value of the iss parameter in the authorization response as it
        is issued by the H-AS.
  * Step 6: The client sends the token request to the token endpoint of
    the A-AS, because it stored the A-AS as the selected AS in step 1.
    This leaks the authorization code to the attacker who can use it in
    a code injection attack, for example.

With an iss parameter present in step 5 the client would be able to 
recognize that the code was issued by the H-AS, not by the A-AS. The 
client would be able to abort the authorization grant instead of leaking 
the code to the A-AS.

I hope this addresses your concerns.

Best regards,

On 08.12.2020 20:15, Warren Parad wrote:
> As an implementer on both sides of the issue I'm struggling to 
> understand how this problem would occur. I'm finding issues with the 
> proposed problems:
>  1. Honest AS is compromised, assuming this does happen details on why
>     adding iss to the AS response would prevent attacks is necessary
>     for me. In other words, how would an AS be compromised in a way
>     that would be identifiable through the issuer value? (my ignorant
>     assumption is that a compromised AS is compromised enough that an
>     attacker would be able to send the correct ISS)
>  2. Attacker AS is registered. I fully support the idea that this can
>     and will happen, however from attempting to test-implement this
>     proposal, I can't see how the authorization would be sent to the
>     wrong token endpoint. Since there is no information in the AS auth
>     code response, the client must already have the knowledge of where
>     they are going to send the token, no mix-up can be executed. I
>     would argue, if anything, adding the ISS parameter would open a
>     new attack surface by providing clients an opportunity to
>     blatantly trust the ISS parameter as the honest AS and thus
>     actually sending the code there instead of sending it to one
>     specified in the metadata document.
> My confusion is the following:
>   * Are multi AS services utilizing authorization codes in a way where
>     there could be a mix up attack for #2.
>   * Is there a #3 that I'm missing which even in light of #1 & #2 I
>     brought up that would still make this change valuable?
> Warren Parad
> Founder, CTO
> Secure your user data and complete your authorization architecture. 
> Implement Authress <>.
> On Tue, Dec 8, 2020 at 8:01 PM Dick Hardt < 
> <>> wrote:
>     +1
>     ᐧ
>     On Tue, Dec 8, 2020 at 4:51 AM Rifaat Shekh-Yusef
>     < <>> wrote:
>         All,
>         This is a call for adoption for the following AS Issuer
>         Identifier in Authorization Response as a WG document:
>         <>
>         Please, provide your feedback on the mailing list by Dec 22nd.
>         Regards,
>          Rifaat & Hannes
>         _______________________________________________
>         OAuth mailing list
> <>
>         <>
>     _______________________________________________
>     OAuth mailing list
> <>
>     <>
Karsten Meyer zu Selhausen
IT Security Consultant
Phone:	+49 (0)234 / 54456499
Web: | IT Security Consulting, Penetration Testing, Security Training

Nehmen Sie an unserer nächsten Live Online-Schulung zur Sicherheit von OAuth und OpenID Connect am 27.01 + 28.01.2021 teil:

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