Hi Vladimir,
Thank you for your detailed response. Yes, I completely agree with your
point about the issue with encryption.
Regards,
Andrii
On Mon, Feb 8, 2021 at 8:03 AM Vladimir Dzhuvinov
wrote:
> Hi Andrii,
>
> The unencoded payload JWS from RFC 7797 appears to be harder to get right.
>
The Cache-Control header, even with its strongest directive "no-store", is
pretty naive protection... Below is an excerpt from RFC 7234 (Hypertext
Transfer Protocol: Caching).
This directive is NOT a reliable or sufficient mechanism for ensuring
> privacy. In particular, malicious or compromised
On Wed, Mar 17, 2021 at 2:47 PM Mike Jones wrote:
>
> I’ve created the pull request
> https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/14/ applying the
> proposed changes below to the draft. Unless suggestions for changes are
> received, we’ll merge this and publish -31 to address
I’ve created the pull request
https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/14/ applying the proposed
changes below to the draft. Unless suggestions for changes are received, we’ll
merge this and publish -31 to address Watson’s comments.
All,
The following links have the DPoP meeting minutes and the list of next
interim meetings:
https://codimd.ietf.org/s/notes-ietf-interim-2021-oauth-01-oauth
https://datatracker.ietf.org/meeting/interim-2021-oauth-01/materials/minutes-interim-2021-oauth-01-202103151200-00
Thanks to Hannes and
This is an impersonation attack. As far as I know there isn't any good
solution for it. The good news is the preconditions for actually pulling
off the attack make it unlikely to be a problem in practice.
I would like to see a proper solution though, however that's going to
require some sort of
I don't think this attack fits into the mix-up attack class.
According to the security BCP (section 4.4) mix-up attacks are defined as:
The goal of the attack is to obtain an authorization code or an access
token for an uncompromised authorization server. This is achieved by
*tricking the
Would it be fair to characterize this attack vector as a mix-up attack
where the malicious app is essentially an Attacker AS?
In the Desktop OS category, responding with the *issuer* in the
authorization response (
https://tools.ietf.org/html/draft-ietf-oauth-iss-auth-resp-00) returned to
the
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.
Title : JSON Web Token (JWT) Profile for OAuth 2.0 Access
Tokens
Author : Vittorio Bertocci
Right, but PKCE doesn’t stop an attack when the malicious app initiates the
authorization flow.
> On 17 Mar 2021, at 08:04, SOMMER, DOMINIK
> wrote:
>
>
> I’d throw in PKCE as a means of assuring that the client who made the user
> follow the auth flow in the first place, is apparently
I’d throw in PKCE as a means of assuring that the client who made the user
follow the auth flow in the first place, is apparently the only one able to
“redeem” the auth code returned to the redirect_uri.
Von: OAuth Im Auftrag von Om
Gesendet: Mittwoch, 17. März 2021 06:17
An: Neil Madden
Cc:
No, it doesn’t mention this attack. The issue is that if the redirect_uri is
not strongly bound to a legitimate client then a malicious app on the user’s
device can initiate an OAuth flow and impersonate the legitimate client and
then intercept the response by claiming to handle the
12 matches
Mail list logo
