Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy

2020-09-10 Thread Michael Richardson
sg> A compromised RS may use the hints for attempting to trick a client sg> into contacting an AS that is not supposed to be in charge of that RS. sg> Therefore, C must not communicate with an AS if it cannot determine sg> that this AS has the authority to issue access tokens for

Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy

2020-09-10 Thread Michael Richardson
John Mattsson wrote: > - That RS shares the AS address with anybody that asks can be a severe > privacy problem. If RS is a medical device, the AS address can reveal > sensitive information. If RS is a blood pressure sensor it could > e.g. be “AS address = >

Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy

2020-09-10 Thread Stefanie Gerdes
Hi all, On 09/10/2020 02:10 PM, Stefanie Gerdes wrote: > We also should decouple the AS request creation hints from the > explanation of the AS discovery mechanism. The hints have the additional > purpose that they may contain the resource server's cnonce that the > resource server can later use

Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy

2020-09-10 Thread Stefanie Gerdes
Hi Ludwig, comments inline. On 09/10/2020 08:49 AM, Seitz Ludwig wrote: > Seeing that the mechanism was introduced to bootstrap a client that doesn't > know which AS to talk to for a specific RS and given the issues raised by > John, what other options do we have that are more secure? The

Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy

2020-09-10 Thread Stefanie Gerdes
Hi Jim, comments inline. On 09/10/2020 12:11 AM, Jim Schaad wrote: > A compromised RS may use the hints for attempting to trick a client into > contacting an AS that is not supposed to be in charge of that RS. > Therefore, C must not communicate with an AS if it cannot determine that this >

Re: [Ace] Framework Figure 12

2020-09-10 Thread Francesca Palombini
And just to use the correct CBOR terminology, I indeed meant _unsigned and negative_ seems to be allowed rather than just unsigned. Francesca On 10/09/2020, 10:38, "Francesca Palombini" wrote: Hi, I noticed a mistake in the current document, that escaped the several rounds of

[Ace] Framework Figure 12

2020-09-10 Thread Francesca Palombini
Hi, I noticed a mistake in the current document, that escaped the several rounds of review. Figure 12 states that the ace_profile is supposed to have for value an unsigned integer. The ACE Profile registry in Section 8.8 implies that the profile can be both positive and negative integers.

Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy

2020-09-10 Thread Olaf Bergmann
Seitz Ludwig writes: > Seeing that the mechanism was introduced to bootstrap a client that > doesn't know which AS to talk to for a specific RS and given the > issues raised by John, what other options do we have that are more > secure? > > a.) A resource directory lookup? I'm not knowledgeable

Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy

2020-09-10 Thread Seitz Ludwig
Seeing that the mechanism was introduced to bootstrap a client that doesn't know which AS to talk to for a specific RS and given the issues raised by John, what other options do we have that are more secure? a.) A resource directory lookup? I'm not knowledgeable enough on RD to answer whether