Return-Path: 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 E1F1D12D1AE for ; Sat, 30 Apr 2016 22:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-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 yL0TqwvdllS6 for ; Sat, 30 Apr 2016 22:22:00 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 0995612B00D for ; Sat, 30 Apr 2016 22:21:57 -0700 (PDT) X-AuditID: 1209190e-cffff70000004bd5-84-57259274da2a Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id F2.98.19413.47295275; Sun, 1 May 2016 01:21:56 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u415Lt4e011524; Sun, 1 May 2016 01:21:56 -0400 Received: from [10.9.0.128] (173-167-121-101-sfba.hfc.comcastbusiness.net [173.167.121.101]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u415LqKK031646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 1 May 2016 01:21:54 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_37F9CA40-9121-4721-9FDF-52D7F4AA3722" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Justin Richer In-Reply-To: <49355f12-ef58-0637-47e0-7acd54e882d9@lodderstedt.net> Date: Sat, 30 Apr 2016 22:21:52 -0700 Message-Id: References: <571B60BA.8090301@lodderstedt.net> <49355f12-ef58-0637-47e0-7acd54e882d9@lodderstedt.net> To: Torsten Lodderstadt X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IR4hTV1i2ZpBpu8P6YnMXJt6/YLM7cWsFo 8erYUxYHZo+ds+6yeyxZ8pPJ41hPP2sAcxSXTUpqTmZZapG+XQJXRveyNtaCSaEVP47UNTBO d+li5OCQEDCRaHme0sXIxSEk0MYkcWnBM1YIZwOjxJ7OHywQzg0mic23FwNlODmYBRIkHp5/ yAhi8wroSWxa/5YJxBYWMJNYvuYGM4jNJqAqMX1NC1icU8BZ4vW3yywgNgtQ/MXjg1BzvCRe vn/JDDHHSmLLmpWMEMtWMUo8a2lkBTlPRMBQ4tecTJAaCQFZiScnF7FMYOSfheSMWUjOgIhr Syxb+JoZwtaU2N+9nAVTXEOi89tE1gWMbKsYZVNyq3RzEzNzilOTdYuTE/PyUot0jfVyM0v0 UlNKNzGCQ12SbwfjpAbvQ4wCHIxKPLwvDFXDhVgTy4orcw8xSnIwKYnyzpirEi7El5SfUpmR WJwRX1Sak1p8iFGCg1lJhHdJH1A5b0piZVVqUT5MSpqDRUmcl5GBgUFIID2xJDU7NbUgtQgm K8PBoSTBWzkRqFGwKDU9tSItM6cEIc3EwQkynAdo+P4JIMOLCxJzizPTIfKnGBWlxHlLQJoF QBIZpXlwvaBUtHZ5ZeorRnGgV4R5/UCqeIBpDK77FdBgJqDBApsUQQaXJCKkpBoYJ74TSZi5 +a1749n+2xznLrbYKJQ7203bcvBvUWjVjkrZS206Gf92fldw3n6g2pfzrJF01MePsfP8wmaJ TSjad2rdtdmnnhxcEfG4UvBU5G2Ng5JP1807Wbtl10KJe9FPlh5zNDOZejzY4V1xV3fOzHmv JSNjDN6kGU5qmP5eVGvbstDde654PFJiKc5INNRiLipOBABCWElVIAMAAA== Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Mix-Up and CnP/ Code injection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 05:22:03 -0000 --Apple-Mail=_37F9CA40-9121-4721-9FDF-52D7F4AA3722 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree that we=E2=80=99re getting dangerously close to recommending = signed assertions at every step of the process, thereby bypassing HTTP. = This was the same mistake that WS-* and SOAP made, let=E2=80=99s not = repeat it if we can. =E2=80=94 Justin > On Apr 30, 2016, at 10:57 AM, Torsten Lodderstedt = wrote: >=20 > Hi Nat, >=20 > sure, one could also authenticate and cryptographically protect the = redirect response. Leveraging OIDC concepts is an idea worth considering = but they should be adopted to the OAuth philosophy. The id token as used = in the hybrid flows mixes an identity assertion with elements of = transport security measures. A OAuth AS does not provide identity data = to clients, so we only need the transport security part.=20 > I personally would prefer a OAuth response object (similar to request = object you have proposed) over the id token. Such a response object = could contain (and directly protect) state, code and other response = values. I consider this the more elegant design and it is easier to = implement then having detached signatures over hash values of codes or = access tokens. Moreover, it would allow to encrypt the response as well.=20= > Generally, our threat analysis so far does not have provided = justification for cryptographically protected redirect responses. All = proposals currently on the table stop mix up and code injection using = simpler mechanisms.=20 > I think OAuth 2.0 is a huge success due to its balance of versatility, = security and _simplicity_. We definitely need to keep it secure, but we = should also keep it as simple as possible. > kind regards, > Torsten. > Am 29.04.2016 um 10:08 schrieb Nat Sakimura: >> As I look at it more and more, it started to look like the problem of = accepting tainted values without message authentication. To fix the root = cause, we would have to authenticate response. ID Token was designed to = also serve as a solution anticipating it.=20 >>=20 >> Any concrete ideas?=20 >>=20 >> On Sat, Apr 23, 2016 at 04:47 Torsten Lodderstedt = > wrote: >> Hi all, >>=20 >> discussion about Mix-Up and CnP seems to have stopped after the = session >> in BA - at least in the OAuth WG. There is a discussion about >> mitigations in OpenId Connect going on at the OpenId Connect mailing = list. >>=20 >> I'm very much interested to find a solution within the OAuth realm as >> I'm not interested to either implement two solutions (for OpenId = Connect >> and OAuth) or adopt a OpenId-specific solution to OAuth (use id! = tokens >> in the front channel). I therefore would like to see progress and >> propose to continue the discussion regarding mitigations for both = threats. >>=20 >> https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-00 = >> proposes reasonable mitigations for both attacks. There are = alternatives >> as well: >> - mix up: >> -- AS specific redirect uris >> -- Meta data/turi >> (https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5 = ) >> - CnP: >> -- use of the nonce parameter (as a distinct mitigation beside state = for >> counter XSRF) >>=20 >> Anyone having an opinion? >>=20 >> best regards, >> Torsten. >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_37F9CA40-9121-4721-9FDF-52D7F4AA3722 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I agree that we=E2=80=99re getting dangerously close to = recommending signed assertions at every step of the process, thereby = bypassing HTTP. This was the same mistake that WS-* and SOAP made, = let=E2=80=99s not repeat it if we can.

 =E2=80=94 Justin

On Apr 30, 2016, at 10:57 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=20

Hi = Nat,

sure, one could also authenticate and = cryptographically protect the redirect response. Leveraging OIDC concepts is an idea worth considering but they should be adopted to the OAuth philosophy. The id token as used in the hybrid flows mixes an identity assertion with elements of transport security measures. A OAuth AS does not provide identity data to clients, so we only need the transport security part.

I personally would prefer a OAuth response object = (similar to request object you have proposed) over the id token. Such a response object could contain (and directly protect) state, code and other response values. I consider this the more elegant design and it is easier to implement then having detached signatures over hash values of codes or access tokens. Moreover, it would allow to encrypt the response as well.

Generally, our threat analysis so far does not = have provided justification for cryptographically protected redirect responses. All proposals currently on the table stop mix up and code injection using simpler mechanisms.

I think OAuth 2.0 is a huge success due to its = balance of versatility, security and _simplicity_. We definitely need to keep it secure, but we should also keep it as simple as possible.

kind regards,
Torsten.

Am 29.04.2016 um 10:08 schrieb Nat Sakimura:
As I look at it more and more, it = started to look like the problem of accepting tainted values without message authentication. To fix the root cause, we would have to authenticate response. ID Token was designed to also serve as a solution anticipating it.

Any concrete ideas?

On Sat, Apr 23, 2016 at 04:47 = Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi all,

discussion about Mix-Up and CnP seems to have stopped after the session
in BA - at least in the OAuth WG. There is a discussion = about
mitigations in OpenId Connect going on at the OpenId Connect mailing list.

I'm very much interested to find a solution within the OAuth realm as
I'm not interested to either implement two solutions (for OpenId Connect
and OAuth) or adopt a OpenId-specific solution to OAuth (use id! tokens
in the front channel). I therefore would like to see progress and
propose to continue the discussion regarding mitigations for both threats.

https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-= 00
proposes reasonable mitigations for both attacks. There are alternatives
as well:
- mix up:
-- AS specific redirect uris
-- Meta data/turi
(https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#sectio= n-5)
- CnP:
-- use of the nonce parameter (as a distinct mitigation beside state for
counter XSRF)

Anyone having an opinion?

best regards,
Torsten.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_37F9CA40-9121-4721-9FDF-52D7F4AA3722--