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

[Olaf Bergmann <[e-mail]>]

Hello John,

Thank you for condensing this discussion thread. See inline for my
reasoning why I think that this issue is less severe than one would
expect at first:

John Mattsson <john.mattsson=[e-mail]> writes:

> Summarizing my thoughts and opinion on this issue. Changing the title
> to highlight the issues better.
>
> 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.)

> - 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.

> 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.

> 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.)

Grüße
Olaf