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/ _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
