Hi, Hannes, Hannes Tschofenig <[email protected]> 写于 2012-09-10 17:39:28:
> 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. Sorry for my mistakes. What I concern is if two unilateral authentication or a mutual authentication between Client and RS is required. Of course mutual authentication is better for security, but is it a must here ? > > 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. I know the procedure. What I was questioning is since Ks is temporal and only used once, why not just send Ks to RS. I can see from other mails that access token are intended for multiple usages, then that can make sense. > > > > > 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. I checked the hotk draft again, I didn't find any method ensuring binding between access toekn and pk, it just said including the encoding of pk into access token,that can not be looked as a binding, unless you attach a mac(access token,k) to the access token, but that will require a long lived key shared between AS ans RS, asymmetric key shows no benifit here. > > > > 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. No, it is not a key distribution protocol. It is like a commitment 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
