Yes the server is supposed to verify the Reflection-Key. Regarding any
middleboxes, the Reflection-Key from the server's perspective is a
somewhat static value and therefore can be configured on an application
level rather than being determined dynamically.
Specifically, if load-balancers or off-loaders are used, the mechanism
still works if the application has been configured to check the
Reflection-Key against a list of valid source IP/port pairs or public
certificate fingerprints that are externally or statically supplied
rather than determining the values itself. I hope this clear things up.
Best regards
Niklas
On 10/19/2010 08:15 PM, George Fletcher wrote:
Question on the Reflection-Key parameter when it is generated from the
source IP and port pair. Is the server receiving the request supposed to
verify that the data in the Reflection-Key matches the data of the
inbound connection? If so, then I think NAT'ing firewalls, proxies and
network SSL off-loaders (e.g. netscalers) will break the security mechanism.
Thanks,
George
On 10/18/10 12:03 PM, Niklas Neumann wrote:
Hello everybody,
I am currently working on a projected related to authentication and
secure token transfer between multiple devices. As such we are
employing a simple protocol that handles token transfers independent
of the actual type of token. We have adapted the protocol to be used
with OAuth tokens and submitted it as an Internet Draft:
http://tools.ietf.org/html/draft-neumann-oauth-token-transfer
I was wondering if there is interest in employing such a protocol in
cases where the HTTP redirection schemes of OAuth are not available or
not working well (e.g. desktop applications without access to a user
agent or authentication from a different device/application than the
one accessing the consumer).
Compared to other proposals such as
draft-dehora-farrell-oauth-accesstoken-creds the STTP is more
heavyweight but in turn it also has more options. With regards to
authentication we didn't use SASL for complexity reasons in our work
initialy but I don't see any reason not to include it if this is
deemed more appropriate.
The work that the draft is based on is still ongoing. Please
understand the draft as no more than a discussion proposal on how
OAuth could be opened to non-web-based environments and scenarios that
involve multiple devices without overloading the OAuth specification
itself. I am happy to further improve the draft if you think this
might be a viable option.
Best regards
Niklas
--
Niklas Neumann - University of Goettingen, Institute of Computer Science
http://user.informatik.uni-goettingen.de/~nneuman1/
Tel: +49 551 39-172053
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
