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

From: Richard Barnes <[email-masked]>
Date: Fri, 12 Jul 2013 14:43:44 -0400

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 13 Jul 2013 15:30:41 +0200

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:
>         ----------------------------------------------------------------------
>
> 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.
>
> 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.
>
> 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.
>
> NEW: "This URL MUST conform to the rules given in [RFC6749], section 
> 3.1.  Clients MUST verify that the URL is an HTTPS URL."
>
> 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.
> """
>
>
>
>
>

---

From: Richard Barnes <[email-masked]>
Date: Sat, 13 Jul 2013 15:30:50 -0400

Great, thanks!  I have cleared.
--Richard

On Sat, Jul 13, 2013 at 9:30 AM, Torsten Lodderstedt <
[email-masked]> wrote:

>  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.
>
> the token on the wire, so clearly it *should* be revoked.  But if the OAuth
> authorization server MUST require the use of a transport-layer security
> mechanism when sending requests to the token revocation endpoints.
>  """
> NEW:
> """