We have native clients using the first 3 as well with good success
-cmort
On 4/4/11 2:00 PM, "Brian Eaton" wrote:
On Mon, Apr 4, 2011 at 1:06 PM, Phil Hunt wrote:
> Very quickly here is the attack...
> 1) Paul starts dance at good Client & good AS, App requests authorization.
> Note: outbou
DO NOT REPLY TO THIS EMAIL.
To Eran's point, before reaching the end of this thread after limited
access to email over the weekend, I was going to shut this thread down
anyways.
I'm not going to issue a call for consensus on this issue, because I
don't believe anyone on the list (except for a s
Blaine, Hannes,
This thread has gone as far as it can. We need to shut it down and move this
item to the chairs (and potentially the AD) to resolve, given that this is not
a technical issue, but a political/procedural one. I'm asking the chairs to
make a decision about this, given that the work
eturned authorization code, but it probably does little for the
>>>>>>>>>>> MITM scenario that was also outlined.
>>>>>>>>>>>
>>>>>>>>>>> 1. The client app generate a random number or sequence of
>>>&g
rver does its usual thing and returns,
>>>>>>>>>> preferably securely but not necessarily, the authorization code to
>>>>>>>>>> the client app.
>>>>>>>>>> 3. Upon requesting an access_token, the client app also includes the
>>&g
ey will suck.
It will be the safest web no one ever uses.
Awesome!
EHL
From: Francisco Corella [mailto:fcore...@pomcor.com]
Sent: Monday, April 04, 2011 5:35 PM
To: Eran Hammer-Lahav; Skylar Woodward; Phil Hunt; Oleg Gryb; David Recordon
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Authorization code securi
client request_id even though it might be able to obtain the
>>>>>>>>> authorization code being returned.
>>>>>>>>>
>>>>>>>>> What this might allow is that the client can transmit a secret
>>>>>>>>> prote
Eran,
> I don’t think your statement that ‘the IETF should endorse
> lack of security’ is accurate or helpful.
If the IETF endorsed a protocol such that a compliant
implementation allows user impersonation and unauthorized
access to protected resource, then the IETF would be
endorsing lack of sec
David,
> If this is changed to a MUST, Facebook will be in violation of the
> specification moving forward. It is untenable to require all of our
> *client* developers to implement TLS endpoints though we certainly
> support developers who wish to do so. This is very different than
> offerring our
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Brian Eaton
> Sent: Monday, April 04, 2011 2:00 PM
> To: Phil Hunt
> Cc: Oleg Gryb; OAuth WG
> Subject: Re: [OAUTH-WG] Authorization code security issue (reframed)
>
On Mon, Apr 4, 2011 at 1:06 PM, Phil Hunt wrote:
> Very quickly here is the attack...
> 1) Paul starts dance at good Client & good AS, App requests authorization.
> Note: outbound call is secure, but returned redirect is not.
For the record, we haven't had particular problems with installed app
>>> protected by TLS in its outbound request, but can accept non-secure
>>>>>>>> delivery of the authorization code. The token server then has a means
>>>>>>>> to verify that the client exchanging the authorization code is the
>
> Phil
>>>>>>> phil.h...@oracle.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2011-04-04, at 10:52 AM, Oleg Gryb wrote:
>>>>>>>
>>>
te:
>>>>>>
>>>>>>> After looking into exiting (and working) implementations of OAuth 1.0
>>>>>>> in mobile world I have strong doubts about possibility of implementing
>>>>>>> what was suggested in option #3.
>>>>>>
>>>>>> 1. Something unique stored on a mobile client.
>>>>>> 2. That something should be a secret, so other (malicious) clients could
>>>>>> not reuse it.
>>>>>>
>>>>>> Distribution of that "unique se
gt;>>> world and is usually included to mobile application
>>>>> activation process, but that activation process can't make conditions 1 &
>>>>> 2 above met in full, becuase:
>>>>>
>>>>> 1. As soon as secrets are distr
;> quite secret any more
>>>> 2. As soon as the secret becomes known, a simulator or other mobile device
>>>> can be used to spoof the traffic
>>>>
>>>> I would consider option #3 as an illusion until somebody comes up with a
>>>>
bile device
>>> can be used to spoof the traffic
>>>
>>> I would consider option #3 as an illusion until somebody comes up with a
>>> solution that would address the described issues.
>>>
>>> BTW, the draft of "OAuth Dynamic Client
olution that would address the described issues.
>>
>> BTW, the draft of "OAuth Dynamic Client Registration Protocol"
>> (http://tools.ietf.org/html/draft-oauth-dyn-reg-v1-00) has expired on Feb.
>> 12 and I didn't see any attempts to re-vitalise it. I thin
unity to return to this protocol rather than
> inventing a new method of "mutual authentication".
>
>
>
>
> From: Phil Hunt
> To: Prateek Mishra
> Cc: OAuth WG
> Sent: Mon, April 4, 2011 9:52:17 AM
> Subject: Re: [OAUTH-WG] Authorization code securi
re beneficial for the community to return to this protocol rather than
inventing a new method of "mutual authentication".
>
>From: Phil Hunt
>To: Prateek Mishra
>Cc: OAuth WG
>Sent: Mon, April 4, 2011 9:52:17 AM
>Subject: Re: [OAUTH-WG] Authorization code security i
On Mon, Apr 4, 2011 at 9:52 AM, Phil Hunt wrote:
> As Prateek clarified in the previous message to Francisco, SAML also uses
> SHOULD, but artifact security is achieved by an additional
> counter-measure...
>
> The identity provider MUST ensure that only the service provider to whom
> the messag
Apologies for the long message (again). I have attempted to sum things up and
bring out the issue without using any existing service or party as an example
of problems. It seems some have taken offence to my previous message pushing
for a solution. As a result it was not productive. I apologize.
On Apr 2, 2011, at 3:19 PM, Phillip Hunt wrote:
> If we take the current implementers as evidence it shows we have little or no
> security either due to misunderstandings or business decisions to accept risk
> for flexibility.
>
This type of language is also not helpful for moving us forward.
...@pomcor.com; Skylar Woodward; Oleg Gryb; OAuth WG; Karen P. Lewison
Subject: Re: [OAUTH-WG] Authorization code security issue (reframed)
For the record, I can except SHOULD. But my very strong feeling is this leads
to much more lengthy and complicated language.
I believe we have already crossed
>
>
> From: Francisco Corella [mailto:fcore...@pomcor.com]
> Sent: Saturday, April 02, 2011 10:49 AM
> To: Skylar Woodward; Phil Hunt; Eran Hammer-Lahav
> Cc: Oleg Gryb; OAuth WG; Karen P. Lewison
> Subject: Re: [OAUTH-WG] Authorization code security issue (reframed)
>
>
mplementers can talk about
their conformance.
EHL
From: Francisco Corella [mailto:fcore...@pomcor.com]
Sent: Saturday, April 02, 2011 10:49 AM
To: Skylar Woodward; Phil Hunt; Eran Hammer-Lahav
Cc: Oleg Gryb; OAuth WG; Karen P. Lewison
Subject: Re: [OAUTH-WG] Authorization code security issue (r
On Behalf
>> Of Skylar Woodward
>> Sent: Friday, April 01, 2011 9:52 PM
>> To: Phil Hunt
>> Cc: Oleg Gryb; OAuth WG
>> Subject: Re: [OAUTH-WG] Authorization code security issue (reframed)
>>
>> Am I the only one still supporting SHOULD on this case? If someon
Eran,
> Google, Facebook, and Yahoo! already indicated they will not enforce
> such a MUST. I could not get a clear answer from Twitter.
>
> However, no one representing this companies has bothered to express
> this view on the list, and to express how they would like the
> specification to handl
secure than ideal.
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Skylar Woodward
> Sent: Friday, April 01, 2011 9:52 PM
> To: Phil Hunt
> Cc: Oleg Gryb; OAuth WG
> Subject: Re: [OAUTH-WG] Authorization code sec
te should be taken into consideration by those who
>>> writes the final version.
>>>
>>> From: Francisco Corella
>>> To: Eran Hammer-Lahav ; Mark Mcgloin
>>>
>>> Cc: OAuth WG ; oauth-boun...@ietf.org
>>> Sent: Fri, April 1, 2011 9
vote should be taken into consideration by those who
>> writes the final version.
>>
>> From: Francisco Corella
>> To: Eran Hammer-Lahav ; Mark Mcgloin
>>
>> Cc: OAuth WG ; oauth-boun...@ietf.org
>> Sent: Fri, April 1, 2011 9:22:32 AM
>> Sub
> The results of the vote should be taken into consideration by those who
> writes the final version.
>
> From: Francisco Corella
> To: Eran Hammer-Lahav ; Mark Mcgloin
>
> Cc: OAuth WG ; oauth-boun...@ietf.org
> Sent: Fri, April 1, 2011 9:22:32 AM
> Subject: Re: [O
2 AM
>Subject: Re: [OAUTH-WG] Authorization code security issue (reframed)
>
>
>> So we have 2 different communities of Oauth developers that
>> will never agree.
>>
>> SHOULD: Typically the social networking sites that need to
>> cater for tail end developers by not
> So we have 2 different communities of Oauth developers that
> will never agree.
>
> SHOULD: Typically the social networking sites that need to
> cater for tail end developers by not enforcing TLS on
> redirect_uri. It is a risk to think that using strong
> language in the spec will help them app
I'm withdrawing my vote. When others decide what they want to do I'll apply it.
EHL
On Mar 31, 2011, at 17:10, "Eran Hammer-Lahav"
mailto:e...@hueniverse.com>> wrote:
(The previous thread is became completely inaccessible to anyone not following
it carefully for the past week or so. For the sa
t;
> To
>
> OAuth WG
>
> cc
>
> Subject
>
> [OAUTH-WG] Authorization code security issue (reframed)
>
> (The previous thread is became completely inaccessible to anyone not
> following it carefully for the past week or so. For the sake of
> reaching a conclu
ilto:phil.h...@oracle.com]
Sent: Thursday, March 31, 2011 5:43 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Authorization code security issue (reframed)
Sadly, see below.
Phil
phil.h...@oracle.com<mailto:phil.h...@oracle.com>
On 2011-03-31, at 5:09 PM, Eran Hammer-Laha
Thanks Eran. Well put.
As one of the original advocates of MUST, I'll offer a bit of background on
what we've done/seen in our 1.0a and 2d10 deployments
* we only block HTTP (and javascript:). Other schemes not using TLS are allowed
* we've seen 1.0 signatures being much harder for developers
Sadly, see below.
Phil
phil.h...@oracle.com
On 2011-03-31, at 5:09 PM, Eran Hammer-Lahav wrote:
> (The previous thread is became completely inaccessible to anyone not
> following it carefully for the past week or so. For the sake of reaching a
> conclusion, I am going to sum up the issue an
(The previous thread is became completely inaccessible to anyone not following
it carefully for the past week or so. For the sake of reaching a conclusion, I
am going to sum up the issue and try to start over with a more narrow focus.)
* The security issue is very simple:
The authorization code
41 matches
Mail list logo
