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

[Torsten Lodderstedt <[e-mail]>]

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