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 should be a secret, so other (malicious) clients could not
reuse it.
Distribution of that "unique secrets" should be automated in the mobile 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 distributed to a mobile device they are not 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
solution 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 think it would be better and
more beneficial for the community to return to this protocol rather than
inventing a new method of "mutual authentication".
>
>From: Phil Hunt <phil.h...@oracle.com>
>To: Prateek Mishra <prateek.mis...@oracle.com>
>Cc: OAuth WG <oauth@ietf.org>
>Sent: Mon, April 4, 2011 9:52:17 AM
>Subject: Re: [OAUTH-WG] Authorization code security issue (reframed)
>
>
>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. Hopefully this
>message sticks to the issue of developing an appropriate counter measure to
>threats as that is my only intent.
>
>
>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
><Response> message has
>>been issued is given the message as the result of an <ArtifactResolve>
request.
>Yet, in OAuth the client app is not unique for a particular set of client
>credentials we currently have no way to verify that the correct client got the
>code. This has been the mechanism that the community has been assuming solves
>the problem. Client credentials do not always work to protect the
>authorization
>code because in OAuth you can havemany many clients with the same credential.
>For example everyone with the same mobile app likely has the same client
>credential. Thus a copy of a valid client app which is easy to obtain becomes
>the hacker's attack vector. So, the client credential is not an effective
>counter in this case.
>
>
>Several have commented that there are other supplementary techniques for
>protection, but in my view, most of them work indirectly and/or depend on
>correct collective configuration of several components. Some of these are:
>tokens may be used one time; tokens are invalidated if used a second time,
>tokens are sufficiently unique, etc. All of these will help. But none are
>designed to directly counter the attack. In fact the best one - token
>invalidation carries the additional problem of unreliable service for the
>legitimate client. The hacker can deny service to anyone in the room simply by
>re-using any tokens seen.
>
>
>From my perspective, the "easy" solution was to increase the requirements on
>TLS
>from SHOULD to MUST to prevent eavesdropping of the code. This was echoed by
>several others. Iagree this will not work for everyone. Many have made strong
>arguments for why they can't use it. But without a MUST we are still missing a
>direct counter to the threat.
>
>
>I don't want to change things at this late date, but maybe this means
>introducing some form of mutual authentication -- some way for the requesting
>client "instance" to prove that they are the copy eligible to use an
>authorization code.
>
>
>To end this discussion, I propose we vote on the proposal from Eran plus one
>new
>option...
>1. Include a normative MUST use TLS for the client redirection URI endpoint.
>2. Include a normative SHOULD use TLS for the client redirection URI endpoint
>with strong language explaining the various attacks possible if the endpoint
>is
>not made secure.
>3. Keep current language of SHOULD, but develop a direct counter-measure to
>token theft such as specific client instance identification or mutual
>authentication.
>
>
>Phil
>phil.h...@oracle.com
>
>
>
>
>On 2011-04-04, at 8:57 AM, Prateek Mishra wrote:
>
>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 (lines
>>595-596, profiles document) - that specifically deal with the
>>artifact being leaked -
>>
>>[quote]
>>The identity provider MUST ensure that only the service provider to whom the
>><Response> message has
>>been issued is given the message as the result of an <ArtifactResolve>
request.
>>[\quote]
>>
>>- prateek
>>
>>Hi Prateek,
>>>
>>>> I would like to strongly disagree with this proposal.
>>>>
>>>> It amounts to explicitly making OAuth 2.0 insecure so as to
>>>> satisfy some mysterious and unspecified set of legacy OAuth
>>>> 1.0 deployments.
>>>>
>>>> The SAML web SSO (artifact) profile - which shares many
>>>> characteristics with the initial steps in OAuth - requires
>>>> precisely such a counter-measure and is widely implemented
>>>> in 1000s of deployments.
>>>
>>>What counter-measure is this? Can you provide a reference?
>>>Section 4.1.3.5 of
>>>http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
>>>recommends TLS but does not require it.
>>>
>>>Francisco
>>>
>>>
>>>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
