Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-revocation-09: (with DISCUSS and COMMENT)

[Richard Barnes <[e-mail]>]

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