While I agree it may not be "proper" OAuth the fact is that the attack
is still possible and that means that some acknowledgement (security or
spec considerations) is required. Being able to MITM the UA or get the
user to click a link that takes them to a malicious "client" that is
really a MITM agent is easily doable.
While it's possible to confuse a client that just uses a single AS, that
attack is more of a "endpoint phishing" style attack than a protocol
attack. So far, baring no additional use cases, I'm still OK with
declaring the existing spec viable for clients that pre-configure a
single AS. Though I do think a "security consideration" should be
written discussing this "endpoint phishing" attack that Nat describes.
That said, to really protect these flows, I've come to the conclusion
that discovery and cryptographic binding are required for clients.
Thanks,
George
On 1/25/16 11:14 PM, Phil Hunt (IDM) 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 <[email protected]
<mailto:[email protected]>> 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) <[email protected]
<mailto:[email protected]>> 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) <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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
www.independentid.com <http://www.independentid.com/>
[email protected] <mailto:[email protected]>
On Jan 25, 2016, at 4:52 PM, nov matake <[email protected]
<mailto:[email protected]>> wrote:
The first assumption is coming from the original security report
at 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/
nov
On Jan 26, 2016, at 08:22, Phil Hunt <[email protected]
<mailto:[email protected]>> wrote:
Sorry, meant to reply-all.
Phil
@independentid
www.independentid.com <http://www.independentid.com/>
[email protected] <mailto:[email protected]>
Begin forwarded message:
*From: *Phil Hunt <[email protected]
<mailto:[email protected]>>
*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 <[email protected]
<mailto:[email protected]>>
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
www.independentid.com <http://www.independentid.com/>
[email protected] <mailto:[email protected]>
On Jan 25, 2016, at 2:58 PM, Nat Sakimura <[email protected]
<mailto:[email protected]>> 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/,
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) <[email protected]
<mailto:[email protected]>>:
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
<[email protected] <mailto:[email protected]>> wrote:
>
> would
_______________________________________________
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
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
--
Chief Architect
Identity Services Engineering Work: [email protected]
AOL Inc. AIM: gffletch
Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544 Photos: http://georgefletcher.photography
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
