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

From: John Mattsson <[email-masked]>
Date: Wed, 9 Sep 2020 07:37:00 +0000

Hi,

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. 

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

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.

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.

Cheers,
John

---

From: Olaf Bergmann <[email-masked]>
Date: Wed, 09 Sep 2020 10:20:06 +0200

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=[email-masked]> writes:

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

---

From: John Mattsson <[email-masked]>
Date: Wed, 9 Sep 2020 09:36:31 +0000

Hi Olof,

Your reasoning does seem to be anchored in the draft. See inline.

The current state of the draft is not acceptable.

Grüße,
John Preuß Mattsson

-----Original Message-----
From: Olaf Bergmann <[email-masked]>
Date: Wednesday, 9 September 2020 at 10:20
To: John Mattsson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy

Hello John,

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

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

>that the client always needs to do, independent of the discovery

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”

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

Grüße
Olaf

---

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 9 Sep 2020 13:11:56 +0200

Hi John,

On 09/09/2020 11:36 AM, John Mattsson wrote:

<snip>

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

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.

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

> 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,…

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

---

From: Olaf Bergmann <[email-masked]>
Date: Wed, 09 Sep 2020 13:14:29 +0200

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

> Cc: "[email-masked]" <[email-masked]>,
> "[email-masked]"
> <[email-masked]>
> 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.

> 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

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

> 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

---

From: Jim Schaad <[email-masked]>
Date: Wed, 9 Sep 2020 15:11:28 -0700

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Stefanie Gerdes
Sent: Wednesday, September 9, 2020 4:12 AM
To: [email-masked]
Subject: Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy

Hi John,

<snip>

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

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 = 

[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

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

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

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
[email-masked]
https://www.ietf.org/mailman/listinfo/ace

---

From: Seitz Ludwig <[email-masked]>
Date: Thu, 10 Sep 2020 06:49:42 +0000

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

> From: Ace <[email-masked]> On Behalf Of Jim Schaad
> Sent: den 10 september 2020 00:11
> To: 'Stefanie Gerdes' <[email-masked]>; [email-masked]
> > 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.
> 
> 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.
> 
> 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.
> 
> >
> [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
> 
> 
> >>
> > 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.
> 
> 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:
> 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.
> 
> >
> > 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”
> >
> > 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.
> 
> 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.
> 
> retrieve the address. That RS sends the AS request creation hints with the
> error response is not mandatory.
> 
> Viele Grüße
> Steffi
>

---

From: Olaf Bergmann <[email-masked]>
Date: Thu, 10 Sep 2020 10:10:40 +0200

Seitz Ludwig <[email-masked]> writes:

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

The issue with options a and c is that they have the same privacy issues
as the current solution. And, of course, they need a way for C to
determine whether the used service (RD or DNS) is authorized to tell C
which AS is supposed to issue access tokens for RS. And after that, C
needs to check the very same things as before.

Option b) is what OAuth does (by presenting the login screen to the user
in front of the web browser). As said before, the current draft mimics
exactly that behavior. But as the client is assumed to act autonomously,
this client owner authorization process has been made upfront by
configuring authorized AS's.

Grüße
Olaf

---

From: Stefanie Gerdes <[email-masked]>
Date: Thu, 10 Sep 2020 14:10:25 +0200

Hi Jim,

comments inline.

> [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 i…

C may use the AS URI to determine if the AS is responsible for this
server, e.g., by looking it up in a secured resource directory that
contains the necessary information or by asking its own authorization
manager. As there may be large numbers of resource server that may
change a lot, it may be beneficial to also have the AS URI. That depends
on the client side authorization mechanism, of course. If C does not
require this information, it does not have to use it.

The unauthorized resource request mechanism has an additional purpose:
it also enables RS to specify a nonce that can later be reflected to it
in the access token and thereby enables RS to validate that the access
token is recent. It would be useful to make the AS address optional in
the AS request creation hints.

> [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 i…

Wouldn't the client breach the privacy of its owner simply by
communicating with an AS with such a URI?

I send a proposal to address this problem in my answer to John [1].

Viele Grüße
Steffi

[1] https://mailarchive.ietf.org/arch/msg/ace/0639BdkMvJZdUjLBJIX21EiSvbw/

---

From: Stefanie Gerdes <[email-masked]>
Date: Thu, 10 Sep 2020 14:10:46 +0200

Hi Ludwig,

comments inline.

> 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 m…

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

> 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

---

From: Stefanie Gerdes <[email-masked]>
Date: Thu, 10 Sep 2020 14:52:47 +0200

Hi all,

> hints, and we should make section 5.1.1 section 5.2.

Looking at section 5.1, I think that we would need to change the text in
there, too.

old:
In order to determine the AS in charge of a resource hosted at the RS, C
MAY send an initial Unauthorized Resource Request message to RS.  RS
then denies the request and sends the address of its AS back to C.

Instead of the initial Unauthorized Resource Request message, other
discovery methods may be used, or the client may be pre-provisioned
with an RS-to-AS mapping.

new:
C must discover the AS in charge of RS to determine where to request the
access token. To do so, C must 1. find out the AS URI to which the token
request message must be sent and 2. MUST validate that the AS with this
URI is authorized to provide access tokens for this RS.

In order to determine the AS URI, C MAY send an initial Unauthorized
Resource Request message to RS.  RS then denies the request and sends
the address of its AS back to C (see section 5.2). How C validates the
AS authorization is not in scope for this document. C may, e.g., ask
it's owner if this AS is authorized for this RS. C may also use a
mechanism that addresses both problems at once.

Viele Grüße
Steffi

---

From: Michael Richardson <[email-masked]>
Date: Thu, 10 Sep 2020 14:46:43 -0400

> 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

This is a hard problem.
  Q: "Who are you?"
  A: "Depends upon who is asking! Who are you?"
  A: "Depends upon who is asking! Who are you?"
  ...

The DNS-SD WG produced rfc8882, but as I understand it,
   https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-privacy-05
was abandonned because the WG did not see implementation/energy.
I can't seem to find the thread discussing that state.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael Richardson <[email-masked]>
Date: Thu, 10 Sep 2020 14:57:43 -0400

sg> A compromised RS may use the hints for attempting to trick a client
    sg> into contacting an AS that is not supposed to be in charge of that RS.
    sg> Therefore, C must not communicate with an AS if it cannot determine
    sg> that this AS has the authority to issue access tokens for this
    sg> RS. Otherwise, a compromised RS may use this to perform a denial of
    sg> service against a specific AS, by redirecting a large number of client
    sg> requests to that AS.

Jim Schaad <[email-masked]> wrote:
    > [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.

I was going to ask the same thing.
This is variation of the onboarding problem, but also it ignores how devices
got network access in the first place.

If C and RS share some trust in some nearby third party, then that party
could vouch.  I say "nearby", because having them both trust google or azure
or amazon doesn't help, because that anchor has no real knowledge about
whether RS or RS' is actually nearby.

RS' could be legitimately onboarded with "cloud", but just happens to be a
device "next door".   Or could it?

yes, in theory, but the question arises about how C and RS are communicating?
If one assumes that they are on the same L2, or different L2's managed by the
same L3, then there is a local third party.
In most cases, if RS' can spoof a response, it's because it is on the same
L2, having the same L2 security as C.

If C and RS are distant (you try to turn on your blood pressure sensor across
the Internet) then yes, it could wind up with the wrong sensor.

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

At which point, I wonder what the point of the AS is.

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

So, RS could answer with some less specific AS, that deals with who C is?
The, as it were, cloudflare of IoT?

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 15 Sep 2020 18:28:14 -0700

> I can't seem to find the thread discussing that state.

Interestingly, the corresponding requirements document was just published
recently as RFC 8882.

"A problem with no solution is a hard problem"...

-Ben

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Sep 2020 11:25:58 -0400

> "A problem with no solution is a hard problem"...

I thought Christian Huitema's solution, which I think is three or four years
old, was reasonable.  The WG just couldn't get reviews or people interested
in implementing.  Maybe ACE cares enough now.

---

From: Seitz Ludwig <[email-masked]>
Date: Thu, 17 Sep 2020 05:59:45 +0000

Hello John,

Steffi made some suggestions to improve the sections you criticized (see also https://github.com/ace-wg/ace-oauth/pull/177).

Do you think they address your issues?

Does the WG have an opinion on the way forward? (Chairs? Ads?)

/Ludwig

> Sent: den 10 september 2020 14:11
> To: [email-masked]
> 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?
> 
> 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].
> 
> >
> 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?
> >
> > 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.
> >
> > 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/
>