Great, thanks! I have cleared. --Richard
On Sat, Jul 13, 2013 at 9:30 AM, Torsten Lodderstedt < tors...@lodderstedt.net> 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. > """ > > > > > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
