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/

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 <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> 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 <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)
    <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)
    <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 <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 <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
    www.independentid.com
    phil.h...@oracle.com





    On Jan 25, 2016, at 4:52 PM, nov matake <mat...@gmail.com>
    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
    <phil.h...@oracle.com> wrote:

    Sorry, meant to reply-all.

    Phil

    @independentid
    www.independentid.com
    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
    www.independentid.com
    phil.h...@oracle.com





    On Jan 25, 2016, at 2:58 PM, Nat Sakimura
    <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/,
    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)
    <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
        <gffle...@aol.com> wrote:
        >
        > would

        _______________________________________________
        OAuth mailing list
        OAuth@ietf.org
        https://www.ietf.org/mailman/listinfo/oauth



    _______________________________________________
    OAuth mailing list
    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

    _______________________________________________
    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

--
Chief Architect
Identity Services Engineering     Work: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


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--
Chief Architect
Identity Services Engineering     Work: 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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to