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 protected]>
Sent: Monday, March 19, 2018 9:23 AM
To: Eric Rescorla <[email protected]>; [email protected]
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 protected]>
Sent: Saturday, February 24, 2018 10:58 PM
To:
[email protected]<mailto:[email protected]>
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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
