Hi Ethan,
<snip>
The most important and unavoidable tradeoff is performance. The
IMHO the comparison is asymmetric. You compare SSL, which offers
various security
measures, with just signatures on plain HTTP requests. Sure, validating a
(HMAC) signature is cheap, but signatures only give you sender
authentication and
(depending on what has been included in the digest computation)
message integrity protection. But any attacker might replay the
messages, so what
about replay prevention?
Replay prevention over unsecure connections is typically (as in OAuth
1.0 and OpenId)
implemented using nounces and timestamps. Validating nounces requires
server-side,
cluster-wide state (transient or database). All requests must be validated
against this state in serialized order. So you end up with
a) scalability issues and
b) performance impacts.
SSL scales both linearly and horicontally.
Not to forget, a HTTP request may be cached by any proxy on the way
from end user
device to target service. Care has to be taken in order to prevent
proxies from
caching sensible requests.
performance tradeoff comes in two flavors:
1. Connection latency to bootstrap the connection (from the
asymmetric/public-key encryption operations)
Bootstrapping a SSL sessions is expensive. But every session can be
used for multiple HTTPS-Connections. Thus an application can establish
the first
HTTPS connection in the background before any user interaction takes place and
reuse the session for further communication.
2. Processing to encrypt requests (from the symmetric/private-key
encryption operations)
TLS is powerful and expensive. That's true. I sometimes wish to have something
more lightweight and flexible where I could decide on a per-message
base which security
features to use. But this is hugh story.
From my point of view, the working group should decide what OAuth 2.0
should be:
1) a standard for token-based authentication and authorization or
2) a standard for HTTP security including token-based authentication
and authorization
In the first case, token holder authentication (Holder of Key in SAML
and WS-Trust) based on signing
a nounce should suffice.
In the later case, the standard should provide a (large) subset of SSL
protection features,
e.g. message integrity, message confidentiality, server
authentication, replay prevention.
regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
