Hi Richard,
thanks for your proposals. I adopted the draft accordingly.
http://www.ietf.org/id/draft-ietf-oauth-revocation-11.txt
regards,
Torsten.
Am 12.07.2013 20:43, schrieb Richard Barnes:
Hi Torsten,
Sorry for the delay on this. I've cleared on D2. Focusing this
response on point D1:
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
D1. The mandate for TLS usage actually seems backward here.
Suppose a
server receives a request over HTTP. At this point, the
credentials have
been exposed, so you would *want* the token to be invalidated!
Suggest:
-- Clients MUST NOT send over HTTP
-- Server revocation URIs MUST be HTTPS
-- Servers MAY support HTTP to the corresponding URI, just in
case the
client screws up
I see your point. Doesn't the last bullet contradict the first bullet?
They don't contradict each other; the third just assumes that the
first might not be universally true. But I would probably be happy
with just the first two.
The scenario I'm worried about is the following:
1. An operator runs both HTTP and HTTPS servers under the name
"example.com <http://example.com>". The HTTPS server is used for
OAuth things, while the HTTP server for unsecured, public-facing
things. In particular, the revocation URIs the server hands out point
to the HTTPS server.
2. An attack or mishap manages to change the revocation URL from
"https:" to "http:"
3. When the client tries to revoke his token, he is able to
successfully open a TCP connection to the HTTP server. He then sends
his revocation request over the TCP connection.
What is the safe thing for the server do now? The client has exposed
the token on the wire, so clearly it *should* be revoked. But if the
OAuth revocation service is only active on the HTTPS server, then it
won't be.
In the spec, there are two things we can do, (1) try to prevent this
scenario from happening, and (2) have it fail safely when it does
happen. In the above three suggested points, the first does (1) and
the third does (2). The document currently says that the server MUST
require TLS (the second bullet above). But that doesn't prevent the
client from sending TLS, so it doesn't prevent the scenario.
Concrete suggestion to realize (1):
OLD: "This URL MUST conform to the rules given in [RFC6749], section 3.1."
NEW: "This URL MUST conform to the rules given in [RFC6749], section
3.1. Clients MUST verify that the URL is an HTTPS URL."
Concrete suggestion to realize (2):
OLD:
"""
Since requests to the token revocation endpoint result in the
transmission of plain text credentials in the HTTP request, the
authorization server MUST require the use of a transport-layer
security mechanism when sending requests to the token revocation
endpoints.
"""
NEW:
"""
Since requests to the token revocation endpoint result in the
transmission of plain text credentials in the HTTP request, URLs for
token revocation endpoints MUST be HTTPS URLs. If the host of the
token revocation endpoint can also be reached over HTTP, then the
server SHOULD also offer a revocation service at the corresponding
HTTP URI, but MUST NOT publish this URI as a token revocation
endpoint. This ensures that tokens accidentally sent over HTTP will
be revoked.
"""
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
