So what's your proposal for OAuth? -------- Originalnachricht -------- Betreff: Re: [OAUTH-WG] Mix-Up and CnP/ Code injection Von: John Bradley <[email protected]> An: Torsten Lodderstedt <[email protected]> Cc: Nat Sakimura <[email protected]>,[email protected]
>The attacks we are talking about (other than cut and paste) are not >compromising the integrity of the response. > >They rely on the response not containing enough information about the request >that is received by the AS for the client to detect tampering with the >request, or tricking the client into creating a new client_id based on bad >information that includes the token or RS endpoint of the attacker. > >As we discussed at IIW we need to do a better job creating a taxonomy for the >parts of the attacks. > >At the moment when we say mixup that may mean quite different things to people. > >Signing the response on it’s own is not much help. The reason the connect >id_token helps is not so much the signature, but rather that it contains the >issuer and client_id as proposed in the draft Mike and I worked on. > >If we wanted to sign something it would be better to sign the request to >prevent a authorization request sent to one AS from being modified and sent to >another AS. > >It is also worth noting that the per AS redirect URI are not effective on >there own agains all of the things in the bucket of mix up attacks. > >I personally prefer that OpenID Connect not add anything new to mitigate this, >however education on how to use the existing features for people who are >concerned, or at risk is a responsible thing to do. > >John B. >> On Apr 30, 2016, at 10:57 AM, Torsten Lodderstedt <[email protected]> >> wrote: >> >> Hi Nat, >> >> sure, one could also authenticate and cryptographically protect the redirect >> response. Leveraging OIDC concepts is an idea worth considering but they >> should be adopted to the OAuth philosophy. The id token as used in the >> hybrid flows mixes an identity assertion with elements of transport security >> measures. A OAuth AS does not provide identity data to clients, so we only >> need the transport security part. >> I personally would prefer a OAuth response object (similar to request object >> you have proposed) over the id token. Such a response object could contain >> (and directly protect) state, code and other response values. I consider >> this the more elegant design and it is easier to implement then having >> detached signatures over hash values of codes or access tokens. Moreover, it >> would allow to encrypt the response as well. >> Generally, our threat analysis so far does not have provided justification >> for cryptographically protected redirect responses. All proposals currently >> on the table stop mix up and code injection using simpler mechanisms. >> I think OAuth 2.0 is a huge success due to its balance of versatility, >> security and _simplicity_. We definitely need to keep it secure, but we >> should also keep it as simple as possible. >> kind regards, >> Torsten. >> Am 29.04.2016 um 10:08 schrieb Nat Sakimura: >>> As I look at it more and more, it started to look like the problem of >>> accepting tainted values without message authentication. To fix the root >>> cause, we would have to authenticate response. ID Token was designed to >>> also serve as a solution anticipating it. >>> >>> Any concrete ideas? >>> >>> On Sat, Apr 23, 2016 at 04:47 Torsten Lodderstedt <[email protected] >>> <mailto:[email protected]>> wrote: >>> Hi all, >>> >>> discussion about Mix-Up and CnP seems to have stopped after the session >>> in BA - at least in the OAuth WG. There is a discussion about >>> mitigations in OpenId Connect going on at the OpenId Connect mailing list. >>> >>> I'm very much interested to find a solution within the OAuth realm as >>> I'm not interested to either implement two solutions (for OpenId Connect >>> and OAuth) or adopt a OpenId-specific solution to OAuth (use id! tokens >>> in the front channel). I therefore would like to see progress and >>> propose to continue the discussion regarding mitigations for both threats. >>> >>> https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-00 >>> <https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-00> >>> proposes reasonable mitigations for both attacks. There are alternatives >>> as well: >>> - mix up: >>> -- AS specific redirect uris >>> -- Meta data/turi >>> (https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5 >>> <https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5>) >>> - CnP: >>> -- use of the nonce parameter (as a distinct mitigation beside state for >>> counter XSRF) >>> >>> Anyone having an opinion? >>> >>> best regards, >>> Torsten. >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
