Re: [OAUTH-WG] OAuth Bearer authentication - for proxies?
Well, this exchange made me read all I could find on reverse proxies. Now I understand--and agree with--the last statement of AYJ: 'the server is a proxy. ' But my understanding is that the proxy (which DNS pointed me to when I tried to get to my bank) belongs in the domain mybank, and this proxy had been issued a valid certificate--which I had ascertained in the process of authentication. So, the end result is that the proxy is part of the bank. If we expect it to be harmful to the bank--so we could the server itself as well as any bank's employee. It would be the bank replaying things to itself, right? Then it is the bank's problem, not OAuth's as far as I am concerned... Igor On 1/2/2012 7:36 PM, Amos Jeffries wrote: On 1/2/2012 7:07 AM, Amos Jeffries wrote: On 2/01/2012 11:00 p.m., Torsten Lodderstedt wrote: ... general note: I do not understand why caching proxies should impose a problem in case TLS is used (end2end). Could you please explain? Because TLS is hop-by-hop (in HTTP hops, end-to-end only in TCP hops). Proxies which decrypt TLS and provide responses out of cache are already deployed in many places. Mostly in the form of reverse-proxies, but corporate decryption proxies are also on the increase. AYJ On 3/01/2012 11:17 a.m., Igor Faynberg wrote: I am at a loss here; granted, it is a gray area... Does it mean that RFC 2817 has not been implemented properly? From RFC 2817: 5. Upgrade across Proxies As a hop-by-hop header, Upgrade is negotiated between each pair of HTTP counterparties. If a User Agent sends a request with an Upgrade header to a proxy, it is requesting a change to the protocol between itself and the proxy, not an end-to-end change. The more common case is CONNECT method from RFC 2068, from a user agent to a reverse-proxy. Same behaviour. To make it simple: At the client, I establish a session key with the server, and then use it for confidentiality. How is this key known to any proxy? the server is a proxy. AYJ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Bearer authentication - for proxies?
On Tue, 03 Jan 2012 18:34:01 -0500, Igor Faynberg wrote: Well, this exchange made me read all I could find on reverse proxies. Now I understand--and agree with--the last statement of AYJ: 'the server is a proxy. ' But my understanding is that the proxy (which DNS pointed me to when I tried to get to my bank) belongs in the domain mybank, and this proxy had been issued a valid certificate--which I had ascertained in the process of authentication. So, the end result is that the proxy is part of the bank. If we expect it to be harmful to the bank--so we could the server itself as well as any bank's employee. It would be the bank replaying things to itself, right? I'm not sure we quite match ideas on this. The problem is between the client and proxy. Not between the proxy and the server. Here is a transaction sequence for that bank: client 1 to proxy: GET /?oauth_token=FOO HTTP/1.1 Host: bank.example.com proxy to server: GET /?oauth_token=FOO HTTP/1.1 Host: bank.example.com (server verifies the token FOO is valid for client 1 through the proxy) bank server to proxy: HTTP/1.1 200 OK stuff proxy to client 1: HTTP/1.1 200 OK stuff .. some time passes. The token FOO expires, gets replaced by token FOO-2. client 1 to proxy: GET /?oauth_token=FOO-2 HTTP/1.1 Host: bank.example.com proxy to server: GET /?oauth_token=FOO-2 HTTP/1.1 Host: bank.example.com (server verifies the token FOO-2 is valid for client 1 through the proxy) bank server to proxy: HTTP/1.1 200 OK other-stuff proxy to client 1: HTTP/1.1 200 OK other-stuff Attacker processes some URL records they somehow swiped from the client transactions... attacker to proxy: GET /?oauth_token=FOO HTTP/1.1 Host: bank.example.com proxy to attacker: HTTP/1.1 200 OK stuff ... Oops. attacker to proxy: GET /?oauth_token=FOO-2 HTTP/1.1 Host: bank.example.com proxy to attacker: HTTP/1.1 200 OK other-stuff ... Oops. I assume for clarity that the server and client 1 have both correctly implemented Bearer and are performing proper validation and expiry on the query-string tokens. The mitigation is for the server which implements Bearer to be sending Cache-Control with one of the values: no-store, private, proxy-revalidate and/or must-revalidate. AYJ Then it is the bank's problem, not OAuth's as far as I am concerned... Igor On 1/2/2012 7:36 PM, Amos Jeffries wrote: On 1/2/2012 7:07 AM, Amos Jeffries wrote: On 2/01/2012 11:00 p.m., Torsten Lodderstedt wrote: ... general note: I do not understand why caching proxies should impose a problem in case TLS is used (end2end). Could you please explain? Because TLS is hop-by-hop (in HTTP hops, end-to-end only in TCP hops). Proxies which decrypt TLS and provide responses out of cache are already deployed in many places. Mostly in the form of reverse-proxies, but corporate decryption proxies are also on the increase. AYJ On 3/01/2012 11:17 a.m., Igor Faynberg wrote: I am at a loss here; granted, it is a gray area... Does it mean that RFC 2817 has not been implemented properly? From RFC 2817: 5. Upgrade across Proxies As a hop-by-hop header, Upgrade is negotiated between each pair of HTTP counterparties. If a User Agent sends a request with an Upgrade header to a proxy, it is requesting a change to the protocol between itself and the proxy, not an end-to-end change. The more common case is CONNECT method from RFC 2068, from a user agent to a reverse-proxy. Same behaviour. To make it simple: At the client, I establish a session key with the server, and then use it for confidentiality. How is this key known to any proxy? the server is a proxy. AYJ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Bearer authentication - for proxies?
Very good to have a clear sequence! Many thanks for all the work explaining this to me. Maybe my misunderstanding can be corrected by considering observations 1) and 2) and answering question 3) in-line: On 1/3/2012 8:30 PM, Amos Jeffries wrote: ... Here is a transaction sequence for that bank: client 1 to proxy: GET /?oauth_token=FOO HTTP/1.1 Host: bank.example.com 1): If this transaction is done over TLS, then this specific proxy is the ONLY entity in the chain that knows the token at the moment, and since it is in the same domain as the server, we must assume its fidelity.. proxy to server: GET /?oauth_token=FOO HTTP/1.1 Host: bank.example.com 2) Now the server knows it, too. (server verifies the token FOO is valid for client 1 through the proxy) bank server to proxy: HTTP/1.1 200 OK stuff proxy to client 1: HTTP/1.1 200 OK stuff .. some time passes. The token FOO expires, gets replaced by token FOO-2. client 1 to proxy: GET /?oauth_token=FOO-2 HTTP/1.1 Host: bank.example.com Same as in 1) proxy to server: GET /?oauth_token=FOO-2 HTTP/1.1 Host: bank.example.com Sane as in 2) (server verifies the token FOO-2 is valid for client 1 through the proxy) bank server to proxy: HTTP/1.1 200 OK other-stuff proxy to client 1: HTTP/1.1 200 OK other-stuff Attacker processes some URL records they somehow swiped from the client transactions... 3) How can attacker swipe it, if the token was passed *as part of an encrypted payload?* attacker to proxy: GET /?oauth_token=FOO HTTP/1.1 Host: bank.example.com proxy to attacker: HTTP/1.1 200 OK stuff ... Oops. attacker to proxy: GET /?oauth_token=FOO-2 HTTP/1.1 Host: bank.example.com proxy to attacker: HTTP/1.1 200 OK other-stuff ... Oops. I assume for clarity that the server and client 1 have both correctly implemented Bearer and are performing proper validation and expiry on the query-string tokens. The mitigation is for the server which implements Bearer to be sending Cache-Control with one of the values: no-store, private, proxy-revalidate and/or must-revalidate. AYJ Then it is the bank's problem, not OAuth's as far as I am concerned... Igor On 1/2/2012 7:36 PM, Amos Jeffries wrote: On 1/2/2012 7:07 AM, Amos Jeffries wrote: On 2/01/2012 11:00 p.m., Torsten Lodderstedt wrote: ... general note: I do not understand why caching proxies should impose a problem in case TLS is used (end2end). Could you please explain? Because TLS is hop-by-hop (in HTTP hops, end-to-end only in TCP hops). Proxies which decrypt TLS and provide responses out of cache are already deployed in many places. Mostly in the form of reverse-proxies, but corporate decryption proxies are also on the increase. AYJ On 3/01/2012 11:17 a.m., Igor Faynberg wrote: I am at a loss here; granted, it is a gray area... Does it mean that RFC 2817 has not been implemented properly? From RFC 2817: 5. Upgrade across Proxies As a hop-by-hop header, Upgrade is negotiated between each pair of HTTP counterparties. If a User Agent sends a request with an Upgrade header to a proxy, it is requesting a change to the protocol between itself and the proxy, not an end-to-end change. The more common case is CONNECT method from RFC 2068, from a user agent to a reverse-proxy. Same behaviour. To make it simple: At the client, I establish a session key with the server, and then use it for confidentiality. How is this key known to any proxy? the server is a proxy. AYJ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Bearer authentication - for proxies?
On 4/01/2012 3:58 p.m., Igor Faynberg wrote: Very good to have a clear sequence! Many thanks for all the work explaining this to me. Maybe my misunderstanding can be corrected by considering observations 1) and 2) and answering question 3) in-line: On 1/3/2012 8:30 PM, Amos Jeffries wrote: ... Here is a transaction sequence for that bank: client 1 to proxy: GET /?oauth_token=FOO HTTP/1.1 Host: bank.example.com 1): If this transaction is done over TLS, then this specific proxy is the ONLY entity in the chain that knows the token at the moment, and since it is in the same domain as the server, we must assume its fidelity.. The client does too, surely. Fidelity, well; * it is going to cache the reply for re-use, === this is what I worry about. * it is going to log the URL+token for a longish term, * it may pass the URL+token in unencrypted packets (via ICP, HTCP, UDP syslog) to any peers it may have, Given these risks are all internal to the security domain and so very slight, they are still weak points in the transactions long-term integrity. Adding the cache-controls erases the risks related to caching. With correct CC headers URL replay would fail even if TLS were not present. proxy to server: GET /?oauth_token=FOO HTTP/1.1 Host: bank.example.com 2) Now the server knows it, too. (server verifies the token FOO is valid for client 1 through the proxy) bank server to proxy: HTTP/1.1 200 OK stuff proxy to client 1: HTTP/1.1 200 OK stuff .. some time passes. The token FOO expires, gets replaced by token FOO-2. client 1 to proxy: GET /?oauth_token=FOO-2 HTTP/1.1 Host: bank.example.com Same as in 1) proxy to server: GET /?oauth_token=FOO-2 HTTP/1.1 Host: bank.example.com Sane as in 2) (server verifies the token FOO-2 is valid for client 1 through the proxy) bank server to proxy: HTTP/1.1 200 OK other-stuff proxy to client 1: HTTP/1.1 200 OK other-stuff Attacker processes some URL records they somehow swiped from the client transactions... 3) How can attacker swipe it, if the token was passed *as part of an encrypted payload?* In the last year or so it has become safe to assume SSL/TLS is compromised by MITM. Or alternatively some secondary infection at one of the end points. Paranoia dictates that someone will figure it out somehow if the stakes are high enough. When they do, its a good idea to have the rest of the system firmly sealed. The given sequence was for the reverse-proxy. The alternative scenario is an identical sequence with a SSL interception proxy. For example an installation of: http://wiki.squid-cache.org/Features/SslBump. In that alternative the proxy is outside the servers security domain and inside some third-party ISP domain at the user end. AYJ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Bearer authentication - for proxies?
On 2/01/2012 7:25 p.m., Igor Faynberg wrote: On 12/30/2011 10:14 PM, Amos Jeffries wrote: Reading section 2.3, it appears this method of transferring the credentials is open to replay attacks when caching TLS middleware is present. I believe this spec should mandate cache controls on responses using that method. Otherwise a lot of HTTP compliant middleware will feel free to store and supply the protected response to later replay attacks. Amos, I believe that the draft addresses the replay matters by specifying the validity time field. Do you see a problem with that? I did not see any such validity time field in the HTTP mechanisms. You mean the validity period of the token itself? that would be irrelevant as the case I am raising is for software which does not support Bearer specs. (1) assuming the client is malicious and cannot be trusted to follow the bearer token limits. (2) the proxy acting as server for the transaction does *not* support bearer and is thus not implementing any bearer token time limitations. The HTTP definition of www-auth specifies an implicit Cache-Control: private unless explicit public is added. The cache supports the HTTP imiplicit definitinon and does not cache the reply. Replay requests will get nothing from the cache. In the query string case proxies use the full abolute URL (including query string with token) as part of the storage key. The HTTP spec outlines that the absence of cache-control time limitations permits a proxy to store the reply as long as it wishes. Meaning that any time limits imposed by the Bearer spec around the token itself are not supported. Therefore Therefore any client requesting the URL with the token can be presented with a cached reply *indefinitely*. At no point between malicious client and proxy is any bearer implementation involved. (I did not understand what HTTP-compliant middleware meant, but if it is something at the proxies, I think this is further addressed by making TLS a must--which will make the token simply invisible.) By HTTP compolliant middleware I mean any software which obeys HTTP proxy guidelines but not necessarily OAuth or other specifications. There are alot of those. With best wishes for the New Year to you and all OAuthers, Igor Igor ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Bearer authentication - for proxies?
Hi, Amos, I believe that the draft addresses the replay matters by specifying the validity time field. Do you see a problem with that? I did not see any such validity time field in the HTTP mechanisms. You mean the validity period of the token itself? that would be irrelevant as the case I am raising is for software which does not support Bearer specs. Even if the software is not aware of the bearer spec, a token that becomes invalid after a certain time span cannot sucessfully be replayed any longer. general note: I do not understand why caching proxies should impose a problem in case TLS is used (end2end). Could you please explain? regards, Torsten. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Bearer authentication - for proxies?
On 2/01/2012 11:00 p.m., Torsten Lodderstedt wrote: Hi, Amos, I believe that the draft addresses the replay matters by specifying the validity time field. Do you see a problem with that? I did not see any such validity time field in the HTTP mechanisms. You mean the validity period of the token itself? that would be irrelevant as the case I am raising is for software which does not support Bearer specs. Even if the software is not aware of the bearer spec, a token that becomes invalid after a certain time span cannot sucessfully be replayed any longer. There is no time span limit mentioned in the section 2.3 when token is passed in the query string. That is my point. Proxies which cache and obey HTTP but not Bearer *will* answer to replay attacks by providing the supposedly secure response body. general note: I do not understand why caching proxies should impose a problem in case TLS is used (end2end). Could you please explain? Because TLS is hop-by-hop (in HTTP hops, end-to-end only in TCP hops). Proxies which decrypt TLS and provide responses out of cache are already deployed in many places. Mostly in the form of reverse-proxies, but corporate decryption proxies are also on the increase. AYJ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Bearer authentication - for proxies?
I am at a loss here; granted, it is a gray area... Does it mean that RFC 2817 has not been implemented properly? To make it simple: At the client, I establish a session key with the server, and then use it for confidentiality. How is this key known to any proxy? Igor On 1/2/2012 7:07 AM, Amos Jeffries wrote: On 2/01/2012 11:00 p.m., Torsten Lodderstedt wrote: ... general note: I do not understand why caching proxies should impose a problem in case TLS is used (end2end). Could you please explain? Because TLS is hop-by-hop (in HTTP hops, end-to-end only in TCP hops). Proxies which decrypt TLS and provide responses out of cache are already deployed in many places. Mostly in the form of reverse-proxies, but corporate decryption proxies are also on the increase. AYJ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Bearer authentication - for proxies?
On 1/2/2012 7:07 AM, Amos Jeffries wrote: On 2/01/2012 11:00 p.m., Torsten Lodderstedt wrote: ... general note: I do not understand why caching proxies should impose a problem in case TLS is used (end2end). Could you please explain? Because TLS is hop-by-hop (in HTTP hops, end-to-end only in TCP hops). Proxies which decrypt TLS and provide responses out of cache are already deployed in many places. Mostly in the form of reverse-proxies, but corporate decryption proxies are also on the increase. AYJ On 3/01/2012 11:17 a.m., Igor Faynberg wrote: I am at a loss here; granted, it is a gray area... Does it mean that RFC 2817 has not been implemented properly? From RFC 2817: 5. Upgrade across Proxies As a hop-by-hop header, Upgrade is negotiated between each pair of HTTP counterparties. If a User Agent sends a request with an Upgrade header to a proxy, it is requesting a change to the protocol between itself and the proxy, not an end-to-end change. The more common case is CONNECT method from RFC 2068, from a user agent to a reverse-proxy. Same behaviour. To make it simple: At the client, I establish a session key with the server, and then use it for confidentiality. How is this key known to any proxy? the server is a proxy. AYJ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Bearer authentication - for proxies?
On 12/30/2011 10:14 PM, Amos Jeffries wrote: Reading section 2.3, it appears this method of transferring the credentials is open to replay attacks when caching TLS middleware is present. I believe this spec should mandate cache controls on responses using that method. Otherwise a lot of HTTP compliant middleware will feel free to store and supply the protected response to later replay attacks. Amos, I believe that the draft addresses the replay matters by specifying the validity time field. Do you see a problem with that? (I did not understand what HTTP-compliant middleware meant, but if it is something at the proxies, I think this is further addressed by making TLS a must--which will make the token simply invisible.) With best wishes for the New Year to you and all OAuthers, Igor Igor ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Bearer authentication - for proxies?
re-posting for cc to OAuth WG On 25/12/2011 7:21 p.m., Amos Jeffries wrote: On Sat, 24 Dec 2011 08:46:45 -0500, Mark Nottingham wrote: The OAUTH WG is creating a new authentication scheme for bearer tokens: http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-15 Reading section 2.3, it appears this method of transferring the credentials is open to replay attacks when caching TLS middleware is present. I believe this spec should mandate cache controls on responses using that method. Otherwise a lot of HTTP compliant middleware will feel free to store and supply the protected response to later replay attacks. During review, I wondered whether this might be a suitable scheme for proxies; the draft doesn't currently specify it as such, and our list of considerations for new schemes asks them to consider this. Do any of the proxy implementers on the list have thoughts about this / possible interest in it? I think it would be a good idea to prepare for. Quite a few admin these days consider transit to be a service that needs authenticating as much as any origin server resource. It might even encourage progress on the TLS proxy connection developments we have been waiting for. AYJ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
