I agree with Hannes and Ben that the Client Token is speculative in nature, 
solving a problem that's it's not clear that we even have.  It certainly isn't 
OAuth.

I already made this point in my earlier comprehensive review of the spec, but 
I'll repeat again here.  Please remove it!

                                -- Mike

-----Original Message-----
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Benjamin Kaduk
Sent: Thursday, February 1, 2018 6:31 PM
To: Hannes Tschofenig <hannes.tschofe...@arm.com>
Cc: ace@ietf.org
Subject: Re: [Ace] Removal of the Client Token from ACE-OAuth draft

On Thu, Feb 01, 2018 at 01:59:48PM +0000, Hannes Tschofenig wrote:
> Hi all,
> 
> the Client Token is a new mechanism in the ACE-OAuth that aims to solve a 
> scenario where the Client does not have connectivity to the Authorization 
> Server to obtain an access token while the Resource Server does.

This sounds eerily reminiscent of the IAKERB GSS-API mechanism, where the 
initiator uses the acceptor as a proxy to contact the Kerberos KDC, obtain an 
initial ticket, and obtain the credentials needed to complete the "normal" 
Kerberos exchange with the acceptor.
(An early draft of) it got implemented, but the spec kind of died and we don't 
know of anyone actually using it.

So, I support not including it unless we have some actual use cases in mind.

-Ben

> The solution is therefore for the Client to use the Resource Server to relay 
> messages to the Authorization Server.
> 
> While this sounds nice it does not follow the OAuth model and we, at 
> ARM, have not seen anyone requesting this feature. It is also not 
> fully specified in the spec: since I have been doing a formal analysis 
> of this protocol variant for the OAuth Security Workshop I had to 
> notice that it is not secure. (I will post the paper to the list 
> asap.)
> 
> Note that I am not saying that we should never do this work but I prefer that 
> someone who really cares about this use case describes it in an independent 
> document.
> 
> In summary, I am again requesting that the Client Token functionality is 
> removed from the ACE-OAuth draft.
> 
> Ciao
> Hannes
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.

> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Reply via email to