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 have many 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. I agree 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
