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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
