Subject: Re: [OAUTH-WG] First look at: draft-ietf-oauth-device-flow

From: Mike Jones <[email-masked]>
Date: Mon, 23 Apr 2018 19:17:48 +0000

Hi Ekr,

https://tools.ietf.org/html/draft-ietf-oauth-device-flow-09  Sections 5.2 and 5.3 have been updated as proposed below.

                                                                -- Mike

From: John Bradley <[email-masked]>
Sent: Monday, March 19, 2018 9:23 AM
To: Eric Rescorla <[email-masked]>; [email-masked]
Subject: RE: First look at: draft-ietf-oauth-device-flow

If an Authorization Server is malicious, then it could man-in-the middle the backchannel flow to another AS.

Note that the device manufacturer must either be the attacker or be using an authorization server that is controlled by an attacker for this attack to be possible.  We can amplify Section 5.2 (Device Trustworthiness) to make this explicit.  In part, the person purchasing the device is counting on it and its business partners to be trustworthy.

As a concrete example, Netflix could man-in-the middle Amazon Prime to get an access token as the user’s device.   For that to work, the user would need to select Netflix on the TV and get back the URI for Amazon Prime video to enter.  They would hopefully notice that they are being sent to the wrong site.

We could expand Section 5.3 (Remote Phishing) to encourage the AS to display information about the device/client so that they would notice if a software client was impersonating a Roku. We currently only talk about informing the user that they are authenticating a device.

This is not the only place in OAuth where we have issues with clients being able to impersonate other clients.  To completely prevent this attack, we would need a client attestation or some form of client credential like a certificate using MTLS for authentication.

Dynamic client registration based on a software statement containing the clients public key would work but raises the deployment bar significantly.

John B.

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: Eric Rescorla<mailto:[email-masked]>
Sent: Saturday, February 24, 2018 10:58 PM
To: [email-masked]<mailto:[email-masked]>
Subject: First look at: draft-ietf-oauth-device-flow

I am concerned about the security of this mechanism. In S 5.3 you
describe a phishing attack, but it seems like there is a confused
deputy attack when a user has accounts on two services, A and B, where
A gets the user to authenticate to B for them:

Client                   A                          B

Client Identifier (A) --->
                           Client identifier (B) --->
                           <- Verification URI + Code
<- Verification URI + Code
User authorization --------------------------------->
                           Poll -------------------->
                           <------------ Access Token

The idea here is that A connects to B claiming to be Client
and then gets the authorization information for the Client->B
interaction, which it convinces Client to supply to B along
with its ambient authority.

Is this a real attack? If not, what am I missing?

-Ekr