Another example I mentioned earlier is when the client does not expose the protected resources back to the bearer of the code. For example, a Twitter application sending you emails when someone stops following you. Since all it does is get the code and then uses it internally (no user login functionality), TLS adds NOTHING.
In practice, the MUST use TLS is not really about the redirection endpoint, but about ANY client endpoint used for user authentication (which is what the code is used in all these attacks). A MUST means we take a stand on the one such endpoint that is within our scope, but it doesn't, by itself, offers full protection of the protected resources granted if the client doesn't match that security level to the redirection endpoint. The only way to enforce that is with client certification by the authorization server vendor - something that is just completely impractical in the consumer web space. For example, Citibank can audit (well, pay someone to) Intuit tax products if they give them OAuth access, to make sure the entire tax product uses TLS without any exceptions (sometimes, a contract with a big liability sum will work too). I am not expressing a position here, just want to make sure people understand that regardless of using a MUST or SHOULD language in the document, the complete security picture of the client matters much more. EHL > -----Original Message----- > From: Dick Hardt [mailto:dick.ha...@gmail.com] > Sent: Saturday, April 02, 2011 8:55 AM > To: Francisco Corella; Eran Hammer-Lahav; Skylar Woodward; Phillip Hunt > Cc: OAuth WG > Subject: to TLS or not on redirect on consumer websites :: security > considerations > > > As has been pointed out in the discussions, if a website does not employe > TLS on connections on other connections, having TLS on the redirect does not > add security. > > Depending on the resource grant being given, the nature of the website, not > running TLS may be an acceptable security tradeoff. No being an IETF security > expert, I don't have an opinion on MUST or SHOULD language for TLS on the > redirect. > > This tradeoff should be well documented in the security considerations, and > this language I feel strongly should be in the core spec so that implementors > understand the risk. > > Examples where this is an acceptable tradeoff could be where access to the > resource is read-only, and the resource is publicly available information. In > this case, the resource is enabling the contextually useful information for > the > user. A specific example of this would be blog comments. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
