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

[Richard Barnes <[e-mail]>]

Great, thanks!  I have cleared.
--Richard


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

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