Hi Ethan,
I'm glad I managed to prompt some discussion on the topic!
Thank you very much for initiating this discussion! It will help to
establish a common understanding
of what is required/feasible for the upcoming standard.
RSA vs. HMAC: I really have no idea. On the other hand, Google is the
only existing provider I am aware of that supports the RSA method, and
Google quickly adopted HMAC as well. If the only use-case for the RSA
method is to establish similar security properties to those provided
by SSL/TLS with no performance or implementation advantage, then we
should get rid of it. I think we already had this discussion and I
have no personal interest in rehashing it.
I really like RSA because of its adavantages from an operational
security standpoint. A receiver does
not need to store any private data in order to authenticate the sender
of a message. Therefore I see RSA
as a promising option to authenticate consumers on the OAuth
authorization server (how to
get a token). One could even use hardware security moduls for
authentication!
I don't consider RSA a good option for signing requests from consumer to
resources because of its performance
characteristics. Symmetric algorithms like HMAC are by magnitudes
faster. I did some benachmarking in
a project in 2006. The measurements have been taken on a Windows PC
(Intel Pentium M 1,7 GHz/1GB)
with Java 1.5.
HMAC-MD5: 33000/s (sign and verify)
RSA/512: 434/s (sign), 3300/s (verify)
RSA/1024: 70/s (sign), 1250/s (verify)
As you can see, there is a factor of 10 (verify) to 300 (sign) between
RSA and HMAC-MD5. Today one would use
HMAC-SHA and probably RSA/2048 so I don't expect the proportions to be
better for RSA.
I think request signing can always be performed using a (symmetric)
token secret issued by the OAuth authorization server.
regards,
Torsten.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
