John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org> writes:
> Hi Olof,
>
> Your reasoning does seem to be anchored in the draft. See inline.
>
> The current state of the draft is not acceptable.
I may agree with you in this point in so far as the sections 6.4 and 6.5
might contradict each other as Steffi has pointed out previously. And I
agree with you also if the requirements on proper behavior I have stated
are not clearly stated in the draft as you seem to believe.
More inline.
>
> -----Original Message-----
> From: Olaf Bergmann <bergm...@tzi.org>
> Date: Wednesday, 9 September 2020 at 10:20
> To: John Mattsson <john.matts...@ericsson.com>
> Cc: "ace@ietf.org" <ace@ietf.org>,
> "draft-ietf-ace-oauth-authz....@ietf.org"
> <draft-ietf-ace-oauth-authz....@ietf.org>
> Subject: Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS
> address, DoS, and privacy
>
> 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=40ericsson....@dmarc.ietf.org> 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.)
>
> I cannot find anything in the draft stating that “A proper client MUST
> NOT act on unauthorized information at any time”.
In this case we may need to state that. I presume the authors have
treated that as natural behavior of any networked station on the
Internet.
> This also raises the question why the unauthorized information is
> needed in the first place.
As explained at the end of my previous post it is needed if there is no
other discovery mechanism and to prevent the need to do a wks lookup
in case an unauthorized plain-text request failed with a 4.01.
>>> - 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.
The construction would be easy: coaps://as.hopkinsmedicine.org/authz-info.
Not trivial if you want to disguise the FQDN as well. There is a lot of
work on how to achieve this. See, e.g., [1] for a brief discussion and a
working solution [2].
I agree with you that this might be worth a paragraph in the Privacy
Considerations section.
[1] S. Stadler, S. Gerdes, O. Bergmann: Privacy-enhanced
Authenticationfor the Internet of Things. In: Proceedings of the
18. GI/ITG KuVS FachGespräch SensorNetze, FGSN 2019, Magdeburg,
Germany, p. 37—40. Available online
http://dx.doi.org/10.25673/28428, last access 2020-09-09.
[2] https://gitlab.informatik.uni-bremen.de/DCAF/dcaf/-/tree/abc
>>> 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”.
Which would be ill-worded. "Trust" is a useless term unless it is
specified to what extend someone relies on someone else to do
something. In this context this "trust" needs to be specified as: "The
client must be sure that the AS is authorized to issue access tokens for
RS to the client."
> 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”
I would translate "advisable" to SHOULD. For example, the client could
delegate the task of checking the AS's "trustwortyhness" (=
authorization to …) to a fourth party. In this case, the client would
not need that list.
Regarding the empty phrases "trust" and "trustworthy", please see above.
(And here, I agree with you that the use of "trustworthy" in the cited
sentence is plain wrong as it fails to indicate what that means.)
>>> 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.
This is indeed an imaginery requirement because no software (or
hardware) is able to check authorization. What happens today on the
Internet and what ACE tries to mimic for the Internet of Things is to
delegate authorization-related tasks to software. Here, the delegation
manifests itself by the user (vendor, sysadmin, …) telling the client
software: "These are the AS's I authorize to issue access tokens for the
following RS's."
Grüße
Olaf
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
