Hi Olof, Your reasoning does seem to be anchored in the draft. See inline.
The current state of the draft is not acceptable. Grüße, John Preuß Mattsson -----Original Message----- From: Olaf Bergmann <[email protected]> Date: Wednesday, 9 September 2020 at 10:20 To: John Mattsson <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy 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.) I cannot find anything in the draft stating that “A proper client MUST NOT act on unauthorized information at any time”. This also raises the question why the unauthorized information is needed in the first place. >> - 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. I don’t find anything in the draft stating that “the Uri-Path in this URI should not be constructed to reveal this information”, or how such a construction would look like. This is not trivial. >> 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. I don’t find anything in the draft stating that “the client must be sure that it trusts the AS”. The draft states that “It is therefore advisable to provide C with a (possibly hard-coded) list of trustworthy authorization servers”. “Advisable” is not the same as “must”, “trustworthy” is not the same as “trust, and “C trust in AS” is completely different than “whether an AS has the authority to issue access tokens for a certain RS” >> 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.) Your reasoning seems to indicate that the mechanism "the client MUST be able to determine whether an AS has the authority to issue access tokens for a certain RS” is just an imaginary requirement, and not something you believe will be possible in practice. Grüße Olaf _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
