Hi Göran,

I believe there are new data points on this topic since the time the 
requirements & use case draft was published. A lot of use cases were written 
down and not all of them are still being considered by the folks in the working 
group. Time has passed and we haven’t seen the same amount of interest in the 
Client Token even among the authors as with the other functionality. 
Furthermore, we have also received a review from Mike where he restated what I 
said earlier about the Client Token. Then, there was the recent IPR disclosure.

If you believe we need to cover the Client Token functionality because you need 
it then you that’s Ok. But so far I don’t think I hear you say that.

The term used in the Client Token for the message sent by the Client to the RS 
is the Access Token but it actually isn’t really an access token. For those who 
want to work on the proposal I would recommend to change it as well. So far, I 
have not seen a problem with the PoP-based access token.

Ciao
Hannes

PS: I am also encourage others to analyse the functionality in the OAuth-ACE 
(and in other specs).


From: Göran Selander [mailto:goran.selan...@ericsson.com]
Sent: 08 February 2018 12:36
To: Hannes Tschofenig; ace@ietf.org
Subject: Re: [Ace] Removal of the Client Token from ACE-OAuth draft

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

Reply via email to