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

William Denniss <wdenniss@google.com> Wed, 31 May 2017 17:21 UTC

Return-Path: <wdenniss@google.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 187C0127BA3 for <oauth@ietfa.amsl.com>; Wed, 31 May 2017 10:21:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 LIhV2rQOR1cy for <oauth@ietfa.amsl.com>; Wed, 31 May 2017 10:21:05 -0700 (PDT)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 A20DF126E01 for <oauth@ietf.org>; Wed, 31 May 2017 10:21:05 -0700 (PDT)
Received: by mail-it0-x232.google.com with SMTP id r63so15582125itc.1 for <oauth@ietf.org>; Wed, 31 May 2017 10:21:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XjiTC7tEM5xKQ//jv42tLt7qF2C7BPUHBxG2KMy+rhI=; b=NpXrpwtAbfcrPDizlRyGKaWqh6Csh5zrYDLCiIqWVJcA/EkclQsAegF/jmKQ4z0KKo JAQ8Lm1tViYQIc/GkfZB+VrbdDNjA5iUVG+8rNfA5BZGvhjuDtmV4BanVPsT8avaxMN8 q14GbhVcldMSZ2lqitieRGpeJyVpq/46bsCxo7uyYEMvmvuaEpbFNZAas6Oaz60dvrjx muQpnOiJi6WVY99XhT3oro0tisDdpnUBm3QqQWHbe1DaZ4qFfMlxjavKf3rfD7+jIU6e r+OokC1cgdnMQAld+LIW5bP1Mfbumzq5pNwMlqEtDGcolgxDvqoJVOhFLlgcD5elZ1G/ sM0Q==
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=XjiTC7tEM5xKQ//jv42tLt7qF2C7BPUHBxG2KMy+rhI=; b=TVFsZhXnckvWePBgK3yUjHZrlvFqNinLRtpaufMZsfX1hDS4MAwiACZI0dTWqcelmV EmkBMzMqRk3ceQY0y57yla0zDnoU6Wu+BgJw5+vyt9vi+WfOy+3GjgtT4dK59zCI024W vylMcof6XprJbKv9hvyxhhNrhEVLuWOaWTYrJjbmGEPfbCX2skNwiJyYPcuAGDwbPqts ejoShxoHDz8hrL37q4vDxyrgOK3z2Sh9p22F9URtAlI7+s2myBhu/emZzOJUsw2GkEx5 i7fpd8Bd4Gs1MRIYQOaij6wAIFvDHs4wu4OgDSa0KLVG5hhG2yhlGJ0Gn0uQ7x7YOuAq v+Rw==
X-Gm-Message-State: AODbwcBLTDZijAh+EO7YO4qxf92T8RvYoBlGMuLMIkZy3pu8pnmEL8X3 aeUodL+GbhV1FGQ9apdbNaacvxXtV49fyP0=
X-Received: by 10.36.185.29 with SMTP id w29mr8056257ite.2.1496251264544; Wed, 31 May 2017 10:21:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.35.37 with HTTP; Wed, 31 May 2017 10:20:43 -0700 (PDT)
In-Reply-To: <CAGL6ep+rr5+aP-OReKzDnvNMk8-cB=CF_qekJcm+6+1A0UL3Ww@mail.gmail.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> <CAGL6ep+rr5+aP-OReKzDnvNMk8-cB=CF_qekJcm+6+1A0UL3Ww@mail.gmail.com>
From: William Denniss <wdenniss@google.com>
Date: Wed, 31 May 2017 10:20:43 -0700
Message-ID: <CAAP42hArRLVwGhNcKv-H6XV=B2FVsdnG-+dGtC1g1jQYK=M0Rw@mail.gmail.com>
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/related; boundary="f403045d97121f346b0550d5259c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/IID5BtlMeHKKYpgZWZvF_mVnuJ4>
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: Wed, 31 May 2017 17:21:08 -0000

Rifaat and Hannes,

Thank you for your review, and for the consensus judgement.  Version v06
<https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06> has been
posted that actions this feedback.

I would also like to see a WGLC issued on the document.

Best,
William

On Mon, May 8, 2017 at 6:02 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>;
wrote:

> 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
>>
>>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>