I support documenting the use of the issuer to mitigate mix-up attacks. Note
that while issuer was first defined by OpenID Connect, it became art of OAuth
2.0 in RFC 8414 - OAuth 2.0 Authorization Server Metadata.
-- Mike
From: OAuth <[email protected]> On Behalf Of Brian Campbell
Sent: Thursday, June 18, 2020 1:32 PM
To: Daniel Fett <[email protected]>
Cc: oauth <[email protected]>
Subject: [EXTERNAL] Re: [OAUTH-WG] Mix-Up Revisited
In my (probably simplistic) understanding of things, the root underlying issue
that allows for mix-up in its variations is the lack of anything identifying
the AS in the authorization response. Following from that, introducing and
using an `iss` authorization response parameter has always seemed like the most
straightforward approach for mitigating the issue (which was part of the
draft-ietf-oauth-mix-up-mitigation but other parameters were also included and,
for reasons I'm not sure about, interest in that work faded in favor of telling
clients to use per AS redirect URIs) . Though for the `iss` authorization
response parameter to be effective, all parties involved need to know about it
and act on it. So I think it'd need to be something more than a passing
recommendation in the BCP. It should be defined, registered, explained, etc..
Actually introducing a new parameter is maybe going beyond the expected scope
of the BCP (or 2.1). But maybe that's ok, if we're at least more intentional
about it.
On Sun, Jun 7, 2020 at 7:53 AM Daniel Fett
<[email protected]<mailto:[email protected]>> wrote:
Hi all,
I was wondering if we should move towards introducing and (more explicitly)
recommending the iss parameter in the security BCP, for the reasons laid out
below and in the article (which is now at
https://danielfett.de/2020/05/04/mix-up-revisited/).
Any thoughts on this?
-Daniel
Am 04.05.20 um 19:34 schrieb Daniel Fett:
Hi all,
to make substantiated recommendations for FAPI 2.0, the security considerations
for PAR, and the security BCP, I did another analysis on the threats that arise
from mix-up attacks. I was interested in particular in two questions:
* Does PAR help preventing mix-up attacks?
* Do we need JARM to prevent mix-up attacks?
I wrote down several attack variants and configurations in the following
document: https://danielfett.github.io/notes/oauth/Mix-Up%20Revisited.html
The key takeaways are:
1. The security BCP needs to make clear that per-AS redirect URIs are only
sufficient if OAuth Metadata is not used to resolve multiple issuers.
Otherwise, per-Issuer redirect URIs or the iss parameter MUST be used.
2. PAR-enabled authorization servers can protect the integrity better and
protect against Mix-Up Attacks better if they ONLY accept PAR requests.
3. We should emphasize the importance of the iss parameter (or issuer) in
the authorization response. Maybe introduce this parameter in the security BCP
or another document?
4. Sender-constrained access tokens help against mix-up attacks when the
access token is targeted.
5. Sender-constraining the authorization code (PAR + PAR-DPoP?) might be
worth looking into.
I would like to hear your thoughts!
-Daniel
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
material for the sole use of the intended recipient(s). Any review, use,
distribution or disclosure by others is strictly prohibited.. If you have
received this communication in error, please notify the sender immediately by
e-mail and delete the message and any file attachments from your computer.
Thank you.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
