Re: [OAUTH-WG] Call for Adoption

Nat Sakimura <sakimura@gmail.com> Thu, 21 January 2016 07:16 UTC

Return-Path: <sakimura@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726C11A010F for <oauth@ietfa.amsl.com>; Wed, 20 Jan 2016 23:16:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 IzT25lgWwT99 for <oauth@ietfa.amsl.com>; Wed, 20 Jan 2016 23:16:51 -0800 (PST)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 097AA1A0107 for <oauth@ietf.org>; Wed, 20 Jan 2016 23:16:51 -0800 (PST)
Received: by mail-qk0-x234.google.com with SMTP id s68so12693607qkh.3 for <oauth@ietf.org>; Wed, 20 Jan 2016 23:16:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=E+LZjQ9zNtoCxbwO2X9Wa6wXx5/h9zFbcVSCJDAuYvs=; b=yVahPN4qU0K9gCq3ZD9NAgmY+tUq23y0aCT2TsSuN1CyJSmS98BnSNluhT2CgsFYUl 5zNhuItSY9S6e1Rw5esRWmqGc4xsVd1OKO0aZGFMUpKIVJXTCxYCbXi1GY81T+NC0k6r XD8P3/0Qj2OIlKx3IFj90tN8vYAWzlliKy3SB6U7ixJF7iHeR0qG5JgnEfNB6lUg2yw2 kQK28vMXjDdC/BP1CaSsU9uCHrbLOYXR2pt30n2vw65smKgxMwQRgvERWdfAYHjR0hNT NODaPn25EAGqhcrlbMefafP18LoJFexcPU9uB2XXjRU+tePDcbGsTWc5Ses1cFBQPILQ xmXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=E+LZjQ9zNtoCxbwO2X9Wa6wXx5/h9zFbcVSCJDAuYvs=; b=LnTFW1xWmtK6VZ1JLJbXJVnBFwz76Gkfk5pHUKA4pv52Vk/S8FYTG3qKyg4OQb7YYx 8blF6Z7rYrlxLzlMrdfmCMMqAxSD5Ou5VJMELKKkmUPWnu9Eux+4h1EUsDGzi1YSN5S5 YIaZzh5MKs4z585royK+H5XWmE6nShF6kHbBD+hMGV9JJ66GKwwwj2WWEgcwVolW81Z/ 1h7pQHLojofAUKGfozF7sv4xX5YjXhepcYvypVSFIb9Nq7MwaCeBV+Fs9Du5braU2iiz 9zxMywsdNwRw8k67Qg+2pS1RPJDLeBch4Ryizacvw62q9yADBkMA1AhxFRnfOCNBcTgc T6Yg==
X-Gm-Message-State: ALoCoQmbXa9qlKeN2F79dOcdh1WJBz6q9gAV3dsAOg4Y0zmSoa/eScWo4H5cgSHk+92h8B7ka+LClq4c8rNc6w5qjyPI1d37Jw==
X-Received: by 10.55.15.139 with SMTP id 11mr49812883qkp.50.1453360610079; Wed, 20 Jan 2016 23:16:50 -0800 (PST)
MIME-Version: 1.0
References: <569E2076.2090405@gmx.net> <CABzCy2D8BvJkLCc543=pEdE4FZa+p1ekyuMs=TtVSnSCrTrviw@mail.gmail.com> <CABzCy2D1gca2OR2qp_gakThjkoLGfaZAo=GE85Lz4+3TrPbFVQ@mail.gmail.com> <569F915D.8020806@mit.edu> <CAAP42hC+L-7irdR7Y2pfNWyhP6cWLn0wNyauA5TQb4jr=4UH4Q@mail.gmail.com> <BY2PR03MB442C2801F09B2B7A103E673F5C30@BY2PR03MB442.namprd03.prod.outlook.com>
In-Reply-To: <BY2PR03MB442C2801F09B2B7A103E673F5C30@BY2PR03MB442.namprd03.prod.outlook.com>
From: Nat Sakimura <sakimura@gmail.com>
Date: Thu, 21 Jan 2016 07:16:40 +0000
Message-ID: <CABzCy2DehwZh2gd_6oNy69O+qxowva00qZWnX8uWX2n4h+kPLw@mail.gmail.com>
To: Mike Jones <Michael.Jones@microsoft.com>, William Denniss <wdenniss@google.com>, Justin Richer <jricher@mit.edu>
Content-Type: multipart/alternative; boundary=001a1147446ee4f9140529d2e22c
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/NxbAwLLR8zBYVh0uII2bVeBIvd0>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 21 Jan 2016 07:16:54 -0000

Hi Mike.

Conversely, I would like to ask why this approach does not work for Mix-up
attack. As Nov stated, we in fact have discussed the approach in quite a
length back in Yokohama. I really would like to know why it does not work.

Besides, for oauth-meta approach, mix-up attack is only one of the thing it
solves.

Nat Sakimura

2016年1月21日(木) 16:02 Mike Jones <Michael.Jones@microsoft.com>;:

> Not to be negative, but I disagree with adopting
> draft-sakimura-oauth-meta.  We should define and promote one mitigation
> approach to the mix-up attacks.  Having two would confuse implementers and
> cause compatibility problems – reducing overall security.
>
>
>
> The approach defined in draft-jones-oauth-mix-up-mitigation was created in
> collaboration with the security researchers who identified the problems in
> the first place, was vigorously discussed in the security meeting Hannes
> and Torsten held in Darmstadt, and has been since refined based on
> substantial input from the working group.  And at least three implementers
> have already stated that they’ve implemented it.  I’m not saying that it’s,
> but if there are things missing or things that need to be improved in our
> approach, we should do it there, rather introducing a competing approach.
>
>
>
> Also, standard OAuth deployments register the client and then use the
> information gathered at registration time for subsequent protocol
> interactions.  They do not need all the configuration information for the
> authorization server to be retransmitted at runtime.  The oauth-meta draft
> goes too far in that direction, at least as I see it.  Returning things two
> ways creates its own problems, as discussed in the Duplicate Information
> Attacks security considerations section (7.2) of the mix-up-mitigation
> draft.
>
>
>
> I’ll note that the mix-up-mitigation approach is compatible with existing
> practice in both static and dynamic metadata discovery.  Replying to
> Justin’s comment that “It's the pre-configured discovery document that's
> at the root of the mix-up attack in the first place” – this is not the
> case.  The attacks can be performed without either discovery or dynamic
> registration.
>
>
>
> I would be interested in hearing a technical discussion on whether there
> are aspects of the oauth-meta approach that mitigate aspects of the attacks
> that the mix-up-mitigation approach does not.  That could help inform
> whether there are additional things we should add to or change in the
> mix-up draft.
>
>
>
>                                                           -- Mike
>
>
>
> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *William
> Denniss
> *Sent:* Wednesday, January 20, 2016 10:37 PM
> *To:* Justin Richer <jricher@mit.edu>;
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Call for Adoption
>
>
>
> +1 to adopt this, and I agree with Justin's comments.
>
>
>
> On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer <jricher@mit.edu>; wrote:
>
> +1
>
> Inline discovery and pre-configured discovery (ie, .well-known) should at
> the very least be compatible and developed together. It's the
> pre-configured discovery document that's at the root of the mix-up attack
> in the first place.
>
>  -- Justin
>
>
>
> On 1/19/2016 10:30 PM, Nat Sakimura wrote:
>
> Just to give more context, at IETF 94, I have done a presentation on
> discovery.
>
>
>
> According to the minutes,
>
>
>
>     (f) Discovery (Nat)
>
>
>
>              Nat explains his document as an example of the work that has to be done
>
>              in the area of discovery, which is a topic that has been identified
>
>              as necessary for interoperability since many years but so far there
>
>              was not time to work on it. Mike, John and Nat are working on a new
>
>              document that describes additional discovery-relevant components.
>
>
>
>              Poll: 19 for / zero against / 4 persons need more information.
>
>
>
> The document discussed there was
> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a
> simple (only 1-page!) but a very powerful document that nudges towards
> HATEOAS which is at the core of RESTful-ness. It also mitigates the Mix-up
> attack without introducing the concept of issuer which is not in RFC6749.
> It is also good for selecting different endpoints depending on the user
> authentication and authorization results and more privacy sensitive than
> pre-announced Discovery document. It also allows you to find to which
> protected resource endpoint you can use the access token against.
>
>
>
> In the last sentence of the minutes, it talks about "a new document that
> describes additional discovery-relevant components". This is
> https://tools.ietf.org/html/draft-jones-oauth-discovery-00.  It went for
> the call for adoption. However, it is only a half of the story. I believe
> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that was
> discussed at IETF 94 and had support there should be adopted as well.
>
>
>
> Nat Sakimura
>
>
>
>
>
>
>
>
>
> 2016年1月20日(水) 12:05 Nat Sakimura <sakimura@gmail.com>;:
>
> Thanks Hannes.
>
>
>
> I did not find https://tools.ietf.org/html/draft-sakimura-oauth-meta-05, which
> was discussed in Yokohama, and was largely in agreement if my recollection
> is correct. Why is it not in the call for adoption?
>
>
>
>
>
>
>
> 2016年1月19日(火) 20:39 Hannes Tschofenig <hannes.tschofenig@gmx.net>;:
>
> Hi all,
>
> we have submitted our new charter to the IESG (see
> http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html) and
> since some IESG members like to see an updated list of milestones as
> well. For this reason, based on a suggestion from Barry, we are also
> starting a call for adoption concurrently with the review of the charter
> text by the IESG.
>
> We will post separate mails on the individual documents. Your feedback
> is important! Please take the time to look at the documents and provide
> your feedback.
>
> Ciao
> Hannes & Derek
>
> _______________________________________________
> 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
>
>
>
>
> _______________________________________________
> 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
>