Hi Göran, I haven’t posted the write-up yet since it is a submission to the workshop and the papers are currently in review. As mentioned to you at the OMA meeting we are currently attending the analysis revealed two issues, namely the lack of stated goals (which makes any security analysis challenging) and the lack of authentication from the client to the AS.
IMHO it is, however, only a small data point in this discussion. I believe the more important question is whether there are people in interested in this scenario or not. I have started my opinion about this already at earlier meetings. There is also the IPR disclosure that some folks may take into account, which was posted to the list: https://www.ietf.org/mail-archive/web/ace/current/msg02572.html Since you have not posted your view on this topic yet you may want to think about whether you consider the feature important for Ericsson. If you believe it is important then maybe you could, as Carsten suggested, continue working on the functionality in an independent document. If you want to spend your time on it then I would recommend to do two things, namely (a) specify what goals the mechanism is supposed to accomplish and (b) build it on top of existing authentication and key exchange protocol. The latter part is quite easy since lots of research was done on 3-party security protocols and there are various protocols that fit the desired message communication pattern. This could give higher confidence in the work. Ciao Hannes From: Göran Selander [mailto:goran.selan...@ericsson.com] Sent: 08 February 2018 09:22 To: Hannes Tschofenig; email@example.com Subject: Re: [Ace] Removal of the Client Token from ACE-OAuth draft Hi Hannes, From: Ace <ace-boun...@ietf.org<mailto:ace-boun...@ietf.org>> on behalf of Hannes Tschofenig <hannes.tschofe...@arm.com<mailto:hannes.tschofe...@arm.com>> Date: Thursday 1 February 2018 at 13:59 To: "firstname.lastname@example.org<mailto:email@example.com>" <firstname.lastname@example.org<mailto:email@example.com>> Subject: [Ace] Removal of the Client Token from ACE-OAuth draft 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. 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.) Have you posted this? I couldn’t find it my Inbox. Göran 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