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
Hi Skylar,
Thank you for sharing this information with us. Some thougts:
The empty string makes your implementation syntactically compliant but does
obviously not comply with its semantics and the security
considerations/expectations associated with a secret. Moreover, what about
interoperabil
Wow. I can't believe we're having this debate. You're describing a failed
implementations, not the spec. I think you are also misunderstanding the
implementation of this client flow. Have you built a sample client with this
flow?
I'm going respond to these points, but if there's still confusi
Phil
Sent from my phone.
On 2011-04-04, at 18:39, Skylar Woodward wrote:
> On Apr 4, 2011, at 4:06 PM, Phil Hunt wrote:
>
>> For the moment, I'm only talking about mobile clients.
>>
>> Very quickly here is the attack...
>> 1) Paul starts dance at good Client & good AS, App requests autho
Speaking from current, on-going, firsthand experience building an OAuth 2.0
server and client.
Your questions about deploying TLS are the least significant when it comes to
deploying a TLS-based client. I know these are the standard argument people
make when defending a requirement to use TLS
On Apr 4, 2011, at 4:06 PM, Phil Hunt wrote:
> For the moment, I'm only talking about mobile clients.
>
> 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.
I'm going to
Dick,
> Maybe you should stop using Twitter as anyone that can MITM your
> session can tweet as you since Twitter does not enforce HTTPS on
> twitter.com
Thanks for pointing that out. I haven't looked at the security
posture of Twitter, I just mentioned Twitter because Eran did. The
point I was
Eran,
> The only consequence is compromising the *client*
> login/authentication security. I'm not trying to play it
> down, but I we need to be clear. This is not a compromise of
> the protected resources or authorization server.
We are definitely talking about a compromise of the
protected reso
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
Read 3.2. I believe you'll find an escape clause there.
Phil
phil.h...@oracle.com
On 2011-04-04, at 5:08 PM, Marius Scurtescu wrote:
> On Mon, Apr 4, 2011 at 4:14 PM, Skylar Woodward wrote:
>> In our implementation (not yet public) we accept the empty string ("") as
>> the value for clients
On Mon, Apr 4, 2011 at 4:14 PM, Skylar Woodward wrote:
> In our implementation (not yet public) we accept the empty string ("") as the
> value for clients not issued secrets. While this was done to simplify the
> interface and implementation, it would make it compliant in my view. In this
> ca
In our implementation (not yet public) we accept the empty string ("") as the
value for clients not issued secrets. While this was done to simplify the
interface and implementation, it would make it compliant in my view. In this
case, the authorization server is validating the credentials, whic
Torsten,
I agree that the described measures would protect the native application
clients.
But the current specification, as I understand it, does not allow the use of
the authorization code without client's authentication. It also requires client
authentication whenever the refresh tokens are
> -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 a
Just to clarify. Those attending the meeting did not decide. The chairs asked
Torsten and Anthony to take the text removed and resubmit it for working group
consideration. The text discussed is all non-normative, and is meant as a
helpful guide.
As editor, I don't have any objections and think
I think in practical terms, an oAuth domain is simply one where the access
token accepted. In practical terms this likely means they share the same token
service.
Regarding 2.2. The attention is not identity federation, just federation of the
token itself. The main thing is the target token ser
Am 04.04.2011 21:38, schrieb Zeltsan, Zachary (Zachary):
According to section "6 Refreshing an Access Token" (-13.txt), client when making a
request for exchanging a refresh token for an access token has to include its authentication
credentials, and the "authorization server MUST validate the
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
Does section 3.2 help you?
"In addition, the authorization server MAY allow unauthenticated access token
requests when the client identity does not matter (e.g. anonymous client) or
when the client identity is established via other means."
Phil
phil.h...@oracle.com
On 2011-04-04, at 1:09 PM,
Phil,
I read through the Chain Grant Type for OAuth 2 draft and appreciate the
problem you are addressing.
We encountered the same issue when using open social gadgets with OAuth when
data needs
to come from more than one server. It is not user friendly to prompt an end
user to log into multiple
On Mon, Apr 4, 2011 at 12:38 PM, Zeltsan, Zachary (Zachary)
wrote:
> According to section "6 Refreshing an Access Token" (-13.txt), client when
> making a request for exchanging a refresh token for an access token has to
> include its authentication credentials, and the "authorization server MUS
Agreed - we are planning to use the auth-code flow for native apps and
have no immediate plans to use implicit mode for native clients, either.
We'd be using the auth-code flow with a client id only and no client
secret, which I think is the pattern that everyone else is planning to
follow.
-- ju
For the moment, I'm only talking about mobile clients.
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.
2) Evil Brian intercepts the (HTTP) redirect containing Paul's authz c
I'm confused - it seems like you're mixing web clients and native clients in
this most recent explanation. It's perfectly reasonable that the authorization
code will always be returned by a provider in a secure TLS channel to the web
browser or native client which started the authorization requ
If you run a scanner, you will see that many of the current draft
implementations pass the authorization code by redirect without SSL. I've seen
several implementations where the authorization code is easy to scan.
I suspect this occurs because the HTTP response isn't directly in response to
th
According to section "6 Refreshing an Access Token" (-13.txt), client when
making a request for exchanging a refresh token for an access token has to
include its authentication credentials, and the "authorization server MUST
validate the client credentials".
How can this be done if a client is
Marius/Kris,
Are we talking about Native apps where no browser (internal or external) is
available (e.g. set-top-box)?
If a browser is available, I would not want to confuse the user with
authentication at the service provider with local branding of the app. OAuth
does a nice job of keeping th
But mobile clients aren't vulnerable to this type of attack because all of
their code is contained on the device and they make all outgoing requests to
the provider via SSL. There are no redirects to insecure remote endpoints. A
mobile device incapable of making outgoing SSL requests would not
On Mon, Apr 4, 2011 at 12:09 PM, Kris Selden wrote:
> I completely agree with you regarding not being able to authenticate a native
> client.
>
> The problem with web flow is the user experience is bad for a native app.
> Why does this matter? Because of competition – if competitors use a user
> I completely agree with you regarding not being able to authenticate a native
> client.
I suggest you read the security considerations draft to make sure this is
correct and points out the issues
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
I was referring to a mobile client that passes the request via an external
browser. That browser is capable of running SSL with server authentication only.
Phil
phil.h...@oracle.com
On 2011-04-04, at 12:08 PM, Skylar Woodward wrote:
> Maybe you can explain your example in more detail then? I
So the rewrite of the text was given to Torsten and myself as action items, but
welcome others to help out here
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
Jones
Sent: Monday, April 04, 2011 12:06 PM
To: Skylar Woodward; Marius Scurte
I completely agree with you regarding not being able to authenticate a native
client.
The problem with web flow is the user experience is bad for a native app. Why
does this matter? Because of competition – if competitors use a user friendly
but less secure method and the end user does not kn
Maybe you can explain your example in more detail then? I'm assuming your
"client app" is a web application hosted on web server supporting only HTTP.
How does the nonce or request_id get to the provider as part of the
authorization request in your example? (step 1)
On Apr 4, 2011, at 3:03 PM
One of the results at the OAuth meeting on Friday was that non-normative text
describing how to use OAuth with native applications will be restored to the
framework draft. We could start with the text from past drafts, but it can
likely be improved upon as well.
Marius, as someone who has exte
It doesn't require client side ssl.
Phil
Sent from my phone.
On 2011-04-04, at 11:47, Skylar Woodward wrote:
> How does the client app transmit the nonce (random number) to the web browser
> for redirect to the provider? If the client app does not support HTTPS, it
> can't set up a secure
I agree with Marius' points. We plan to support the auth-code flow for native
apps as well. There is no reason why native apps can't perform a successful
auth-code flow, they just do so without client credentials. However, the spec
doesn't make it clear that this is viable option.
skylar
On
How does the client app transmit the nonce (random number) to the web browser
for redirect to the provider? If the client app does not support HTTPS, it
can't set up a secure session on its own to give the browser/user something to
pass on during the provider authorization.
To me, this is nothi
On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden wrote:
> A typical iPhone app cannot be shipped with a client secret and rightly or
> wrongly users expect to only have to enter their credentials once.
>
> What is the best profile to use for an app that can't have a client secret
> and needs a refre
I have been wondering if we can combine a couple of things such as a client
generated transaction secret and use limited TLS to achieve a fix. Note: this
would address a hacker sniffing a returned authorization code, but it probably
does little for the MITM scenario that was also outlined.
1.
Having worked many years with native Internet consumer software applications,
and having worked in those teams in attempt to secure client secrets (be they
keys or obfuscated dynamic algorithms), I can say with reasonable confidence
that it is impossible to secure client credentials for publicly
See below...
Phil
phil.h...@oracle.com
On 2011-04-04, at 10:47 AM, Kris Selden wrote:
> A typical iPhone app cannot be shipped with a client secret and rightly or
> wrongly users expect to only have to enter their credentials once.
My understanding (and I'm not an iOS expert) is that each i
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.
In my view, two conditions are needed to achieve that:
1. Something unique stored on a mobile client.
2. That something
A typical iPhone app cannot be shipped with a client secret and rightly or
wrongly users expect to only have to enter their credentials once.
What is the best profile to use for an app that can't have a client secret and
needs a refresh token or a long lived access token?
Why doesn't implicit_g
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.
+1
Am 01.04.2011 03:00, schrieb Marius Scurtescu:
On Thu, Mar 31, 2011 at 4:56 PM, Phil Hunt wrote:
Done.
It isn't quite what the flow shows in the earlier diagram. I was originally
avoiding client type and trying to focus on section 4 options.
But this should be a better diagram.
http://i
Francisco,
You are right, I was in error to suggest that it was a MUST.
I think my main concern was that security considerations should not be
based on polling developers/deployers of an existing or legacy protocol.
SAML does include some additional countermeasures though - for example
(line
49 matches
Mail list logo
