Subject: [OAUTH-WG] Token Transfer Protocol

From: Niklas Neumann <[email-masked]>
Date: Mon, 18 Oct 2010 18:03:12 +0200

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

---

From: Justin Richer <[email-masked]>
Date: Mon, 18 Oct 2010 12:15:02 -0400

The ability to securely transfer tokens between systems is the last
missing part to the redelegation problem. Right now, we can have an
authorized client request a new access token with an equal or lesser
scope and be granted that with no user interaction. That token can then
be handed, using the below or similar mechanism, to another system for
its own access. I'm assuming this would work with tokens containing a
secret part (to be used for signing) as well as plain bearer tokens,
too.

 -- Justin

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 18 Oct 2010 12:47:38 -0400

Niklas Neumann wrote:
> ...
> agent or authentication from a different device/application than the 
> one accessing the consumer).

A lot of interest on my part. 

Igor

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 18 Oct 2010 16:19:48 -0700

Trying to imagine a real world use case.

For example, section 2.2, how would the public terminal know that a
user device exists, let alone where?

Thanks,
Marius

On Mon, Oct 18, 2010 at 9:03 AM, Niklas Neumann
<[email-masked]> 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:
> 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).
>
> 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
>
> --
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Niklas Neumann <[email-masked]>
Date: Tue, 19 Oct 2010 09:42:08 +0200

In the project I am working on we are using discovery based on dynamic 
DNS but there probably are better ways. I felt that the discovery was 
rather application specific and didn't really fit into the draft but I 
am happy to expand if you think that will make things more clear.

Currently our (project-specific) workflow is something like this:
User wants to use (untrusted) public terminal to access a private 
resource. Instead of his username he inputs his authentication device 
address (i.e. DNS name of his mobile). Either the terminal or the server 
(depending on where the protocol is supported) uses the address to run 
STTP and then just substitutes the tokens STTP delivers as the user's 
credentials.
The difference to a "normal" authentication is that all the "magic" is 
happening on the mobile device where the user is comfortable enough to 
use his actual credentials. For example, the device can use a 
service-specific API (or actually STTP again) to retrieve a one-time 
password that can be used (somewhat) safely on the public terminal. 
Facebook just started a service to send people otps to their mobile 
phone via text messages 
(http://blog.facebook.com/blog.php?post=436800707130) which could be 
easily expanded to a more seamless (and world-wide available) 
authentication scenario using STTP (I am not affiliated with Facebook in 
any way, it's just an example).

Best regards
   Niklas

---

From: George Fletcher <[email-masked]>
Date: Tue, 19 Oct 2010 14:15:40 -0400

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:
> 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: 
> 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
>

---

From: Niklas Neumann <[email-masked]>
Date: Thu, 21 Oct 2010 11:07:48 +0200

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