Hello John, Steffi made some suggestions to improve the sections you criticized (see also https://github.com/ace-wg/ace-oauth/pull/177).
Do you think they address your issues? Does the WG have an opinion on the way forward? (Chairs? Ads?) /Ludwig > -----Original Message----- > From: Ace <ace-boun...@ietf.org> On Behalf Of Stefanie Gerdes > Sent: den 10 september 2020 14:11 > To: ace@ietf.org > Subject: Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, > DoS, and privacy > > Hi Ludwig, > > comments inline. > > On 09/10/2020 08:49 AM, Seitz Ludwig wrote: > > Seeing that the mechanism was introduced to bootstrap a client that > doesn't know which AS to talk to for a specific RS and given the issues raised > by John, what other options do we have that are more secure? > > The mechanism in itself does not have a security problem. If C would > communicate with an AS that is not authorized for this RS that would be a > problem, but as section 6.5 states, C must be able to validate that. > This point is really important for the security of the solution, regardless > of the > discovery mechanism. The privacy problem that AS URIs may pose should be > mentioned in the privacy considerations. I made a text proposal in my > response to John [1]. > > > > > a.) A resource directory lookup? I'm not knowledgeable enough on RD to > answer whether that is more secure, but Steffi or Olaf or Carsten should > have more insight on this. > > > > b.) A callback to a trusted entity (say the client owner). The issue here is > that we have not defined any interactions for that entity yet. > > > > c.) John suggested something with DNS in the first mail. I have no idea how > this would work, John what did you have in mind there? > > > > For the draft I see two ways forward: > > > > 1.) Remove the whole discovery mechanism and just state that at this point > we assume that the knowledge of the right AS is pre-configured/supplied > out-of-band to the client. This leaves room for future work that specifies an > in-band method. > > > > 2.) Try to fix this (e.g. by specifying one of the methods a-c above). > > > > I do not have the time to do 2 so I clearly prefer option 1, but if any of > > my > co-authors can put in the work I'd be very glad. > > I already made text proposals that hopefully clarify the problems that John > brought up [1]. I think it is really important to address these problems in > sections 6.4 and 6.5 in the draft and not just ignore them or leave them for > later. That would leave the framework open for attacks. Developers will have > difficulties to close this gap on their own. > > We also should decouple the AS request creation hints from the explanation > of the AS discovery mechanism. The hints have the additional purpose that > they may contain the resource server's cnonce that the resource server can > later use to validate the access token. > Therefore, the AS URI should be optional in the AS request creation hints, > and we should make section 5.1.1 section 5.2. > > Viele Grüße > Steffi > > [1] > https://mailarchive.ietf.org/arch/msg/ace/0639BdkMvJZdUjLBJIX21EiSvbw/ > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
