Re: [OAUTH-WG] [EXTERNAL] Re: Device Authorization Grant and Illicit Consent Exploits

[Brock Allen]

In the case of DEF CON video showing the Microsoft exploit, it worked liked 
this (if I recall correctly):

The attacker started the device flow from their system, sent the user a link to 
login with an "promo code" (the user code) to get a discount on their Microsoft 
bill, and when the user logged in they were prompted for the code (which they 
thought it was a promo code), and thus they granted access to the attacker 
waiting for the flow to be complete.

The problem was that:

1) The vendor's first party administrative CLI app was designed to use device 
flow.
2) The consent screen just said "Do you want to login to your Microsoft 
account".

So the issues were that for (1) device flow was just the wrong one (the native 
apps BCP w/ system browser should have been used), especially for an app with 
such high/privileged access, and for (2) the consent did not let the end-user 
know they were granting the client full administrative access.

So several missteps here that the protocol by itself can't completely protect 
against.

-Brock
On 3/23/2022 9:10:01 PM, George Fletcher  wrote:
I just want to make a quick comment on the use of "proximity and location 
information". I used the device flow to authorize my son's device by having him 
text me the code so I could login on my device (in a different state) and 
provide his device access. If we close the door too much we will potentially 
impact good users :)

I agree that consent can be socially engineered... but think that it would be 
useful to improve that information so that the user authenticating to provide 
authorization could know where the device their authorizing is located. That 
could help users detecting that they are authorizing a device in a location 
that doesn't make sense to them.

Thanks,
George


On 3/18/22 8:21 AM, Pieter Kasselman wrote:

Hi Brock
 
Great point, and I would agree that better consent screens could help, but I 
don’t think it is sufficient.
 
One of the challenges with consent screens is that it makes assumptions about 
the users abilities when they are being asked to make decisions about things 
they do not fully appreciate or understand. In addition, they are in a rush, 
are often trying to be helpful and prone to grant consent (the framing in these 
social engineering attacks can be very persuasive). Even users who are aware of 
these exploits and understand the systems they interact with are prone to be 
misled. Better guidance on the consent screen is definitely something we should 
provide.
 
I do think there is a defence in depth strategy that can reduce risk by (1) 
avoiding asking the user for a decision by making back-end risk decisions (2) 
augmenting the information presented to the user when making the decisions and 
(3) mitigating against a decision made in error.
 
Proximity and location information can for instance be used to bind user codes 
to specific locations or inform the user on where the user code was first 
presented, device status and/or location may be used to make decisions on 
whether to allow device code flows to be used in the first place and use of 
token binding (e.g. DPoP) may help defend against attackers who are able to 
exfiltrate tokens from a device and make lateral attacks.
 
Anything we can do to encourage implementor to ask users to make fewer 
decision, help them make better decisions and then protecting them in case of a 
bad decision will help drive down risk.
 
Cheers
 
Pieter
 
 
From: Brock Allen  [mailto:brockal...@gmail.com]
Sent: Thursday 17 March 2022 21:25
To: Pieter Kasselman  
[mailto:pieter.kassel...@microsoft.com]; oauth@ietf.org [mailto:oauth@ietf.org]
Subject: [EXTERNAL] Re: [OAUTH-WG] Device Authorization Grant and Illicit 
Consent Exploits
 
I watched one of those videos and it seems to be that a proper consent screen 
would have been the best and easiest line of defense. Is there something more 
to the attacks where a better consent page (or any consent page for that 
matter) would not have been sufficient?
 
-Brock
On 3/17/2022 5:10:35 PM, Pieter Kasselman 
mailto:pieter.kasselman=40microsoft@dmarc.ietf.org]> wrote:
Hi All 
 
One of the agenda items for IETF 113 is the device authorization grant flow 
(aka device code flow), scheduled for Thursday 24 March 2022. Before the 
meeting, I wanted to share a bit more information for those interested in the 
topic and also give those who are unable to attend in person an opportunity to 
participate in the conversation. 
 
The Device Authorization Grant Flow (RFC 8682) 
[https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8628data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cdab129df96fb4fe03c7908da085c8dae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637831490884440262%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=EswcNYKNZWEAWLBuOvQytd8TMlgpgUxIk0E%2FlfKkRIk%3Dreserved=0]
 solves an important problem 

Re: [OAUTH-WG] [EXTERNAL] Re: Device Authorization Grant and Illicit Consent Exploits

[George Fletcher]

I just want to make a quick comment on the use of "proximity and 
location information". I used the device flow to authorize my son's 
device by having him text me the code so I could login on my device (in 
a different state) and provide his device access. If we close the door 
too much we will potentially impact good users :)


I agree that consent can be socially engineered... but think that it 
would be useful to improve that information so that the user 
authenticating to provide authorization could know where the device 
their authorizing is located. That could help users detecting that they 
are authorizing a device in a location that doesn't make sense to them.


Thanks,
George

On 3/18/22 8:21 AM, Pieter Kasselman wrote:


Hi Brock

Great point, and I would agree that better consent screens could help, 
but I don’t think it is sufficient.


One of the challenges with consent screens is that it makes 
assumptions about the users abilities when they are being asked to 
make decisions about things they do not fully appreciate or 
understand. In addition, they are in a rush, are often trying to be 
helpful and prone to grant consent (the framing in these social 
engineering attacks can be very persuasive). Even users who are aware 
of these exploits and understand the systems they interact with are 
prone to be misled. Better guidance on the consent screen is 
definitely something we should provide.


I do think there is a defence in depth strategy that can reduce risk 
by (1) avoiding asking the user for a decision by making back-end risk 
decisions (2) augmenting the information presented to the user when 
making the decisions and (3) mitigating against a decision made in error.


Proximity and location information can for instance be used to bind 
user codes to specific locations or inform the user on where the user 
code was first presented, device status and/or location may be used to 
make decisions on whether to allow device code flows to be used in the 
first place and use of token binding (e.g. DPoP) may help defend 
against attackers who are able to exfiltrate tokens from a device and 
make lateral attacks.


Anything we can do to encourage implementor to ask users to make fewer 
decision, help them make better decisions and then protecting them in 
case of a bad decision will help drive down risk.


Cheers

Pieter

*From:*Brock Allen 
*Sent:* Thursday 17 March 2022 21:25
*To:* Pieter Kasselman ; oauth@ietf.org
*Subject:* [EXTERNAL] Re: [OAUTH-WG] Device Authorization Grant and 
Illicit Consent Exploits


I watched one of those videos and it seems to be that a proper consent 
screen would have been the best and easiest line of defense. Is there 
something more to the attacks where a better consent page (or any 
consent page for that matter) would not have been sufficient?


-Brock

On 3/17/2022 5:10:35 PM, Pieter Kasselman
 wrote:

Hi All

One of the agenda items for IETF 113 is the device authorization
grant flow (aka device code flow), scheduled for Thursday 24 March
2022.  Before the meeting, I wanted to share a bit more
information for those interested in the topic and also give those
who are unable to attend in person an opportunity to participate
in the conversation.

The Device Authorization Grant Flow (RFC 8682)

solves
an important problem by enabling authorization flows on devices
that are unable to support a browsers or have limited input
capabilities. However, looking back over the past 18-24 months,
there have been a number of practical exploits published that use
social engineering techniques applied to the device authorization
grant flow.

The goal of the session at IETF 113 is to discuss the patterns of
the exploits that are known and start a conversation on what (if
anything) we should do, based on what we are learning.

These exploits follow a general man-in-the-middle (MITM) pattern,
where the attacker:

 1. Initiates the Device Authorization Grant flow on a device
under their control,
 2. Presents the user code in a context that the end-user is
likely to act on (using social engineering techniques), and
 3. Once the user grants access, retrieves the access and refresh
tokens and uses them to access the user’s resources.

Some of the exploits are described here for those interested in
more detail:

 1. The Art of the Device Code Phish - Boku (0xboku.com)

Re: [OAUTH-WG] Comments on ietf-oauth-dpop

[Rohan Mahy]

Hi Brian,

To be clear, for pre-generated proofs, I am not worried about an attack
against the client; I am worried about a malicious client. Imagine a
malicious client which pre-generates proofs during a brief window while it
has access to a private key stored on the iOS secure enclave, or on a
Yubikey, or a non-extractable WebCryptoAPI CryptoKey. The ability to
pre-generate proofs with no lifetime effectively makes these
non-extractable key protections meaningless for some fixed number of
proofs. If the WG does not want to make server nonces a SHOULD, then I
suggest the following:
"Server implementations need some protection against arbitrary
pre-generation. Servers MUST require all client proofs to contain either a
server-provided nonce, or a server-provided explicit expiration time, or
both."

Adding "(on the order of seconds or minutes)" would already be a big
improvement to what is in the document.

The linkage between Figure 12 and Figure 13 is clear. I was talking about
the linkage between Figure 5 (or the refresh response to Figure 6) and the
token hash in Figure 12.

Many Thanks,
-rohan


*Rohan Mahy  *l  Vice President Engineering, Architecture

Chat: @rohan_wire on Wire



Wire  - Secure team messaging.

*Zeta Project Germany GmbH  *l  Rosenthaler Straße 40,
10178
Berlin,

Germany


Geschäftsführer/Managing Director: Morten J. Broegger

HRB 149847 beim Handelsregister Charlottenburg, Berlin

VAT-ID DE288748675


On Wed, Mar 23, 2022 at 8:17 AM Brian Campbell  wrote:

> Thanks Rohan,
>
> Pre-generating a proof requires the ability to execute code on the client,
> which is already a problematic situation where other (arguably more)
> serious attacks are possible. Such as driving a whole attack directly from
> the client. The draft aims to give servers the option to use a nonce but
> not push it too much or overstate its protections.
>
> The vagueness around lifetimes is somewhat intentional. At one point the
> document (maybe aspirationally) had something like 'no more than a few
> seconds' but there was some push-back that it was unrealistically short to
> accommodate real world client clock skew. I'm not sure the draft can make a
> much more concrete recommendation as I think it really is something that
> has tradeoffs and will be implementation/deployment specific. Perhaps
> something like, "(on the order of seconds or minutes)" could be added as a
> qualifier around lifetime leniency? That maybe gives a general idea of what
> is acceptable and/or relatively brief without being overly prescriptive.
> I'm quite hesitant to say anything more specific.
>
> An access token and its "ath" hash value are shown as part of the examples
> https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-06.html#figure-12
> and
> https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-06.html#figure-13
> respectively. Perhaps it'd be worthwhile to more explicitly mention the
> relationship between the two examples? I think I did the calculations
> correctly but anyone double checking that work would be welcome. The
> sentence in sec 4.3 step 11 is already pretty darn verbose - probably too
> much so. I think breaking it up would probably be a better way to make it
> more clear.
>
> The MIME type registration will be in the next revision
> https://mailarchive.ietf.org/arch/msg/oauth/Vj24ZXU4UuG6Rr04U1Cdrz2rx3o/
>
> I'll work those nits and fix things up as appropriate.
>
>
>
>
>
>
> On Tue, Mar 22, 2022 at 4:24 PM Rohan Mahy  40wire@dmarc.ietf.org> wrote:
>
>> Hi,
>> Here are some comments on draft-ietf-oauth-dpop-06:
>>
>> 1) With such a significant attack possible as DPoP proof pre-generation,
>> why isn't using the server nonce a SHOULD? Preventing a significant attack
>> and making lifetime handling sane are two excellent reasons to use a server
>> nonce. If an implementation has a good reason to not use a server nonce, we
>> can give guidance about what additional steps the implementation needs to
>> take.
>>
>> 2) The handling of lifetimes of DPoP proofs is vague: "acceptable
>> timeframe" (Section 4.3), "relatively brief period" (Section 11.1). Is that
>> 1 day,15 minutes, or 30 seconds?
>> The normative text in the two sections seem contradictory.
>> I think you need a lifetime parameter if a server nonce isn't included,
>> or just pick a number (5 minutes?).
>>
>> 3) I had a similar thought to Nicolas Mora about including other
>> assertions/tokens. There should be a way to chain, include, or reference
>> other OAuth assertions and bind them somehow with the DPoP. This will be a
>> common and important model.
>>
>> 4. Right now you describe the access token hash before describing the
>> 

Re: [OAUTH-WG] Comments on ietf-oauth-dpop

[Brian Campbell]

Thanks Rohan,

Pre-generating a proof requires the ability to execute code on the client,
which is already a problematic situation where other (arguably more)
serious attacks are possible. Such as driving a whole attack directly from
the client. The draft aims to give servers the option to use a nonce but
not push it too much or overstate its protections.

The vagueness around lifetimes is somewhat intentional. At one point the
document (maybe aspirationally) had something like 'no more than a few
seconds' but there was some push-back that it was unrealistically short to
accommodate real world client clock skew. I'm not sure the draft can make a
much more concrete recommendation as I think it really is something that
has tradeoffs and will be implementation/deployment specific. Perhaps
something like, "(on the order of seconds or minutes)" could be added as a
qualifier around lifetime leniency? That maybe gives a general idea of what
is acceptable and/or relatively brief without being overly prescriptive.
I'm quite hesitant to say anything more specific.

An access token and its "ath" hash value are shown as part of the examples
https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-06.html#figure-12 and
https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-06.html#figure-13
respectively. Perhaps it'd be worthwhile to more explicitly mention the
relationship between the two examples? I think I did the calculations
correctly but anyone double checking that work would be welcome. The
sentence in sec 4.3 step 11 is already pretty darn verbose - probably too
much so. I think breaking it up would probably be a better way to make it
more clear.

The MIME type registration will be in the next revision
https://mailarchive.ietf.org/arch/msg/oauth/Vj24ZXU4UuG6Rr04U1Cdrz2rx3o/

I'll work those nits and fix things up as appropriate.






On Tue, Mar 22, 2022 at 4:24 PM Rohan Mahy  wrote:

> Hi,
> Here are some comments on draft-ietf-oauth-dpop-06:
>
> 1) With such a significant attack possible as DPoP proof pre-generation,
> why isn't using the server nonce a SHOULD? Preventing a significant attack
> and making lifetime handling sane are two excellent reasons to use a server
> nonce. If an implementation has a good reason to not use a server nonce, we
> can give guidance about what additional steps the implementation needs to
> take.
>
> 2) The handling of lifetimes of DPoP proofs is vague: "acceptable
> timeframe" (Section 4.3), "relatively brief period" (Section 11.1). Is that
> 1 day,15 minutes, or 30 seconds?
> The normative text in the two sections seem contradictory.
> I think you need a lifetime parameter if a server nonce isn't included, or
> just pick a number (5 minutes?).
>
> 3) I had a similar thought to Nicolas Mora about including other
> assertions/tokens. There should be a way to chain, include, or reference
> other OAuth assertions and bind them somehow with the DPoP. This will be a
> common and important model.
>
> 4. Right now you describe the access token hash before describing the
> access token itself. I think it would be very useful to show the a worked
> example of an access token and then its hash used subsequently. Also
> Section 4.3 step 11 feels like a circular description. Please rewrite more
> verbosely to be clearer:
> Currently:
> "when presented to a protected resource in conjunction with an access
> token, ensure that the value of the ath claim equals the hash of that
> access token and confirm that the public key to which the access token is
> bound matches the public key from the DPoP proof."
>
> 5. Re: IANA registration of the MIME type. TL;DR: Just register
> application/dpop+jwt.
> Long version: The semantics of the thing you want to register is
> application/dpop. The first syntax you are defining is jwt. For example,
> iCalendar has three formats: text/calendar (iCal),
> application/calendar+json (jCal), and application/calendar+xml (xCal).
>
> NITS:
> - Spell out first use of acronyms: JWT, JWK, JWS, TLS, JOSE, PKCE,
> - Add reference to TLS, XSS, Crime/Heartbleed/BREACH/etc., HTTP, JOSE, on
> first use
> - First sentence of Section 2 (Objectives): add a comma (access tokens_,_
> by binding) to make it clear that "binding a token" is doing the preventing
> instead of the stealing in the sentence.
> - Section 2 para 5: s/XXS/XSS/
> - Maybe mention why you are using ASCII (7-bit) when the charset in the
> examples is UTF-8.
>
> I hope these comments are useful.
> Many thanks,
> -rohan
>
>
> *Rohan Mahy  *l  Vice President Engineering, Architecture
>
> Chat: @rohan_wire on Wire
>
>
>
> Wire  - Secure team messaging.
>
> *Zeta Project Germany GmbH  *l  Rosenthaler Straße 40,
> 10178
> Berlin,
> 
> Germany
> 

Re: [OAUTH-WG] Comments on ietf-oauth-dpop

[Joseph Heenan]

Hi Rohan,


> On 22 Mar 2022, at 15:24, Rohan Mahy  
> wrote:
> 
> Here are some comments on draft-ietf-oauth-dpop-06:
> 
> 1) With such a significant attack possible as DPoP proof pre-generation, why 
> isn't using the server nonce a SHOULD? Preventing a significant attack and 
> making lifetime handling sane are two excellent reasons to use a server 
> nonce. If an implementation has a good reason to not use a server nonce, we 
> can give guidance about what additional steps the implementation needs to 
> take. 

I think this is a good question, and I’ve been wondering about it myself.

The argument I see for not more strongly requiring nonces is that it pushes 
additional and non-trivial implementation complexity onto clients (and arguably 
also onto resource servers).

There are situations where I am not sure a nonce adds much value - for example 
in the case of a confidential client, an attacker with access to pre-generate 
DPoP proofs can likely also pre-generate private_key_jwt client authentication 
assertions and likely also has access to any refresh token. I believe this 
would allow them to obtain access tokens bound to a DPoP key of their choosing, 
and a nonce then seems to provide no additional protection.

(There are also cases where the nonce clearly does add a lot of value, 
particularly when considering public clients, and there may well be an argument 
for a ’should’ in those cases. Conversely I think there’s a potential argument 
for saying you should not use nonces in the confidential client situation I 
outlined, as it adds little other than complexity.)

Thanks

Joseph

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Newbie server implementation question

[Gevik Babakhani]

Hi all,

I would like to implement my own OAuth authorisation server and started reading 
"Aaron Parecki” book. My goal is to implement an OpenID connect provider at the 
end.
I was wondering if there is a certification or validation/testing program that 
can help me verify my implementation similar to OIDC certification?

Regards,
Gevik.___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth