Hi Ludwig, The problem I have is that the current mechanism is presented as a generic discovery mechanism and that none of the disadvantages are mentioned in section 5.1.
"A generic procedure is described in Section 5.1" The mechanism is not presented as an error message when the client in good faith tries to access a resource. It is presented as something C do intentionally to dicsover the AS. In the description in the draft, C is clearly aware that the request is unauthorized. Section 6.4 describes the security properties quite well. But I cannot see any discusion about the inefficiency of doing discovery over the C-RS path, which in many cases is contrained. The current presentation is: 5.1 generic procedure to discover AS 6.4 BTW this mechanism has some security limitation My view would be that is should be more like: 5.1 Error message with AS address X.X BTW the error message could be used for AS discovery but has limited effeciency and security and is not recommended. Cheers, John -----Original Message----- From: Seitz Ludwig <ludwig.se...@combitech.se> Date: Monday, 7 September 2020 at 08:28 To: John Mattsson <john.matts...@ericsson.com>, "ace@ietf.org" <ace@ietf.org> Subject: RE: AS discovery in draft-ietf-ace-oauth-authz-35 Hi John, Replies inline /Ludwig > -----Original Message----- > From: Ace <ace-boun...@ietf.org> On Behalf Of John Mattsson > Sent: den 5 september 2020 14:53 > To: ace@ietf.org > Subject: [Ace] AS discovery in draft-ietf-ace-oauth-authz-35 > > Hi, > > I just reviewed draft-ietf-ace-oscore-profile. This made me wonder about > the AS discovery mechanism in the ACE framework. Why is this particular > discovery mechanism given so much attention? Of all possible discovery > mechanisms, this seems like one of the worst as: > > 1. It requires a round-trip over the C-RS path which is typically the most > constrained path in the architecture. > 2. The response would in many cases be unprotected, which means C > does not know if the response comes from RS or an attacker. > > A discovery mechanism using a non-contrained path (e.g. DNS, but could be > any type of look up service) would in many cases be much more efficient and > should be recommended. Such a mechanism might also be protected in > more cases and therefore rule out the possibility that the response came > from an attacker. > > I understand that the ACE framework draft does not want to specify any > other AS discovery mechanism, but at a minimum the severe limitations of > the current mechanism should be detailed. The limitations of this mechanism are detailed in section 6.4, do you think that there is some consideration missing from that section? > I my view the current mechanism > should be not recommended and only used as an error message when the > client in good faith try to access a resource believing that it might have the > right to access it. > It is indeed intended as an error message when the client in good faith tries to access a resource believing it might have the right to access it. _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
