Hi Hannes, The paper you are referring to was the only new data point you included when you started this thread. I’m not questioning the correctness of your analysis, just saying that we are now taking action without having seen the analysis.
As I replied to you in our discussion here at the OMA meeting the lack of authentication from RS to the AS may actually carry over to the Access Token. Should we then remove the Access Token as well? My personal view on this is that we should try to support the use case with offline Clients (i.e. which cannot communicate directly with the AS) which does not have a previous security association with the RS (e.g. during device deployment). This would encompasses the authorization of Client and key provisioning to the RS. This is the Access Token. It additionally requires key provisioning to the Client, and, if desired, the "authorization" of RS - i.e. the conditions under which the Client should actually make the request. How do we get that information from the AS to the Client? Göran From: Hannes Tschofenig <hannes.tschofe...@arm.com<mailto:hannes.tschofe...@arm.com>> Date: Thursday 8 February 2018 at 10:38 To: Göran Selander <goran.selan...@ericsson.com<mailto:goran.selan...@ericsson.com>>, "ace@ietf.org<mailto:ace@ietf.org>" <ace@ietf.org<mailto:ace@ietf.org>> Subject: RE: [Ace] Removal of the Client Token from ACE-OAuth draft 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; ace@ietf.org<mailto:ace@ietf.org> 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: "ace@ietf.org<mailto:ace@ietf.org>" <ace@ietf.org<mailto:ace@ietf.org>> 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
