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.
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.
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.
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 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.
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.
[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
