From my perspective we are not trying to solve a mix-up case or any
other attack. We are trying to solve for audience restricted tokens in
OAuth2 without PoP. In working to solve that case, we also want to close
any possible attacks but that is not the primary goal. I, personally,
don't want a bunch of one-off solutions to identified attacks if we can
design an cohesive solution that provides value and mitigates known attacks.
Thanks,
George
On 3/17/16 12:27 PM, Phil Hunt wrote:
I think in the mis-configuration case, it is different form the
redirect issues.
What we are concerned about is an attackers ability to convince the
client to set up a connection via an attackers proxy which can even
have a valid TLS enabled. The client won’t know it has done something
wrong. In fact it will confirm it has correctly connected to the
attackers proxy.
I don’t believe we have to have exact-match to work here. We need
preferable an exact host match.
I agree there can be a redirect issue pop up once we allow domain
matching. What we could ask the client to do is reconfirm discovery
when it receives a redirect from a resource. I’m not a fan of this
because it depends on the client doing something that seems optional
(even when it isn’t). BUT….this might be the out for SP’s like
George’s case where they don’t know the exact URL’s clients will be using.
Phil
@independentid
www.independentid.com <http://www.independentid.com>
phil.h...@oracle.com <mailto:phil.h...@oracle.com>
On Mar 17, 2016, at 8:48 AM, John Bradley <ve7...@ve7jtb.com
<mailto:ve7...@ve7jtb.com>> wrote:
The problem is similar to the one with redirect_uri, if you allow
user hosted content on the domain they will be able to get the token
if it is sent as a query parameter, and might be able to if it is
sent as a header.
Unfortunately many OAuth clients are badly behaved and make use of
the query parameter not considering the security issues.
Anything other than the AS or the client doing an exact URI match is
going to leave some hole.
This is why we are working on POP that is the correct way to solve
this for AS.
I think anything other than the client giving the AS the whole URI
and the AS including that as a audience/destination and letting the
RS figure out if it is correct is largely hopeless, as it will be to
fragile or the client won’t do it.
In the case of Phil’s proposal the discovery happens once at client
setup so the AS has no idea if the client checked before issuing the
token.
I honestly think there are two viable options:
1 PoP tokens
2 Including the destination URI / RS URI (pick name) in the token in
full and letting the RS decide if it has been man in the middled.
Everything else will be an endless game of wack-a-mole that increases
complexity but gets little real security.
John B.
On Mar 17, 2016, at 11:43 AM, George Fletcher <gffle...@aol.com
<mailto:gffle...@aol.com>> wrote:
If one of the APIs has an open-redirect problem, won't that cause
the token to leak to the attacker? That's why we went to exact match
in OpenID Connect. Does it not apply in this case?
Thanks,
George
On 3/17/16 2:42 AM, Nat Sakimura wrote:
IMHO, list of URIs that represent the partial paths under the same
authority would not be too onerous.
e.g., if you have
https://example.com/apis/v1/userinfo
https://example.com/apis/v2/userinfo
https://example.org/some/api/endpoint
etc., then the AS may provide
https://example.com/apis/
https://example.org/
or something like that in the audiences.
A completely new domain should not be trusted blindly.
The resource should at least make sure to provide the domain as
being under the same authority.
Bearer Token is a Password. It should not be shared among different
authorities.
Best,
Nat
*From:*OAuth [mailto:oauth-boun...@ietf.org]*On Behalf Of*George
Fletcher
*Sent:*Wednesday, March 16, 2016 3:15 AM
*To:*John Bradley<ve7...@ve7jtb.com>; Brian
Campbell<bcampb...@pingidentity.com>
*Cc:*<oauth@ietf.org><oauth@ietf.org>
*Subject:*Re: [OAUTH-WG] New Version Notification for
draft-hunt-oauth-bound-config-00.txt
(..snip..)
I'm not sure passing the full endpoint to the AS will help with my
concerns... The AS could potentially do a webfinger on the resource
URI and determine if it's an RS that it supports... though that
requires all RS's to support webfinger. What I really want to avoid
is the AS having this list of URIs to RS that is almost assuredly
to get out of sync.
(..snip..)
--
PLEASE READ :This e-mail is confidential and intended for the
named recipient only. If you are not an intended recipient,
please notify the sender and delete this e-mail.
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
