Subject: [Ace] Removal of the Client Token from ACE-OAuth draft

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 1 Feb 2018 13:59:48 +0000

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

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.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 1 Feb 2018 20:31:04 -0600

> 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 Resour…

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

> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Mike Jones <[email-masked]>
Date: Fri, 2 Feb 2018 02:35:20 +0000

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:[email-masked]] On Behalf Of Benjamin Kaduk
Sent: Thursday, February 1, 2018 6:31 PM
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ace] Removal of the Client Token from ACE-OAuth draft

> 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 Resour…

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

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

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 5 Feb 2018 08:01:12 +0100

On 2018-02-01 14:59, 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.
> 
> The solution is therefore for the Client to use the Resource Server to 
> relay messages to the Authorization Server.
> 
> ARM, have not seen anyone requesting this feature.

~snip~

> removed from the ACE-OAuth draft.

I agree that interest for this use case has been lukewarm at most in the 
WG. I will remove that feature from the draft in the next update.

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 5 Feb 2018 08:56:00 +0100

On Feb 5, 2018, at 08:01, Ludwig Seitz <[email-masked]> wrote:
> 
> I agree that interest for this use case has been lukewarm at most in the WG.

Well, IoT is a vast field and we cannot expect all areas of it to be represented equally well in the WG yet.

> I will remove that feature from the draft in the next update.

Right.  But please put it into a separate draft, so we can

— develop it further and make it ready for use, and
— ensure that the base framework is prepared for additional flows like this.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 5 Feb 2018 10:59:34 +0000

Hi Carsten,

> Right.  But please put it into a separate draft, so we can — develop it further and make it ready for use, and — ensure that the base framework is prepared for additional flows like this.

Good idea and maybe we can find someone who volunteers to become the author of such a document.

Ciao
Hannes