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

[Seitz Ludwig <[e-mail]>]

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?

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.

/Ludwig


> -----Original Message-----
> From: Ace <[e-mail]> On Behalf Of Jim Schaad
> Sent: den 10 september 2020 00:11
> To: 'Stefanie Gerdes' <[e-mail]>; [e-mail]
> Subject: Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address,
> DoS, and privacy
> 
> 
> 
> -----Original Message-----
> From: Ace <[e-mail]> On Behalf Of Stefanie Gerdes
> Sent: Wednesday, September 9, 2020 4:12 AM
> To: [e-mail]
> Subject: Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address,
> DoS, and privacy
> 
> Hi John,
> 
> On 09/09/2020 11:36 AM, John Mattsson wrote:
> 
> <snip>
> 
> >>> 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.
> 
> Hm, section 6.5 already states "the client MUST be able to determine
> whether an AS has the authority to issue access tokens for a certain RS." We
> can add "The client must not interact with an AS if it cannot determine that
> AS has the authority for this RS."
> 
> We also should change section 6.4 because the attack described there is not
> possible as C must not interact with an AS that is not authorized for this RS. I
> think that paragraph is a relic.
> 
> How about:
> 
> old:
> Initially, no secure channel exists to protect the communication between C
> and RS.  Thus, C cannot determine if the AS Request Creation Hints contained
> in an unprotected response from RS to an unauthorized request (see Section
> 5.1.2) are authentic.  It is therefore advisable to provide C with a (possibly
> hard-coded) list of trustworthy authorization servers, possibly including
> information used to authenticate the AS, such as a public key or certificate
> fingerprint.  AS Request Creation Hints referring to a URI not listed there
> would be ignored.
> 
> A compromised RS may use the hints to trick a client into contacting an AS
> that is not supposed to be in charge of that RS.  Since this AS must be in the
> hard-coded list of trusted AS no violation of privileges and or exposure of
> credentials should happen, since a trusted AS is expected to refuse
> requestes for which it is not applicable and render a corresponding error
> response.  However a compromised RS may use this to perform a denial of
> service against a specific AS, by redirecting a large number of client requests
> to that AS.
> 
> new:
> Initially, no secure channel exists to protect the communication between C
> and RS.  Thus, C cannot determine if the AS Request Creation Hints contained
> in an unprotected response from RS to an unauthorized request (see Section
> 5.1.2) are authentic. C therefore must be able to determine if an AS is
> authorized to provide access tokens for a certain RS.
> 
> A compromised RS may use the hints for attempting to trick a client into
> contacting an AS that is not supposed to be in charge of that RS.
> Therefore, C must not communicate with an AS if it cannot determine that
> this AS has the authority to issue access tokens for this RS. Otherwise, a
> compromised RS may use this to perform a denial of service against a specific
> AS, by redirecting a large number of client requests to that AS.
> 
> [JLS] I do not know how C is supposed to be able to determine if AS has the
> authority to issue access tokens for a specific RS.  If it had the ability to do
> that then it can go directly to the AS in question without ever needing to use
> this mechanism.  This mechanism is designed to be used for the case where C
> does not have a priori knowledge about which AS it will talk to get the token
> for RS.
> 
> >
> >>> - 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/”
> 
> [JLS] My first hope is that this RS would never return an AS address to a
> client.   Sending information which has secure privacy problems amounts to a
> case where the rule should be:  If C does not know what AS to talk to, it has
> no business talking to me (RS).
> 
> [JLS] This is the type of situation where that information itself is going to be
> information to which access is to be restricted and where you need to talk to
> an AS to get permissions to get that information.  In this type of situation I
> would expect that the information would only be available either throw an
> already secure channel or from a DS with the, not yet defined, AS attributes.
> 
> Jim
> 
> 
> >>
> >> 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.
> 
> I guess that an authorization server with such a URI is a general problem since
> the client needs to communicate with it at some point.
> This problem therefore is not specific for the AS Request Creation Hints.
> Nevertheless, we should clarify the impact of the not carefully chosen hints
> on the privacy in the privacy considerations.
> 
> There already is some text about the unauthorized request in the privacy
> considerations. How about:
> 
> old:
> An unprotected response to an unauthorized request (see Section 5.1.2)
> may disclose information about RS and/or its existing relationship with C.  It is
> advisable to include as little information as possible in an unencrypted
> response.
> 
> new:
> An unprotected response to an unauthorized request (see Section 5.1.2)
> may disclose information about RS and/or its existing relationship with C.  It is
> advisable to include as little information as possible in an unencrypted
> response. Even the absolute URI of the AS may reveal sensitive information
> about the service the RS provides. Developers must ensure that the RS does
> not disclose information that has an impact on the privacy of the
> stakeholders in the AS Request Creation Hints. They may choose to use a
> different mechanism for the discovery of the AS if necessary.
> 
> >
> >>> 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.
> 
> There are various possibilities how a client can determine if an AS is
> authorized and responsible for a certain RS. A client that is directly controlled
> by its owner can just ask her. An autonomous client may ask some entity that
> it trusts, e.g., a secured resource directory. In the four-corner architecture,
> the client asks its own authorization manager if the AS is authorized to
> provide access tokens for this RS.
> 
> The Unauthorized Resource Request is only one possible mechanism to
> retrieve the address. That RS sends the AS request creation hints with the
> error response is not mandatory.
> 
> Viele Grüße
> Steffi
> 
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace
> 
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace