Hello John, Thank you for condensing this discussion thread. See inline for my reasoning why I think that this issue is less severe than one would expect at first:
John Mattsson <[email protected]> writes: > Summarizing my thoughts and opinion on this issue. Changing the title > to highlight the issues better. > > As currently specified in draft-ietf-ace-oauth-authz-35, the RS will > happily send the AS address to any node that asks. This causes two > problems. > > - If C acts on the unauthorized information, this is an attack vector > for DoS attacks as an attacker on the C-RS path can make C contact a > chosen node on the Internet. The important part here is the "If". A proper client MUST NOT act on unauthorized information at any time. The workaround is the list of known AS'es in the draft. (In the current architecture, a client would not and cannot communicate with an unknown AS anyway as it has no way to establish a secure communication.) > - 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/” This is a valid concern. However, I would argue that the Uri-Path in this URI should not be constructed to reveal this information in the first place. All discussions so far assumed that the authorization information endpoint on the AS would be named more descriptively as, e.g., /autz-info. This could at least mitigate the issue. > The requirement "the client MUST be able to determine whether an AS > has the authority to issue access tokens for a certain RS. This can > for example be done through pre-configured lists, or through an online > lookup mechanism that in turn also must be secured." indicates that C > is required to have another mechanism to determine the AS for a > specific RS and that the unauthorized AS address is completely > redundant. No. This indicates that before contacting an AS (in order to retrieve an access token for its communication with RS), the client must be sure that it trusts the AS to provide this access token. This is something that the client always needs to do, independent of the discovery mechanism. > The draft does not discuss the privacy issues of unauthorized AS > addresses at all and the draft is diminishing the DoS issues by only > talking about compromised RS and attacking an AS. This indicates that > none of these issues has been discussed enough. > > I currently have a strong opinion that Unauthorized AS address should > be removed from the specification. I still think that due to the lack of a secure discovery mechanism for authorized AS'es, this mechanism is the best we have. Otherwise, the specification would leave the reader completely in the dark on how to guess to which AS the RS has delegated its authorization tasks. (A natural way would be to include it in /.well-known/core but I fail to see a difference except for an additional roundtrip in case the client is not aware a priori that the requested resource is protected.) Grüße Olaf _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
