Re: [OAUTH-WG] Mix-Up and CnP/ Code injection

[Brian Campbell <[e-mail]>]

Sorry to chime in late but I wanted to say that I strongly agree with
Torsten's characterization of things.

On Sat, Apr 30, 2016 at 11:57 AM, Torsten Lodderstedt <
[e-mail]> 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 <[e-mail]>
> 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
>> 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)
>> - 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>