Re: [OAUTH-WG] OAuth 2.0 Device Flow: IETF98 Follow-up

Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> Mon, 08 May 2017 13:02 UTC

Return-Path: <rifaat.ietf@gmail.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 A82EF129467 for <oauth@ietfa.amsl.com>; Mon, 8 May 2017 06:02:30 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 fVt-P96T2qJj for <oauth@ietfa.amsl.com>; Mon, 8 May 2017 06:02:23 -0700 (PDT)
Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (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 EAC3B129465 for <oauth@ietf.org>; Mon, 8 May 2017 06:02:22 -0700 (PDT)
Received: by mail-ua0-x230.google.com with SMTP id e55so40261646uaa.2 for <oauth@ietf.org>; Mon, 08 May 2017 06:02:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SXnegd+RCc48ZHH6jHdpDSUPoHc+XPUlMgTCMA5fSaI=; b=WVpnP/JDPID8xOMui4m31+HjflOPJf3jEVsY/PZYwxGPr2DkQHYgH9/LlOr1kmNeJy yfumkds+q/mDohMym9j4FadA3gBzD7yiUkWBqAsCDjWtrUPl8sSg/l5jhLOzT3jQijj4 +vzlvgyUaMvNMc6mAy4e7LrE+8+zyflkFjo63bO2VeKwmXzcyzd5CyAVJ/9sVFOhmtaO /cENVo9IJQu9Js7YzCWag7QT0hRvUIHihWn+3RiuJtabN33asVyLOtoq1f9GkOws5ZYa kTLIfeQOsX+xNT8YPCiEtX6RSIobxCTPumeMP/B/I9TLey9SMpQA7sQoMOfgRbPeUrZc 4qIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SXnegd+RCc48ZHH6jHdpDSUPoHc+XPUlMgTCMA5fSaI=; b=uIxAakf5MZLYRdedZQr5w0e0V/KJeoQC3nKb+F+FvdOnI+UyzC2YURmxuoXWvyX2DB EHxNp8RFz28rETXQ1YILBJMGI2+B+pLolVqUZlitHEKrSUUhVEiZ2PjBCijI+mVuSxlM yrd4P1txKYCPFOS4hOZaMUbnNazloMfkdrLqya5i9SAbvxB4irs4v2Z7t3T6lIibpLV3 gOPTK6mqyhN+kb1Rz/ePBJuh96ea3uWkJPrkRy7uu3iEYewTwXJ3Eg4W+Rw6bipRC8uB 0jjlCvvIvGpkUkKe65ESqd+UjuRIFvl1pRQSY+ejAGZV5udqWQiLCJaXSqXyJkG7+ucX L0MQ==
X-Gm-Message-State: AN3rC/6vklWoP4558y4RMILbKjlKWKdf+MQytYgCBz/S87SiN/OFF6uZ F+p5MQobVY460dErk1sOx9L21cwFmC1P
X-Received: by 10.176.6.197 with SMTP id g63mr15397719uag.52.1494248541749; Mon, 08 May 2017 06:02:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.76.91 with HTTP; Mon, 8 May 2017 06:02:21 -0700 (PDT)
In-Reply-To: <5529a18f-0ebe-eeae-2de1-c4066cf986b3@forgerock.com>
References: <CAAP42hDugtAz-7MaeVcNsS+Oza1GVKRyGm4vfR6Vj1DFF1-nag@mail.gmail.com> <77856AF4-9B2E-4478-9509-1459037C24E4@ve7jtb.com> <22d06952-94ab-e6a9-d2b2-f96f8252bf5e@mit.edu> <4107AB98-25D8-4542-B932-CD6F921D0D1D@lodderstedt.net> <5529a18f-0ebe-eeae-2de1-c4066cf986b3@forgerock.com>
From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Mon, 8 May 2017 09:02:21 -0400
Message-ID: <CAGL6ep+rr5+aP-OReKzDnvNMk8-cB=CF_qekJcm+6+1A0UL3Ww@mail.gmail.com>
To: Simon Moffatt <simon.moffatt@forgerock.com>
Cc: Torsten Lodderstedt <torsten@lodderstedt.net>, Justin Richer <jricher@mit.edu>, "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/related; boundary=94eb2c122e648c1039054f02d9ca
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/y5O_zeyha596EwthVzNqUos0OgI>
Subject: Re: [OAUTH-WG] OAuth 2.0 Device Flow: IETF98 Follow-up
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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, 08 May 2017 13:02:30 -0000

All,

Hannes and I discussed the Device Flow draft. Based on the mailing list
feedback, we see that there is a good support for keeping the "user_code"
parameter in, but there is a need to document the security implication of
this feature. If anyone is against keeping this feature, please speak up
now.


*William,*

Can you please update the document based on the feedback you received so
far?
We would like to start a WGLC after we get the new version of the draft.


We also have few comments on v05 of the draft:

Section 3.3, second paragraph:

   The document should explicitly state that this step must be done over an
   HTTPS channel.

   Also, the paragraph is talking about an "end-user" performing the
   procedure. This could be done by an administrator that has a long list
   of devices, e.g. IoT devices, that support this mechanism. So, maybe the
   document should clearly state that too.


Nits:

Section 3.3, 3rd paragraph, second line:
   Remove the "a" before "the browser"

Section 5.2, 1st paragraph, second line:
   Remove the word "they" after "attacker"

Regards,
 Rifaat & Hannes



On Tue, May 2, 2017 at 4:56 AM, Simon Moffatt <simon.moffatt@forgerock.com>;
wrote:

> +1 for separate. The real world implementations we've seen tend to not
> need the URL at all.  Eg end user out of band is in a web application on
> the their laptop/tablet and that app has a "pair device" area, where they
> just enter the necessary code - so they don't even need to see/use a URL
> from the device.
>
> Having the code augmented in to the URL too opens up the ability for that
> code to be logged on intermediary network devices.
>
> SM
>
> On 02/05/17 06:32, Torsten Lodderstedt wrote:
>
> +1 to keep the optional parameter along with clear wording regarding
> security risk and interoperability
>
> Am 29.04.2017 um 15:12 schrieb Justin Richer <jricher@mit.edu>;:
>
> +1, documentation is better. Though we also need to keep in mind that this
> was the justification for the password flow in 6749, which has been abused
> all over the place (and continues to this day). Still, it would be arguably
> worse without that so I'm good with keeping the parameter in there as long
> as we're careful.
>
> Namely: So long as the user code is *also* delivered separately to the
> user, we would have interoperability between the two. What I don't think we
> want is some systems that *require* the URI parameter on the approval URL
> and other implementations that *forbid* it. That case could end up with
> something like: I've got a set-top system that's incapable of displaying a
> separate user code because it always assumes it's baked into the URL, and
> then I try to put it on a server that requires the code be entered
> separately.
>
> The resulting spec needs to be clear that the box MUST be able to display
> both the URL and the code separately, in case the URL does not include the
> code. In fact, maybe we'd even want to introduce a new parameter from the
> endpoint for the pre-composed URL:
>
>    user_code
>       REQUIRED.  The end-user verification code.
>
>    verification_uri
>       REQUIRED.  The end-user verification URI on the authorization
>       server.  The URI should be short and easy to remember as end-
>       users will be asked to manually type it into their user-agent.
>
>    composite_verification_uri
>       OPTIONAL.  The end-user verification URI with the end-user
>       verification code already included. See discussion in [blah]
>       for its use.
>
>  -- Justin
>
>
> On 4/28/2017 6:38 PM, John Bradley wrote:
>
> I would like to keep the optional parameter.   It is useful enough that if
> we don’t have it people will add it on there own as a custom parameter.
> Better to document any issues.
>
> John B.
>
> On Apr 28, 2017, at 5:39 PM, William Denniss <wdenniss@google.com>; wrote:
>
> Thanks all who joined us in Chicago in person and remotely last month for
> the discussion on the device flow. [recording here
> <https://play.conf.meetecho.com/Playout/?session=IETF98-OAUTH-20170327-1710>;,
> presentation starts at about 7min in].
>
> The most contentious topic was addition of the user_code URI param
> extension (introduced in version 05, documented in Section 3.3
> <https://tools.ietf.org/html/draft-ietf-oauth-device-flow-05#section-3.3>
> ).
>
> I'd like to close out that discussion with a decision soon so we can
> advance to a WG last call on the draft.
>
> To summarise my thoughts on the param:
>
>    1. It can be can be used to improve usability – QR codes and NFC can
>    be used with this feature to create a more delightful user authorization
>    experience.
>    2. It may increase the potential phishing risk (which we can
>    document), as the user has less typing. This risk assessment is likely not
>    one-size-fits-all, it may vary widely due to different the different
>    potential applications of this standard.
>    3. The way it's worded makes it completely optional, leaving it up to
>    the discretion of the authorization server on whether to offer the
>    optimisation, allowing them to secure it as best they see it.
>    4. I do believe it is possible to design a secure user experiance that
>    includes this optimization.
>
> I think on the balance, it's worthwhile feature to include, and one that
> benefits interop. The authorization server has complete control over
> whether to enable this feature – as Justin pointed out in the meeting, it
> degrades really nicely – and should they enable it, they have control over
> the user experiance and can add whatever phishing mitigations their
> use-case warrants.  Rarely is there a one-size-fits-all risk profile,
> use-cases of this flow range widely from mass-market TV apps to
> internal-only device bootstrapping by employees, so I don't think we should
> be overly prescriptive.
>
> Mitigating phishing is already something that is in the domain of the
> authorization server with OAuth generally, and I know that this is an
> extremely important consideration when designing user authorization flows.
> This spec will be no exception to that, with or without this optimization.
>
> That's my opinion. I'm keen to continue the discussion from Chicago and
> reach rough consensus so we can progress forward.
>
> Best,
> William
>
>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> --
> [image: ForgeRock] <http://www.forgerock.com/> *Simon Moffatt*
> Product Management  |  ForgeRock
> *tel* +44 (0) 7903 347 240 <+44%207903%20347240>  |  *e*
> Simon.Moffatt@Forgerock.com <simon.moffatt@forgerock.com>;
> *skype* simon.moffatt  |  *web* www.forgerock.com  |  *twitter*
> @simonmoffatt
> [image: ForgeRock Live 2017] <https://summits.forgerock.com/>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>