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

[Stefanie Gerdes <[e-mail]>]

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 AS has the authority to issue access tokens for this RS. Otherwise, a compromised RS may use this to perform a denial of service against a specific AS, by redirecting a large number of client requests to that AS.
> 
> [JLS] I do not know how C is supposed to be able to determine if AS has the authority to issue access tokens for a specific RS.  If it had the ability to do that then it can go directly to the AS in question without ever needing to use this mechanism.  This mechanism is designed to be used for the case where C does not have a priori knowledge about which AS it will talk to get the token for RS.

C may use the AS URI to determine if the AS is responsible for this
server, e.g., by looking it up in a secured resource directory that
contains the necessary information or by asking its own authorization
manager. As there may be large numbers of resource server that may
change a lot, it may be beneficial to also have the AS URI. That depends
on the client side authorization mechanism, of course. If C does not
require this information, it does not have to use it.

The unauthorized resource request mechanism has an additional purpose:
it also enables RS to specify a nonce that can later be reflected to it
in the access token and thereby enables RS to validate that the access
token is recent. It would be useful to make the AS address optional in
the AS request creation hints.

> 
>>
>>>> - 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 = 
>>>> coaps://as.hopkinsmedicine.org/kimmel_cancer_center/”
> 
> [JLS] My first hope is that this RS would never return an AS address to a client.   Sending information which has secure privacy problems amounts to a case where the rule should be:  If C does not know what AS to talk to, it has no business talking to me (RS).
> 
> [JLS] This is the type of situation where that information itself is going to be information to which access is to be restricted and where you need to talk to an AS to get permissions to get that information.  In this type of situation I would expect that the information would only be available either throw an already secure channel or from a DS with the, not yet defined, AS attributes.

Wouldn't the client breach the privacy of its owner simply by
communicating with an AS with such a URI?

I send a proposal to address this problem in my answer to John [1].

Viele Grüße
Steffi

[1] https://mailarchive.ietf.org/arch/msg/ace/0639BdkMvJZdUjLBJIX21EiSvbw/