Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy

[Stefanie Gerdes <[e-mail]>]

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/