a perfectly valid - at first - AS may get compromised later and used to
attack other ASes; that attacj does not require code changes or control
over the authorization endpoint: a rogue employee that happens to have
access to log files (granted those include GET & POST data) on the AS
can mount the attack if only he can phish the user
we can't expect that Clients are able to judge whether an AS will become
compromised in the future; in fact that pushes the problems to the
really good AS who now needs to decide if it accepts Clients that are
able to make that judgement call about other ASes that it connects to
Hans.
On 1/27/16 8:48 PM, Justin Richer wrote:
I propose we rename this the “Random ASs Attack”.
— Justin (only half joking)
On Jan 27, 2016, at 8:07 AM, Nat Sakimura <sakim...@gmail.com
<mailto:sakim...@gmail.com>> wrote:
Yup.
For the RPs that would deal with valuable data, I also recommend it to
become HTTPS only. This will effectively close the hole for the AS
Mix-Up.
Also, I would recommend to the clients to think twice before accepting
random ASs.
To prevent the code phishing, it is a good idea to require the same
authority restriction. Otherwise, use some variant of discovery to get
the authoritative token endpoints.
2016年1月27日(水) 21:49 George Fletcher <gffle...@aol.com
<mailto:gffle...@aol.com>>:
Based on Hans' response to Nat I understand why this doesn't solve
all the use cases. It does still seem like a good idea from a
client perspective that would address the dynamic client
registration cases where the Bad AS is returning mixed endpoints.
On 1/27/16 7:43 AM, George Fletcher wrote:
Following up on Nat's last paragraph... did the group in
Darmstadt discuss this option? Namely, to require that the
authority section of the AuthZ and Token endpoints be the same?
Are there known implementations already deployed where the
authority sections are different? It seems like a simple check
that would address the endpoint mix-up cases.
Thanks,
George
On 1/26/16 8:58 PM, Nat Sakimura wrote:
John,
Nov is not talking about the redirection endpoint. I just
noticed that 3.1.2.1 of RFC 6749 is just asking TLS by "SHOULD"
and I think it needs to be changed to "MUST" but that is not
what he is talking about.
Instead, he is talking about before starting the RFC 6749 flow.
In many cases, a non TLS protected sites have "Login with HIdP"
button linked to a URI that initiates the RFC 6749 flow. This
portion is not within RFC 6749 and this endpoint has no name or
no requirement to be TLS protected. Right, it is very stupid,
but there are many sites like that.
As a result, the attacker can insert itself as a proxy, say by
providing a free wifi hotspot, and either re-write the button or
the request so that the RP receives "Login with AIdP" instead of
"Login with HIdP".
I have add a note explaining this to
<http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/>http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/
I also have added a bit of risk analysis on it and considered
other risk control measures as well.
It does not seem to be worthwhile to introduce a new
wire-protocol element to deal with this particular attack. (I
regard code cut-and-paste attack a separate attack.) I am
inclining to think that just to TLS protect the pre-RFC6749 flow
portion and add a check to disallow the ASs that has different
authority section for the Auhtz EP and Token EP would be adequate.
Nat
2016年1月27日(水) 2:18 John Bradley
<<mailto:ve7...@ve7jtb.com>ve7...@ve7jtb.com
<mailto:ve7...@ve7jtb.com>>:
Nov,
Are you referring to Sec 3.1.2.1 of RFC 6749.
Stating that the the redirection endpoint SHOULD require
TLS, and that the AS should warn the user if the redirect
URI is not over TLS (Something I have never seen done in the
real world)
Not using TLS is reasonable when the redirect URI is using a
custom scheme for native apps.
It might almost be reasonable for the token flow where the
JS page itself is not loaded over TLS so the callback to
extract the fragment would not be as well.
Note that the token itself is never passed over a non https
connection in tis case.
I would argue now that it is irresponsible to have a non TLS
protected site, but not everyone is going to go along with
that.
Using a http scheme URI for the redirect is allowed but is
really stupid. We did have a large debate about this when
profiling OAuth for Connect.
We did tighten connect to say that if you are using the code
flow then a http scheme redirect URI is only allowed if the
client is confidential.
John B.
On Jan 26, 2016, at 1:14 AM, Phil Hunt (IDM)
<phil.h...@oracle.com <mailto:phil.h...@oracle.com>> wrote:
Still don't see it. Though i think the diagram is wrong
(the rp should redirct to the ua and not call the authz
direct), the IDP should either return an error or redirect
the RP to TLS.
I don't see this as proper oauth protocol since the RP is
MITM the UA rather than acting as a client.
Phil
On Jan 25, 2016, at 19:57, nov matake
<<mailto:mat...@gmail.com>mat...@gmail.com
<mailto:mat...@gmail.com>> wrote:
In this flow, AuthZ endpoint is forced to be TLS-protected.
http://nat.sakimura.org/wp-content/uploads/2016/01/oauth-idp-mixup.png
However, RP’s redirect response which causes following
AuthZ request is still not TLS-protected, and modified on
the attacker’s proxy.
Section 3.2 of this report also describes the same flow.
http://arxiv.org/pdf/1601.01229v2.pdf
On Jan 26, 2016, at 12:37, Phil Hunt (IDM)
<<mailto:phil.h...@oracle.com>phil.h...@oracle.com
<mailto:phil.h...@oracle.com>> wrote:
Also the authz endpoint is required to force tls. So if
the client doesn't do it the authz should reject (eg by
upgrading to tls).
Phil
On Jan 25, 2016, at 19:29, Phil Hunt (IDM)
<<mailto:phil.h...@oracle.com>phil.h...@oracle.com
<mailto:phil.h...@oracle.com>> wrote:
When the RP acting as the client issues a authorize
redirect to the UA it has to make it with TLS
Phil
On Jan 25, 2016, at 17:53, Nov Matake
<<mailto:mat...@gmail.com>mat...@gmail.com
<mailto:mat...@gmail.com>> wrote:
It doen't say anything about the first request which
initiate the login flow.
It is still a reasonable assumption that RP puts a
"login with FB" button on a non TLS-protected page.
nov
On Jan 26, 2016, at 10:45, Phil Hunt
<<mailto:phil.h...@oracle.com>phil.h...@oracle.com
<mailto:phil.h...@oracle.com>> wrote:
I would find it hard to believe that is true.
From 6749 Sec 3.1
Since requests to the authorization endpoint result in user
authentication and the transmission of clear-text credentials (in
the
HTTP response), the authorization server MUST require the use of TLS
as described inSection 1.6
<https://tools.ietf.org/html/rfc6749#section-1.6> when sending
requests to the
authorization endpoint.
Sec 3.1.2.1
The redirection endpoint SHOULD require the use of TLS as described
inSection 1.6
<https://tools.ietf.org/html/rfc6749#section-1.6> when the requested response type is
"code" or "token",
or when the redirection request will result in the transmission of
sensitive credentials over an open network. This specification does
not mandate the use of TLS because at the time of this writing,
requiring clients to deploy TLS is a significant hurdle for many
client developers. If TLS is not available, the authorization
server
SHOULD warn the resource owner about the insecure endpoint prior to
redirection (e.g., display a message during the authorization
request).
Lack of transport-layer security can have a severe impact on the
security of the client and the protected resources it is authorized
to access. The use of transport-layer security is particularly
critical when the authorization process is used as a form of
delegated end-user authentication by the client (e.g., third-party
sign-in service).
Section 10.5 talks about transmission of authorization
codes in connection with redirects.
Also see 6819, Sec 4.4.1.1 regarding eavesdropping or
leaking of authz codes.
Phil
@independentid
<http://www.independentid.com/>www.independentid.com
<http://www.independentid.com/>
<mailto:phil.h...@oracle.com>phil.h...@oracle.com
<mailto:phil.h...@oracle.com>
On Jan 25, 2016, at 4:52 PM, nov matake
<<mailto:mat...@gmail.com>mat...@gmail.com
<mailto:mat...@gmail.com>> wrote:
The first assumption is coming from the original
security report at
<http://arxiv.org/abs/1601.01229>http://arxiv.org/abs/1601.01229.
RFC 6749 requires TLS between RS and AS, and also
between UA and AS, but not between UA and RS.
The blog post is based on my Japanese post, and it
describes multi-AS case.
Nat's another post describes the case which can
affect single-AS case too.
<http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/>http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/
nov
On Jan 26, 2016, at 08:22, Phil Hunt
<<mailto:phil.h...@oracle.com>phil.h...@oracle.com
<mailto:phil.h...@oracle.com>> wrote:
Sorry, meant to reply-all.
Phil
@independentid
<http://www.independentid.com/>www.independentid.com
<http://www.independentid.com/>
<mailto:phil.h...@oracle.com>phil.h...@oracle.com
<mailto:phil.h...@oracle.com>
Begin forwarded message:
*From: *Phil Hunt <phil.h...@oracle.com
<mailto:phil.h...@oracle.com>>
*Subject: **Re: [OAUTH-WG] Call for Adoption: OAuth
2.0 Mix-Up Mitigation*
*Date: *January 25, 2016 at 3:20:19 PM PST
*To: *Nat Sakimura <sakim...@gmail.com
<mailto:sakim...@gmail.com>>
I am having trouble with the very first assumption.
The user-agent sets up a non TLS protected
connection to the RP? That’s a fundamental
violation of 6749.
Also, the second statement says the RP (assuming it
acts as OAuth client) is talking to two IDPs.
That’s still a multi-AS case is it not?
Phil
@independentid
<http://www.independentid.com/>www.independentid.com
<http://www.independentid.com/>
<mailto:phil.h...@oracle.com>phil.h...@oracle.com
<mailto:phil.h...@oracle.com>
On Jan 25, 2016, at 2:58 PM, Nat Sakimura
<<mailto:sakim...@gmail.com>sakim...@gmail.com
<mailto:sakim...@gmail.com>> wrote:
Hi Phil,
Since I was not in Darmstadt, I really do not know
what was discussed there, but with the compromised
developer documentation described in
<http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/>http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/,
all RFC6749 clients with a naive implementer will
be affected. The client does not need to be
talking to multiple IdPs.
Nat
2016 年1月26日(火) 3:58 Phil Hunt (IDM)
<<mailto:phil.h...@oracle.com>phil.h...@oracle.com
<mailto:phil.h...@oracle.com>>:
I recall making this point in Germany. 99% of
existing use is fine. OIDC is probably the
largest community that *might* have an issue.
I recall proposing a new security document
that covers oauth security for dynamic
scenarios. "Dynamic" being broadly defined to
mean:
* clients who have configured at runtime or
install time (including clients that do discovery)
* clients that communicate with more than one
endpoint
* clients that are deployed in large volume
and may update frequently (more discussion of
"public" cases)
* clients that are script based (loaded into
browser on the fly)
* others?
Phil
> On Jan 25, 2016, at 10:39, George Fletcher
<<mailto:gffle...@aol.com>gffle...@aol.com
<mailto:gffle...@aol.com>> wrote:
>
> would
_______________________________________________
OAuth mailing list
<mailto:OAuth@ietf.org>OAuth@ietf.org
<mailto:OAuth@ietf.org>
<https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
<mailto:OAuth@ietf.org>OAuth@ietf.org
<mailto:OAuth@ietf.org>
<https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
<mailto:OAuth@ietf.org>OAuth@ietf.org
<mailto:OAuth@ietf.org>
<https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
Chief Architect
Identity Services Engineering Work:george.fletc...@teamaol.com
<mailto:george.fletc...@teamaol.com>
AOL Inc. AIM: gffletch
Mobile: +1-703-462-3494 Twitter:http://twitter.com/gffletch
Office: +1-703-265-2544 Photos:http://georgefletcher.photography
<http://georgefletcher.photography/>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
Chief Architect
Identity Services Engineering Work:george.fletc...@teamaol.com
<mailto:george.fletc...@teamaol.com>
AOL Inc. AIM: gffletch
Mobile: +1-703-462-3494 Twitter:http://twitter.com/gffletch
Office: +1-703-265-2544 Photos:http://georgefletcher.photography
<http://georgefletcher.photography/>
_______________________________________________
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
--
Hans Zandbelt | Sr. Technical Architect
hzandb...@pingidentity.com | Ping Identity
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
