Hi Zhou,
On Sep 7, 2012, at 6:23 AM, [email protected] wrote: > > 1. Section 4 “A Resource Server must not be allowed to accept access > tokens that are not meant for its consumption.” > says Resource Server authentication to Client is a must. Here is what I wrote: " An Authorization Server wants to ensure that it only hands out tokens to Clients it has authenticated first and who are authorized. For this purpose, authentication of the Client to the Authorization Server will be a requirement to ensure adequate protection against a range of attacks. " > section 4.1 “For that purpose the Client will have to authenticate the > Resource Server before transmitting the access token.” > says Client authentication to Resource Server is a must. No. The Client authenticates the Resource Server and not the other way around. > so the two unilateral authentications are must for one thing: client sends > an access token to a not intended resource server. > it seems to me either one is workable, especially the second one is enough. > The reson: > If RS is honest, to protect the resource access it must gurantee the > resource is accessed by proper entity. > If RS is unhonest, RS redirects the access token to another RS, and > another RS authenticates token provider, the RS fails. The two steps are needed for dealing with different attacks. > 2. In section 4.3 key confirmation > The example of symmetrical key, since Ks is only used once, client can > directly send token and Ks to RS, don't have to compute a MAC with Ks. The Ks is not sent to the RS by the Client but the Client instead uses the Ks as input to a cryptographic operation. > > The example of asymmetrical key is flawed. Without trust (e.g. > Certificate) implemented, Client can use any pk/sk generated by itself to > confirm > its knowledge of sk. It is perfectly fine but there are obviously lots of details missing. If you look at http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-01 then see the details. > > > 3. In section 4.4 summary > "The weak point with this approach..is.. increased complexity: a complete > key distribution protocol has to be defined." > Don't have to be always the case. > For example, client send H(R) in token request to AS, AS includes the H(R) in > the token, and client sends (token,R) to RS, > RS can verify the key confirmation by client without using preinstalled key > between AS and RS. What you describe is a key distribution protocol. Ciao Hannes > [email protected] 写于 2012-09-06 22:25:03: > > > Hi all, > > > > following the discussions at the last IETF meeting and the weeks > > before Phil and I had prepared a short writeup about the threats, > > and the security requirements. > > > > Here is the document: > > http://tools.ietf.org/html/draft-tschofenig-oauth-security-00 > > > > Please share your views with us. Is there something missing? Is > > further explanation needed? With what do you agree / disagree? > > > > Ciao > > Hannes & Phil > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
