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