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

[Stefanie Gerdes <[e-mail]>]

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.

> 
>>> - 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/”
>>
>> 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