;> My reasoning is that we have a closed system that is fairly simple, so
>>>>>>> formal analysis must be entirely possible.
>>>>>>>
>>>>>>> 1. We have 5 parties (client, AS, RS, user, user agent).
>>>>>>>
>&g
t;>>>>> into OAuth must therefore be finite.
>>>>>>
>>>>>> 4. The security requirement is essentially to guarantee the precedence
>>>>>> and authenticity of the messages from discovery endpoint to RS, and the
>>>>>> pr
ges, which can be forward or backward binding.
>>>>>
>>>>>
>>>>> Right now the WG concern is whether all possible attacks have been
>>>>> recognised, and then taken care of. If we can have a formal model that
>>>>> can reliably r
Hi all,
I prefer to use draft-jones-oauth-mix-up-mitigation-01 as starting point
simply because it gives some description of the threats we need to cope
with. This does not preclude to eventually use
draft-sakimura-oauth-meta-07 as solution or any other suitable
mechanisms we find consensus o
;>
>>>> Vladimir
>>>>
>>>>
>>>>
>>>> On 20/02/16 12:41, Mike Jones wrote:
>>>>> Suggesting that they be read is of course, the right long-term
>>> approach. But as someone who spent 20+ years as a researc
iption of the
>>> threats and mitigations in the working group document.
>>>
>>> Cheers,
>>> -- Mike
>>>
>>> -Original Message-
>>> From: Hannes Tschofenig [mailto:hannes.
ht long-term
>> approach. But as someone who spent 20+ years as a researcher before
>> switching to digital identity, I was sensitive to not wanting to upstage
>> their work by copying too much of their material into our draft before
>> their publications were widely known. I
bcampb...@pingidentity.com]
Sent: Friday, February 26, 2016 5:28 PM
To: Hannes Tschofenig
Cc: oauth
Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for
Adoption
My preference is for Option A.
The mix-up attack, in all it's variations, relies on there being no means in
OAuth fo
rchers and the working group to create a self-contained concise
> description of the threats and mitigations in the working group document.
> >>
> >> Cheers,
> >> -- Mike
> >>
> >> -Origina
-- Mike
>>
>> -Original Message-
>> From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net]
>> Sent: Saturday, February 20, 2016 2:25 AM
>> To: Mike Jones ; William Denniss
>> ; Phil Hunt (IDM)
>> Cc: oauth@ietf.org
>> Subject: Re: [
I think that AT reuse by MITM attacks should be dealt with as a separate issue.
There are several possibilities.
1) POP tokens (You will recall the Eran wanted them for this reason)
2) The AS telling the client where the token can be used and the client
comparing the URI (may be multiple)
3) The
We still have a problem with AT leaking. I think that needs to be dealt with
separately.
Access tokens should have a audience (by value or by introspection) the client
needs to tell the AS what resource it want s to use the token at and have that
included as the audience or the request reject
Comments inline.
On 24/02/16 12:27, Nat Sakimura wrote:
> 2016年2月24日(水) 8:17 John Bradley :
> [..snip..]
>
>> This is not stoping the attack it is protecting code.
>>
> IMHO, this is the right approach. We should solve the problem
> architecturally rather than bandaging the hols.
>
>
>> I should p
2016年2月24日(水) 8:17 John Bradley :
[..snip..]
>
> This is not stoping the attack it is protecting code.
>
IMHO, this is the right approach. We should solve the problem
architecturally rather than bandaging the hols.
>
> I should point out that some of the attacks like man in the middling
> regis
g the Authorization Server Mix-Up: Call for
Adoption
The idea of including the state in the PKCE calculation was one I think Hans
brought up at the meeting in Darmstadt.
I think we discounted it as not solving the problem because the attacker could
manipulate the code_challenge.
As and exampl
The idea of including the state in the PKCE calculation was one I think Hans
brought up at the meeting in Darmstadt.
I think we discounted it as not solving the problem because the attacker could
manipulate the code_challenge.
As and example the attacker receives the request and changes the cod
Authorization Server Mix-Up: Call for Adoption
Early February I posted a mail to the list to make progress on the solution to
the OAuth Authorization Server Mix-Up problem discovered late last year.
Here is my mail about the Authorization Server Mix-Up:
https://na01
In line !
> 22 feb 2016 kl. 05:08 skrev John Bradley :
>
>> On Feb 22, 2016, at 9:22 AM, Nat Sakimura wrote:
>>
>> The risk impact of [case2] is more OAuth specific. The token is stolen as
>> the token is going to be sent to a rogue resource, and the resource can use
>> that to obtain the res
think I will make RSA to go over this in person.
>
If PKCE with a new mode manages to fix everything, that would be great!
I'm just reframing the essence of the proposed solution, as I roughly
understood it:
1. The mix-up attack causes the client to be set up with compromised
endpoints.
On 23/02/16 07:56, William Denniss wrote:
> I also wonder if the spec could be re-titled and focus on use-case that it
> solves (supporting multiple ASes without using Connect), rather than the
> attack it mitigates. I like that the metadata draft is targeted to solve a
> particular use-case, whi
This sounds fantastic, Daniel. I was only aware of the work by the
researchers from RUB.de about the CSRF attack on OIDC discovery. I'm
reading the paper right now and want to take some time off to study it
in more detail.
Congratulations for doing this,
Vladimir
On 23/02/16 12:28, Daniel Fett w
Hi Valdimir,
this is exactly what we did in our research paper. We also analyzed and
established a proof of security for one of the proposed mitigations.
Of course, any proof always depends on some assumptions (e.g., no
untrusted third-party code on RP's web site) and aims at specific
security pr
; Phil Hunt (IDM)
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for
> Adoption
>
> Hi Mike,
>
> On 02/20/2016 10:52 AM, Mike Jones wrote:
>> Have you read both of their publications? If not, do yourself a favor
>>
hi,
FWIW I also find Option A easier to understand/implement.
regards
antonio
On Feb 19, 2016, at 8:42 PM, Hannes Tschofenig
wrote:
> Early February I posted a mail to the list to make progress on the
> solution to the OAuth Authorization Server Mix-Up problem discovered
> late last year.
>
however a new method along the lines I sketched out may
let it work, or I could be completely wrong.
Too bad I don’t think I will make RSA to go over this in person.
John B.
>
> Nat
>
>
>
>
>
>
> --
> PLEASE READ :This e-mail is confidential and inte
: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for
Adoption
Inline
On Feb 20, 2016, at 9:49 AM, William Denniss mailto:wdenn...@google.com> > wrote:
Maybe it's because I wasn't at the Darmstadt meeting so I don't have the full
context, but I don&#
Information about the OAuth security meeting can be found at
> >> https://docs.google.com/document/d/136Cz2iwUFMdoKWZPCqZRhkmfmHAlJ6kM5OyeXzGptU4/edit
> >>
> >> <https://docs.google.com/document/d/136Cz2iwUFMdoKWZPCqZRhkmfmHAlJ6kM5OyeXzGptU4/edit>
> >>
ginal Message-
From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net]
Sent: Saturday, February 20, 2016 2:25 AM
To: Mike Jones ; William Denniss
; Phil Hunt (IDM)
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for
Adoption
Hi Mike,
On 02/20/2016
Hi Mike,
On 02/20/2016 10:52 AM, Mike Jones wrote:
> Have you read both of their publications? If not, do yourself a
> favor and do. They're actually both very readable and quite
> informative.
I have read both documents. In context of this discussion the question
is whether we
(a) require the
OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for
Adoption
Just a quick reply to two of your remarks:
On 02/20/2016 09:49 AM, William Denniss wrote:
> The security researcher documents are only informative references
I think they should be informative references since the motivate the reason
Just a quick reply to two of your remarks:
On 02/20/2016 09:49 AM, William Denniss wrote:
> The security researcher documents are only informative references
I think they should be informative references since the motivate the
reason for doing the work but there is nothing in these publications
t
nt/d/136Cz2iwUFMdoKWZPCqZRhkmfmHAlJ6kM5OyeXzGptU4/edit
>> and
>> https://docs.google.com/document/d/1cRa11EgimnTeJZR1-PUpNRpi_u_EoSpO5NtakVbA_sk/edit
>> .
>>
>> -Original Message-
>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschof
/d/1cRa11EgimnTeJZR1-PUpNRpi_u_EoSpO5NtakVbA_sk/edit
.
-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Friday, February 19, 2016 11:43 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for
Adoption
Early February I
annes Tschofenig
Sent: Friday, February 19, 2016 11:43 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption
Early February I posted a mail to the list to make progress on the solution to
the OAuth Authorization Server Mix-Up problem discovered late
Early February I posted a mail to the list to make progress on the
solution to the OAuth Authorization Server Mix-Up problem discovered
late last year.
Here is my mail about the Authorization Server Mix-Up:
http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html
Here is my mail to the li
35 matches
Mail list logo
