Hannes Tschofenig <[email protected]> 写于 2012-09-17 20:27:32:
> 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. May I understand your explaination as not all requirements are to be implemented in an OAuth protocol, whether one requirement is applicable depends on specific protocol? > > > > > > 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. I see. > > > > > > > > > > > > > > > > > 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. As I understand, key distribution protocol is used to establish key to entities by transportation of agreement. Here I did't mean to distribute any key. If you view R as a key, in a key distribution protocol, R should be encrypted or by a confidential channel. Here R don't have to be encrypted. The idea is commitment to something then disclose it, which is common in contract signing. Yes, you are right, this method has limited period, I propose it on the base that access token is only used once. What I am trying to say is that may be you don't have to limit key confirmation methods (section 4.3) to precondition that key distribution has to be defined to share keys between AS and RS, although I think sharing keys between AS and RS is acceptable. > > 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
