Hi Zhou, On 09/11/2012 04:11 AM, [email protected] wrote: > > 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 ?
The answer depends on what you assume as the baseline working assumption. See Section 4.1, 4.2., and 4.3 of http://tools.ietf.org/html/draft-tschofenig-oauth-security-00 When going for the approach outlined in Section 4.3 then the client authentication is really "only" key confirmation. (Note also that the currently specified client authentication is really only application authentication rather than client instance authentication. I don't know whether this makes sense, as I tried to explain it. > > > > 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. This is certainly a design decision we need to make, namely how often the Access Token shall be re-usable (with the same key). This is a very important design decision. Luckily, OAuth 2.0 has a mechanism to request new Access Tokens - a feature OAuth 1.0 didn't provide. > > > > > > > > > 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. At the beginning of Section 4 I write: " A large range of threats can be mitigated by protecting the content of the token, using a digital signature or a keyed message digest. Alternatively, the content of the token could be passed by reference rather than by value (requiring a separate message exchange to resolve the reference to the token content). To simplify the subsequent description we assume that the token itself is digitally signed by the Authorization Server and therefore cannot be modified. " I did not suggest any specific way to protect the token (neither symmetric nor asymmetric keys) but there is a lot of existing deployment for both. SAML uses asymmetric keys to protect the SAML assertions (if they are protected), and Kerberos Tickets are protected using symmetric keys. In our standardization efforts we are getting there to create a JSON based structure that can use both mechanisms. > > > > > > > > > > 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. Have a look at the Handbook of Applied Cryptography (available for free at http://cacr.uwaterloo.ca/hac/) and let us see whether we can agree on the right terminology here. Ciao Hannes > > > > > 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
