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

Vladimir Dzhuvinov <vladimir@connect2id.com> Mon, 26 October 2020 15:06 UTC

Return-Path: <vladimir@connect2id.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 BB5DE3A0C0A for <oauth@ietfa.amsl.com>; Mon, 26 Oct 2020 08:06:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.141
X-Spam-Level:
X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 lQeq0NY3Oonv for <oauth@ietfa.amsl.com>; Mon, 26 Oct 2020 08:06:52 -0700 (PDT)
Received: from p3plsmtpa11-02.prod.phx3.secureserver.net (p3plsmtpa11-02.prod.phx3.secureserver.net [68.178.252.103]) (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 40C523A0A06 for <oauth@ietf.org>; Mon, 26 Oct 2020 08:06:52 -0700 (PDT)
Received: from [192.168.88.250] ([94.155.17.31]) by :SMTPAUTH: with ESMTPSA id X45Bk68f8zAfGX45CkvHrJ; Mon, 26 Oct 2020 08:06:51 -0700
X-CMAE-Analysis: v=2.4 cv=TeJTCTch c=1 sm=1 tr=0 ts=5f96e60b a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=9YbGl7VAAAAA:8 a=ZS-cmYKORgS9EeuWxlMA:9 a=r4LEt5SkN1rejCcQ:21 a=4KQkCOPDxcHvq9Gw:21 a=QEXdDO2ut3YA:10 a=jRiBNK6MsXuhxgvlEu8A:9 a=o9Buy8lpsuiF2yCf:21 a=lgwvC8R7iWXqwNI9:21 a=RjFB5uIzcAI4r0ot:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=AcK2Xwxry4XOpw9gWFIK:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: oauth@ietf.org
References: <6604cde2-a936-7e66-034b-9282380205a6@hackmanit.de>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: <a720170f-cd50-7342-8f19-da94c11e719f@connect2id.com>
Date: Mon, 26 Oct 2020 17:06:49 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <6604cde2-a936-7e66-034b-9282380205a6@hackmanit.de>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020406050807060706080108"
X-CMAE-Envelope: MS4xfEN3xAlFJ1Ts2hKd0dXCfg4W4lm7NnFyehwJBc+t5CdqD05EPJHEA8XMEGXtdZPLSE3ln7Q2iXok8NDwP6v+qJp0ITLILy78HlEra0uIH8jIlA+fsivk e508dadaLPYGs2n7Llo80F+/j50UGcRP9d4+SXWu/5gk2te+OKdx8/UI8DJ8qfczI3vUbVD0eh0YYg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/jZtisWocvOB1ZZQA6BFLYrwnoV0>
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 15:06:54 -0000

Hi Karsten,

Thanks for the write up. I would like to suggest the name
authorization_response_iss_parameter_supported, instead of
iss_parameter_supported. To make it explicit and unambiguous that it's
about the authZ response.

Vladimir

On 26/10/2020 16:33, Karsten Meyer zu Selhausen 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
>