Re: [Ace] draft-ietf-ace-oauth-authz issue #179 / PR #180

[Daniel Migault]

great! Thanks!

Yours,
Daniel

From: Ace  on behalf of Göran Selander 

Sent: Thursday, February 4, 2021 3:37 AM
To: Daniel Migault ; Daniel 
Migault 
Cc: ace@ietf.org 
Subject: Re: [Ace] draft-ietf-ace-oauth-authz issue #179 / PR #180

Hi,

Now merged and submitted.

Göran

On 2021-02-03, 19:19, "Daniel Migault" 
 wrote:

Hi,

Just following up, I am wondering if the merge can be pushed this week.

Yours,
Daniel

From: Ace  on behalf of Daniel Migault 

Sent: Thursday, January 28, 2021 10:09 AM
To: Göran Selander 
Cc: ace@ietf.org 
Subject: Re: [Ace] draft-ietf-ace-oauth-authz issue #179 / PR #180

As we have not heard anyone opposed to the rewording I propose we proceed 
to the merge and publish a new version.
Yours,
Daniel


On Fri, Jan 15, 2021 at 3:35 AM Göran Selander 
 wrote:


Hi,

In the interim meeting yesterday I was requested to notify the ACE mailing 
list on this point:

Marco has commented that the term "overwrite" used once in 
draft-ietf-ace-oauth-authz should not be interpreted literally and it is 
proposed to be replaced with "supersede". More details in issue #179 / PR #180.


https://protect2.fireeye.com/v1/url?k=e38047ae-bc1b7eab-e3800735-86959e472243-8e4bfbc3d46c0e17=1=24bf59b1-c892-4c94-a540-ca5ff35613bd=https%3A%2F%2Fgithub.com%2Face-wg%2Face-oauth%2Fissues%2F179
 
<https://protect2.fireeye.com/v1/url?k=6c954d49-330e740a-6c950dd2-861fcb972bfc-3f900ad0dd6394aa=1=92c9ad59-1185-4cdd-b406-54be47152c48=https%3A%2F%2Fgithub.com%2Face-wg%2Face-oauth%2Fissues%2F179>

https://protect2.fireeye.com/v1/url?k=0f3baf69-50a0966c-0f3beff2-86959e472243-1d2a62f1c61eecfc=1=24bf59b1-c892-4c94-a540-ca5ff35613bd=https%3A%2F%2Fgithub.com%2Face-wg%2Face-oauth%2Fpull%2F180
 
<https://protect2.fireeye.com/v1/url?k=300264fd-6f995dbe-30022466-861fcb972bfc-fdbba8c4f7e4eb66=1=92c9ad59-1185-4cdd-b406-54be47152c48=https%3A%2F%2Fgithub.com%2Face-wg%2Face-oauth%2Fpull%2F180>

Unless there are any objections the PR will be merged soon.

Göran




___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace





--
Daniel Migault

Ericsson

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-oauth-authz issue #179 / PR #180

[Göran Selander]

Hi,

Now merged and submitted.

Göran

On 2021-02-03, 19:19, "Daniel Migault" 
 wrote:

Hi, 

Just following up, I am wondering if the merge can be pushed this week. 

Yours, 
Daniel

From: Ace  on behalf of Daniel Migault 

Sent: Thursday, January 28, 2021 10:09 AM
To: Göran Selander 
Cc: ace@ietf.org 
Subject: Re: [Ace] draft-ietf-ace-oauth-authz issue #179 / PR #180  

As we have not heard anyone opposed to the rewording I propose we proceed 
to the merge and publish a new version.  
Yours, 
Daniel


On Fri, Jan 15, 2021 at 3:35 AM Göran Selander 
 wrote:


Hi,

In the interim meeting yesterday I was requested to notify the ACE mailing 
list on this point: 

Marco has commented that the term "overwrite" used once in 
draft-ietf-ace-oauth-authz should not be interpreted literally and it is 
proposed to be replaced with "supersede". More details in issue #179 / PR #180.

https://github.com/ace-wg/ace-oauth/issues/179 
<https://protect2.fireeye.com/v1/url?k=6c954d49-330e740a-6c950dd2-861fcb972bfc-3f900ad0dd6394aa=1=92c9ad59-1185-4cdd-b406-54be47152c48=https%3A%2F%2Fgithub.com%2Face-wg%2Face-oauth%2Fissues%2F179>
https://github.com/ace-wg/ace-oauth/pull/180 
<https://protect2.fireeye.com/v1/url?k=300264fd-6f995dbe-30022466-861fcb972bfc-fdbba8c4f7e4eb66=1=92c9ad59-1185-4cdd-b406-54be47152c48=https%3A%2F%2Fgithub.com%2Face-wg%2Face-oauth%2Fpull%2F180>

Unless there are any objections the PR will be merged soon.

Göran




___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace





-- 
Daniel Migault

Ericsson

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-oauth-authz issue #179 / PR #180

[Daniel Migault]

Hi,

Just following up, I am wondering if the merge can be pushed this week.

Yours,
Daniel

From: Ace  on behalf of Daniel Migault 

Sent: Thursday, January 28, 2021 10:09 AM
To: Göran Selander 
Cc: ace@ietf.org 
Subject: Re: [Ace] draft-ietf-ace-oauth-authz issue #179 / PR #180

As we have not heard anyone opposed to the rewording I propose we proceed to 
the merge and publish a new version.

Yours,
Daniel

On Fri, Jan 15, 2021 at 3:35 AM Göran Selander 
mailto:40ericsson@dmarc.ietf.org>>
 wrote:
Hi,

In the interim meeting yesterday I was requested to notify the ACE mailing list 
on this point:

Marco has commented that the term "overwrite" used once in 
draft-ietf-ace-oauth-authz should not be interpreted literally and it is 
proposed to be replaced with "supersede". More details in issue #179 / PR #180.

https://github.com/ace-wg/ace-oauth/issues/179<https://protect2.fireeye.com/v1/url?k=6c954d49-330e740a-6c950dd2-861fcb972bfc-3f900ad0dd6394aa=1=92c9ad59-1185-4cdd-b406-54be47152c48=https%3A%2F%2Fgithub.com%2Face-wg%2Face-oauth%2Fissues%2F179>
https://github.com/ace-wg/ace-oauth/pull/180<https://protect2.fireeye.com/v1/url?k=300264fd-6f995dbe-30022466-861fcb972bfc-fdbba8c4f7e4eb66=1=92c9ad59-1185-4cdd-b406-54be47152c48=https%3A%2F%2Fgithub.com%2Face-wg%2Face-oauth%2Fpull%2F180>

Unless there are any objections the PR will be merged soon.

Göran




___
Ace mailing list
Ace@ietf.org<mailto:Ace@ietf.org>
https://www.ietf.org/mailman/listinfo/ace


--
Daniel Migault
Ericsson
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-oauth-authz issue #179 / PR #180

[Daniel Migault]

As we have not heard anyone opposed to the rewording I propose we proceed
to the merge and publish a new version.

Yours,
Daniel

On Fri, Jan 15, 2021 at 3:35 AM Göran Selander  wrote:

> Hi,
>
> In the interim meeting yesterday I was requested to notify the ACE mailing
> list on this point:
>
> Marco has commented that the term "overwrite" used once in
> draft-ietf-ace-oauth-authz should not be interpreted literally and it is
> proposed to be replaced with "supersede". More details in issue #179 / PR
> #180.
>
> https://github.com/ace-wg/ace-oauth/issues/179
> https://github.com/ace-wg/ace-oauth/pull/180
>
> Unless there are any objections the PR will be merged soon.
>
> Göran
>
>
>
>
> ___
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>


-- 
Daniel Migault
Ericsson
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] draft-ietf-ace-oauth-authz issue #179 / PR #180

[Göran Selander]

Hi,

In the interim meeting yesterday I was requested to notify the ACE mailing list 
on this point: 

Marco has commented that the term "overwrite" used once in 
draft-ietf-ace-oauth-authz should not be interpreted literally and it is 
proposed to be replaced with "supersede". More details in issue #179 / PR #180.

https://github.com/ace-wg/ace-oauth/issues/179
https://github.com/ace-wg/ace-oauth/pull/180

Unless there are any objections the PR will be merged soon.

Göran




___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Seitz Ludwig]

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


> -Original Message-
> From: Ace  On Behalf Of Stefanie Gerdes
> Sent: den 10 september 2020 14:11
> To: ace@ietf.org
> Subject: Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address,
> DoS, and privacy
> 
> Hi Ludwig,
> 
> comments inline.
> 
> On 09/10/2020 08:49 AM, Seitz Ludwig wrote:
> > 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?
> 
> 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].
> 
> >
> > 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.
> 
> 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/
> 
> ___
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Michael Richardson]

Benjamin Kaduk  wrote:
>> > 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.
>>
>> 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.

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

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

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Benjamin Kaduk]

On Thu, Sep 10, 2020 at 02:46:43PM -0400, Michael Richardson wrote:
> 
> John Mattsson  wrote:
> > - 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.
> 
> 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.

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

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

-Ben

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Michael Richardson]

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

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

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?

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Michael Richardson]

John Mattsson  wrote:
> - 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.

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. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Stefanie Gerdes]

Hi all,

On 09/10/2020 02:10 PM, Stefanie Gerdes wrote:

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

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

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Stefanie Gerdes]

Hi Ludwig,

comments inline.

On 09/10/2020 08:49 AM, Seitz Ludwig wrote:
> 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?

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

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

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/

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Stefanie Gerdes]

Hi Jim,

comments inline.

On 09/10/2020 12:11 AM, Jim Schaad wrote:

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

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.

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

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/

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Olaf Bergmann]

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

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

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Seitz Ludwig]

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  On Behalf Of Jim Schaad
> Sent: den 10 september 2020 00:11
> To: 'Stefanie Gerdes' ; ace@ietf.org
> Subject: Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address,
> DoS, and privacy
> 
> 
> 
> -Original Message-
> From: Ace  On Behalf Of Stefanie Gerdes
> Sent: Wednesday, September 9, 2020 4:12 AM
> To: ace@ietf.org
> 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:
> 
> 
> 
> >>> 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 R

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

[Jim Schaad]

-Original Message-
From: Ace  On Behalf Of Stefanie Gerdes
Sent: Wednesday, September 9, 2020 4:12 AM
To: ace@ietf.org
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:



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

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

[Olaf Bergmann]

John Mattsson  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 
> Date: Wednesday, 9 September 2020 at 10:20
> To: John Mattsson 
> Cc: "ace@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  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

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

[Stefanie Gerdes]

Hi John,

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



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

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

[John Mattsson]

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 
Date: Wednesday, 9 September 2020 at 10:20
To: John Mattsson 
Cc: "ace@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  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”. This also raises the question why the 
unauthorized information is needed in the first place.

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

Grüße
Olaf

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Olaf Bergmann]

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

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[John Mattsson]

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

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-oauth-authz

[Michael Richardson]

Carsten Bormann  wrote:
>> I don't see how the four-corner model solves the issue that I
>> highlighted.  If the client does not have a key for any local AS, then
>> nothing helps.  The four-corner model deals with the issue of the
>> client and the RS not trusting the same AS, but the different AS
>> entities trust each other on the back side.
>>
>> Getting trust in a local AS seems to be a bootstrapping problem.

> If you only have one security domain, there is no benefit.  But in
> general is it much easier to bootstrap a device once into its own
> security domain, instead of having to do the bootstrapping again and
> again for each server that device needs to access.

That was my understanding.

The four corner removes the problem of how C trusts RS to a problem of how
does C ask CAS whether it can trust RS.  Which could involve significant
layers of PKI or human override (or pixie dust).


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-oauth-authz

[Carsten Bormann]

On 2020-05-05, at 17:39, Jim Schaad  wrote:
> 
> I don't see how the four-corner model solves the issue that I highlighted.  
> If the client does not have a key for any local AS, then nothing helps.  The 
> four-corner model deals with the issue of the client and the RS not trusting 
> the same AS, but the different AS entities trust each other on the back side.
> 
> Getting trust in a local AS seems to be a bootstrapping problem.

If you only have one security domain, there is no benefit.
But in general is it much easier to bootstrap a device once into its own 
security domain, instead of having to do the bootstrapping again and again for 
each server that device needs to access.

Grüße, Carsten


> 
> Jim
> 
> 
> -Original Message-
> From: Carsten Bormann  
> Sent: Monday, May 4, 2020 10:38 PM
> To: Jim Schaad 
> Cc: Benjamin Kaduk ; Olaf Bergmann ; Peter 
> van der Stok ; peter van der Stok 
> ; Ace 
> Subject: Re: [Ace] draft-ietf-ace-oauth-authz
> 
> On 2020-05-05, at 06:54, Jim Schaad  wrote:
>> 
>> I have much the same problem.  While a client could find an AS which 
>> would authenticate the client, I don't know how the client would 
>> establish any degree of trust in the AS which is going to give it tokens.
> 
> Hence the four-corner model [1].
> 
> Grüße, Carsten
> 
> [1]: https://tools.ietf.org/html/draft-ietf-ace-actors
> 

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-oauth-authz

[Jim Schaad]

-Original Message-
From: Michael Richardson  
Sent: Tuesday, May 5, 2020 11:07 AM
To: Jim Schaad ; 'Ace' 
Subject: Re: [Ace] draft-ietf-ace-oauth-authz


Jim Schaad  wrote:
> I have much the same problem.  While a client could find an AS which
> would authenticate the client, I don't know how the client would
> establish any degree of trust in the AS which is going to give it
> tokens.

Is your question that you don't know how to trust that the AS is the correct
AS for RS-foo?

[JLS] No, my question is how do I know to trust the AS period.  I don't have
a key to establish a secure session with the AS.  I guess doing full X.509
certificate processing would be an answer, but that could be difficult in
the event of a key compromise.

> If you have already put a local public key for the AS into the
> client, then you might as well put in a name for the AS as well.  I
> suppose you could get by with a shared secret but that does not seem
to
> be a good way to build up the system.

Maybe there are redundant instances of the AS, or maybe there are multiple
ways (thus different IP addresses) by which to reach the AS.
[JLS] It could be that there are redundant instances of the AS, but then you
have the problem of either doing key sharing between all of them or needing
the ability to validate the key assigned to each of them.  If you have
different addresses, that might be interesting, but you are going to need to
do trial connections to each possible AS found until you get one that works.

Jim



--
Michael Richardson , Sandelman Software Works  -=
IPv6 IoT consulting =-




___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-oauth-authz

[Michael Richardson]

Jim Schaad  wrote:
> I have much the same problem.  While a client could find an AS which
> would authenticate the client, I don't know how the client would
> establish any degree of trust in the AS which is going to give it
> tokens.

Is your question that you don't know how to trust that the AS is the correct
AS for RS-foo?

> If you have already put a local public key for the AS into the
> client, then you might as well put in a name for the AS as well.  I
> suppose you could get by with a shared secret but that does not seem to
> be a good way to build up the system.

Maybe there are redundant instances of the AS, or maybe there are multiple ways
(thus different IP addresses) by which to reach the AS.


-- 
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-oauth-authz

[Peter van der Stok]

HI Jim,

Agree.
That's a new draft then with an rt value for a given upload protocol.

Peter
Jim Schaad schreef op 2020-05-05 17:43:





Thanks Peter, that makes things a lot clearer.  However I think that you are not asking for who is an AS, but who is an AS that has a particular interface.  It would make more sense to define a new interface identifier for the upload/control protocol rather than just identifying who is an AS. 

Jim 


From: Ace  On Behalf Of Peter van der Stok
Sent: Tuesday, May 5, 2020 12:26 AM
To: Benjamin Kaduk 
Cc: Jim Schaad ; Olaf Bergmann ; 'Ace' 

Subject: Re: [Ace] draft-ietf-ace-oauth-authz 


HI all,

I agree about the authorization/trust problem.
My request concerns something more trivial.

Suppose we have this new network with a set of servers, an (AS) (may be more) 
and a controller.
The servers, controller and AS may have used BRSKI to enter the network.
The servers will only provide their service when a token has been sent.
The AS is completely empty, not aware of the servers or its clients.
The controller wants to fill the AS with the necessary information.

Both controller and AS have agreed on an initialization protocol, and are 
equipped with the necessary secrets. (A protocol to be standardized in general, 
but not my concen here)

Now, what IP address does the controller use to start the communication?

Typing in the IP address is a possibility, switching off all other devices is 
another, etc...
I hoped that a coap discovery could be used such that the controller learns the 
IP address of the AS.

When several AS servers are present, the controller can access each one of them 
out till it accesses the AS with the correct credentials.

I hope my request has become a bit clearer.

Peter

Benjamin Kaduk schreef op 2020-05-05 06:09: 

On Mon, May 04, 2020 at 09:21:06AM +0200, Olaf Bergmann wrote: 


Hi Peter,

Peter van der Stok  writes:

When I want to access an OCF device I can find its IP address through
service discovery (rfc7252 section 7) using an rt-value registered at
the IANA core parameters registry.  For example, when I want to
initialize the AS I have to type in the IP address of the AS.  From
that moment on keys and certificates can be compared to continue
initialization.

Using service discovery can automate that process.

My request is that authz draft registers an rt-value in core
parameters registry for service discovery of the AS, unless a
different process has already been established for AS initialization. 


That is exaclty what originally has been done in section 9 of
draft-gerdes-ace-dcaf-authorize [1]. Somehow, this got lost in the
process.


I think I'm still a little confused as to what good being able to
"discover" that the network says something is an AS is, without some
prior
trust and/or key material for that AS.  How would the necessary trust be
established as part of such a discovery scheme?

Thanks,

Ben___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-oauth-authz

[Jim Schaad]

Thanks Peter, that makes things a lot clearer.  However I think that you are 
not asking for who is an AS, but who is an AS that has a particular interface.  
It would make more sense to define a new interface identifier for the 
upload/control protocol rather than just identifying who is an AS.

 

Jim

 

 

From: Ace  On Behalf Of Peter van der Stok
Sent: Tuesday, May 5, 2020 12:26 AM
To: Benjamin Kaduk 
Cc: Jim Schaad ; Olaf Bergmann ; 
'Ace' 
Subject: Re: [Ace] draft-ietf-ace-oauth-authz

 

HI all,

I agree about the authorization/trust problem.
My request concerns something more trivial.

Suppose we have this new network with a set of servers, an (AS) (may be more) 
and a controller.
The servers, controller and AS may have used BRSKI to enter the network.
The servers will only provide their service when a token has been sent.
The AS is completely empty, not aware of the servers or its clients.
The controller wants to fill the AS with the necessary information.

Both controller and AS have agreed on an initialization protocol, and are 
equipped with the necessary secrets. (A protocol to be standardized in general, 
but not my concen here)

Now, what IP address does the controller use to start the communication?

Typing in the IP address is a possibility, switching off all other devices is 
another, etc...
I hoped that a coap discovery could be used such that the controller learns the 
IP address of the AS.

When several AS servers are present, the controller can access each one of them 
out till it accesses the AS with the correct credentials.

I hope my request has become a bit clearer.

Peter



Benjamin Kaduk schreef op 2020-05-05 06:09:

On Mon, May 04, 2020 at 09:21:06AM +0200, Olaf Bergmann wrote: 

Hi Peter,

Peter van der Stok mailto:stokc...@bbhmail.nl> > writes:




When I want to access an OCF device I can find its IP address through
service discovery (rfc7252 section 7) using an rt-value registered at
the IANA core parameters registry.  For example, when I want to
initialize the AS I have to type in the IP address of the AS.  From
that moment on keys and certificates can be compared to continue
initialization.

Using service discovery can automate that process.

My request is that authz draft registers an rt-value in core
parameters registry for service discovery of the AS, unless a
different process has already been established for AS initialization.


That is exaclty what originally has been done in section 9 of
draft-gerdes-ace-dcaf-authorize [1]. Somehow, this got lost in the
process.


I think I'm still a little confused as to what good being able to
"discover" that the network says something is an AS is, without some prior
trust and/or key material for that AS.  How would the necessary trust be
established as part of such a discovery scheme?

Thanks,

Ben

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-oauth-authz

[Jim Schaad]

I don't see how the four-corner model solves the issue that I highlighted.  If 
the client does not have a key for any local AS, then nothing helps.  The 
four-corner model deals with the issue of the client and the RS not trusting 
the same AS, but the different AS entities trust each other on the back side.

Getting trust in a local AS seems to be a bootstrapping problem.

Jim


-Original Message-
From: Carsten Bormann  
Sent: Monday, May 4, 2020 10:38 PM
To: Jim Schaad 
Cc: Benjamin Kaduk ; Olaf Bergmann ; Peter van 
der Stok ; peter van der Stok 
; Ace 
Subject: Re: [Ace] draft-ietf-ace-oauth-authz

On 2020-05-05, at 06:54, Jim Schaad  wrote:
> 
> I have much the same problem.  While a client could find an AS which 
> would authenticate the client, I don't know how the client would 
> establish any degree of trust in the AS which is going to give it tokens.

Hence the four-corner model [1].

Grüße, Carsten

[1]: https://tools.ietf.org/html/draft-ietf-ace-actors

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-oauth-authz

[Peter van der Stok]

HI all,

I agree about the authorization/trust problem.
My request concerns something more trivial.

Suppose we have this new network with a set of servers, an (AS) (may be
more) and a controller.
The servers, controller and AS may have used BRSKI to enter the network.
The servers will only provide their service when a token has been sent.
The AS is completely empty, not aware of the servers or its clients.
The controller wants to fill the AS with the necessary information.

Both controller and AS have agreed on an initialization protocol, and
are equipped with the necessary secrets. (A protocol to be standardized
in general, but not my concen here)

Now, what IP address does the controller use to start the communication?

Typing in the IP address is a possibility, switching off all other
devices is another, etc...
I hoped that a coap discovery could be used such that the controller
learns the IP address of the AS.

When several AS servers are present, the controller can access each one
of them out till it accesses the AS with the correct credentials.

I hope my request has become a bit clearer.

Peter
Benjamin Kaduk schreef op 2020-05-05 06:09:


On Mon, May 04, 2020 at 09:21:06AM +0200, Olaf Bergmann wrote: Hi Peter,

Peter van der Stok  writes:

When I want to access an OCF device I can find its IP address through
service discovery (rfc7252 section 7) using an rt-value registered at
the IANA core parameters registry.  For example, when I want to
initialize the AS I have to type in the IP address of the AS.  From
that moment on keys and certificates can be compared to continue
initialization.

Using service discovery can automate that process.

My request is that authz draft registers an rt-value in core
parameters registry for service discovery of the AS, unless a
different process has already been established for AS initialization. 
That is exaclty what originally has been done in section 9 of

draft-gerdes-ace-dcaf-authorize [1]. Somehow, this got lost in the
process.


I think I'm still a little confused as to what good being able to
"discover" that the network says something is an AS is, without some
prior
trust and/or key material for that AS.  How would the necessary trust be
established as part of such a discovery scheme?

Thanks,

Ben___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-oauth-authz

[Carsten Bormann]

On 2020-05-05, at 06:54, Jim Schaad  wrote:
> 
> I have much the same problem.  While a client could find an AS which would
> authenticate the client, I don't know how the client would establish any
> degree of trust in the AS which is going to give it tokens.  

Hence the four-corner model [1].

Grüße, Carsten

[1]: https://tools.ietf.org/html/draft-ietf-ace-actors

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-oauth-authz

[Jim Schaad]

I have much the same problem.  While a client could find an AS which would
authenticate the client, I don't know how the client would establish any
degree of trust in the AS which is going to give it tokens.  If you have
already put a local public key for the AS into the client, then you might as
well put in a name for the AS as well.  I suppose you could get by with a
shared secret but that does not seem to be a good way to build up the
system.

Jim


-Original Message-
From: Benjamin Kaduk  
Sent: Monday, May 4, 2020 9:09 PM
To: Olaf Bergmann 
Cc: Peter van der Stok ; Jim Schaad
; consulta...@vanderstok.org; 'Ace' 
Subject: Re: [Ace] draft-ietf-ace-oauth-authz

On Mon, May 04, 2020 at 09:21:06AM +0200, Olaf Bergmann wrote:
> Hi Peter,
> 
> Peter van der Stok  writes:
> 
> > When I want to access an OCF device I can find its IP address 
> > through service discovery (rfc7252 section 7) using an rt-value 
> > registered at the IANA core parameters registry.  For example, when 
> > I want to initialize the AS I have to type in the IP address of the 
> > AS.  From that moment on keys and certificates can be compared to 
> > continue initialization.
> >
> > Using service discovery can automate that process.
> >
> > My request is that authz draft registers an rt-value in core 
> > parameters registry for service discovery of the AS, unless a 
> > different process has already been established for AS initialization.
> 
> That is exaclty what originally has been done in section 9 of 
> draft-gerdes-ace-dcaf-authorize [1]. Somehow, this got lost in the 
> process.

I think I'm still a little confused as to what good being able to "discover"
that the network says something is an AS is, without some prior trust and/or
key material for that AS.  How would the necessary trust be established as
part of such a discovery scheme?

Thanks,

Ben

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-oauth-authz

[Seitz Ludwig]

Peter,

Why not document what you invent in a draft? To me it would be a good starting 
point.

/Ludwig

From: Peter van der Stok 
Sent: den 4 maj 2020 09:15
To: Carsten Bormann 
Cc: Seitz Ludwig ; Jim Schaad 
; peter van der Stok ; Ace 

Subject: Re: [Ace] draft-ietf-ace-oauth-authz

Hi Carsten,

The imagination will not have finished its work in 10 yeras time if coap and 
the authorization will enjoy the success they merit.
Also I don't see anybody being ready to start such  a document the coming month.
Do you see another document in which a first set of these registrations can be 
added?

FYI, today I do my iplementation and (to my regret) will invent something of my 
own.

cheerio,

Peter


Carsten Bormann schreef op 2020-05-04 08:51:
On 2020-05-04, at 08:42, Seitz Ludwig 
mailto:ludwig.se...@combitech.se>> wrote:

For the sake of getting the document finished before I die of old age ;-) would 
it be possible to specify this in a separate document?

I think there may be multiple of these RT registrations, because the fact that 
a resource is part of an AS is only part of the information that is needed: The 
RT could tell us more about the way the AS wants to be used.

I think that is a strong argument to *not* do these RT registrations in the 
framework, because we will not have enough imagination to catch them all.

So my recommendation would indeed be a separate document.

Grüße, Carsten

___
Ace mailing list
Ace@ietf.org<mailto:Ace@ietf.org>
https://www.ietf.org/mailman/listinfo/ace
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-oauth-authz

[Olaf Bergmann]

Hi Peter,

Peter van der Stok  writes:

> When I want to access an OCF device I can find its IP address through
> service discovery (rfc7252 section 7) using an rt-value registered at
> the IANA core parameters registry.  For example, when I want to
> initialize the AS I have to type in the IP address of the AS.  From
> that moment on keys and certificates can be compared to continue
> initialization.
>
> Using service discovery can automate that process.
>
> My request is that authz draft registers an rt-value in core
> parameters registry for service discovery of the AS, unless a
> different process has already been established for AS initialization.

That is exaclty what originally has been done in section 9 of
draft-gerdes-ace-dcaf-authorize [1]. Somehow, this got lost in the
process.

[1] https://tools.ietf.org/html/draft-gerdes-ace-dcaf-authorize-04#page-30


Grüße
Olaf

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-oauth-authz

[Peter van der Stok]

Hi Carsten,

The imagination will not have finished its work in 10 yeras time if coap
and the authorization will enjoy the success they merit.
Also I don't see anybody being ready to start such  a document the
coming month.
Do you see another document in which a first set of these registrations
can be added?

FYI, today I do my iplementation and (to my regret) will invent
something of my own. 


cheerio,

Peter
Carsten Bormann schreef op 2020-05-04 08:51:

On 2020-05-04, at 08:42, Seitz Ludwig  wrote: 


For the sake of getting the document finished before I die of old age ;-) would 
it be possible to specify this in a separate document?


I think there may be multiple of these RT registrations, because the fact that 
a resource is part of an AS is only part of the information that is needed: The 
RT could tell us more about the way the AS wants to be used.

I think that is a strong argument to *not* do these RT registrations in the 
framework, because we will not have enough imagination to catch them all.

So my recommendation would indeed be a separate document.

Grüße, Carsten

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-oauth-authz

[Carsten Bormann]

On 2020-05-04, at 08:42, Seitz Ludwig  wrote:
> 
> For the sake of getting the document finished before I die of old age ;-) 
> would it be possible to specify this in a separate document?

I think there may be multiple of these RT registrations, because the fact that 
a resource is part of an AS is only part of the information that is needed: The 
RT could tell us more about the way the AS wants to be used.

I think that is a strong argument to *not* do these RT registrations in the 
framework, because we will not have enough imagination to catch them all.

So my recommendation would indeed be a separate document.

Grüße, Carsten

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-oauth-authz

[Seitz Ludwig]

For the sake of getting the document finished before I die of old age ;-) would 
it be possible to specify this in a separate document?

/Ludwig

From: Ace  On Behalf Of Peter van der Stok
Sent: den 1 maj 2020 08:56
To: Jim Schaad 
Cc: consulta...@vanderstok.org; 'Ace' 
Subject: Re: [Ace] draft-ietf-ace-oauth-authz

HI Jim,

I try to answer your question,

When I want to access an OCF device I can find its IP address through service 
discovery (rfc7252 section 7) using an rt-value registered at the IANA core 
parameters registry.
For example, when I want to initialize the AS I have to type in the IP address 
of the AS.
From that moment on keys and certificates can be compared to continue 
initialization.

Using service discovery can automate that process.

My request is that authz draft registers an rt-value in core parameters 
registry for service discovery of the AS,
unless a different process has already been established for AS initialization.

Many thanks,

peter


Jim Schaad schreef op 2020-04-30 17:25:


What do you expect to see?   By default a client needs to know that something 
is an AS and have a key to interact with that AS.



Jim





From: Ace mailto:ace-boun...@ietf.org>> On Behalf Of 
Peter van der Stok
Sent: Wednesday, April 29, 2020 11:57 PM
To: Ace mailto:ace@ietf.org>>
Subject: [Ace] draft-ietf-ace-oauth-authz



Hi authz authors,,

While implementing a version of AS, I noticed that there is no resource type 
(rt) registered for /.well-known/core discovery.
Is this voluntary?
If not, can it still be added?

thanks,

peter

--

Peter van der Stok
vanderstok consultancy
mailto: consulta...@vanderstok.org<mailto:consulta...@vanderstok.org>, 
stokc...@bbhmail.nl<mailto:stokc...@bbhmail.nl>
www: www.vanderstok.org<http://www.vanderstok.org>
tel NL: +31(0)492474673 F: +33(0)966015248

___
Ace mailing list
Ace@ietf.org<mailto:Ace@ietf.org>
https://www.ietf.org/mailman/listinfo/ace
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-oauth-authz

[Peter van der Stok]

HI Jim,

I try to answer your question,

When I want to access an OCF device I can find its IP address through
service discovery (rfc7252 section 7) using an rt-value registered at
the IANA core parameters registry.
For example, when I want to initialize the AS I have to type in the IP
address of the AS.

From that moment on keys and certificates can be compared to continue

initialization.

Using service discovery can automate that process.

My request is that authz draft registers an rt-value in core parameters
registry for service discovery of the AS,
unless a different process has already been established for AS
initialization.

Many thanks,

peter
Jim Schaad schreef op 2020-04-30 17:25:





What do you expect to see?   By default a client needs to know that something is an AS and have a key to interact with that AS. 

Jim 


From: Ace  On Behalf Of Peter van der Stok
Sent: Wednesday, April 29, 2020 11:57 PM
To: Ace 
Subject: [Ace] draft-ietf-ace-oauth-authz 


Hi authz authors,,

While implementing a version of AS, I noticed that there is no resource type 
(rt) registered for /.well-known/core discovery.
Is this voluntary?
If not, can it still be added?

thanks,

peter 


--

Peter van der Stok
vanderstok consultancy
mailto: consulta...@vanderstok.org, stokc...@bbhmail.nl
www: www.vanderstok.org [1]
tel NL: +31(0)492474673 F: +33(0)966015248 
___

Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace



Links:
--
[1] http://www.vanderstok.org___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-oauth-authz

[Jim Schaad]

What do you expect to see?   By default a client needs to know that something 
is an AS and have a key to interact with that AS.

 

Jim

 

 

From: Ace  On Behalf Of Peter van der Stok
Sent: Wednesday, April 29, 2020 11:57 PM
To: Ace 
Subject: [Ace] draft-ietf-ace-oauth-authz

 

Hi authz authors,,

While implementing a version of AS, I noticed that there is no resource type 
(rt) registered for /.well-known/core discovery.
Is this voluntary?
If not, can it still be added?

thanks,

peter 

-- 

Peter van der Stok
vanderstok consultancy
mailto: consulta...@vanderstok.org <mailto:consulta...@vanderstok.org> , 
stokc...@bbhmail.nl <mailto:stokc...@bbhmail.nl> 
www: www.vanderstok.org <http://www.vanderstok.org> 
tel NL: +31(0)492474673 F: +33(0)966015248

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] draft-ietf-ace-oauth-authz

[Peter van der Stok]

Hi authz authors,,

While implementing a version of AS, I noticed that there is no resource
type (rt) registered for /.well-known/core discovery.
Is this voluntary?
If not, can it still be added?

thanks,

peter 
--

Peter van der Stok
vanderstok consultancy
mailto: consulta...@vanderstok.org, stokc...@bbhmail.nl
www: www.vanderstok.org [1]
tel NL: +31(0)492474673 F: +33(0)966015248 


Links:
--
[1] http://www.vanderstok.org___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-oauth-authz

[Ludwig Seitz]

On 26/02/2019 17:54, Jim Schaad wrote:




3. In section 8.3 - Is/Should there be a requirement that the
error also be registered in an OAuth registry?  If so then this
needs to be part of the expert reviewer instructions on this
registry.


The expert reviewer instructions already state this:

"Since a high degree of overlap is expected between these
registries and the contents of the OAuth parameters registries,
experts should require new registrations to maintain a reasonable
level of alignment with parameters from OAuth that have comparable
functionality."

This includes the error registry, do you think this is
sufficiently clear or should I elaborate?


The question I had was the difference between SHOULD and MUST be
registered.  The text there says - try and keep them in sync, but if
they are not it is not a problem.   If that is what you want then
this is not a problem, I was just validating this.


The intention of the "should require ... a reasonable level of
alignment" was "try and keep them in sync, but if they are not you need
a good reason for this".

Your alternate interpretation makes me think the text is not worded
strongly enough.


I think that this is basically the same thing.   The only thing that you might 
want to add is some guidance on what constitutes a good reason.


Ok how about this:

"... experts should require new registrations to maintain alignment with 
parameters from OAuth that have comparable functionality.  Deviation 
from this alignment should only be allowed if there are functional 
differences, that are motivated by the use case and that cannot be 
easily or efficiently addressed by comparable OAuth parameters."







4. In section 8.4 - Is there a reason to require a specification
for this registry?  Should it be sufficient to have somebody
request that a mapping be registered and the DE approves it?  The
previous comment would apply

to

all of the mapping registries that are just mappings.


The idea is to prevent the squatting of low byte count
abbreviations by parameters that are not frequently used, thus
there is a range of different policies for different integer
abbreviation number ranges. (note: I'm following the example of the
CWT specification here)


Not requiring a document to exists could still allow this.  IANA
would still have the DE approve the assignment.



Ok so you mean not having "specification required" for -65536 to -257
and 256 to 65535 and not having "standards action" for -256 to 255 would
be ok?

Note that this would be different from the policy in RFC 8392 (CWT).


Yes I understand that this is different from CWT.  When looking at the 
registries you basically would write a specification which contains the 
following text:

If, for example , in section 8.4 it was already registered in the OAuth 
registry, then the document would boil down to:

Please assign a number in the "OAuth Grant Type CBOR Mappings" registry with 
the following properties:
Name:  grant_type_name
CBOR Value: TBD
Reference: [This document]
Original Specification: [The document for grant_type_name] in the "OAuth Grant 
Type" registry.

This seems like it is really overkill to have to produce a full specification with of one 
page when an email to IANA would seem to have the same info.   If you were defining a new 
grant type, then a full spec would be useful but it would also be expected to do the 
registration in the "OAuth Grant Type" registry as well as in this registry.



Ok now I get what you were going for. Sorry for the slow uptake, and you 
are indeed right. I will go through the mapping IANA sections and redue 
the applicable policies to "expert review required" and "private use" 
based on the number ranges.


/Ludwig


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



smime.p7s
Description: S/MIME Cryptographic Signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-oauth-authz

[Ludwig Seitz]

On 25/02/2019 18:08, Jim Schaad wrote:


3. In section 8.3 - Is/Should there be a requirement that the
error also be registered in an OAuth registry?  If so then this
needs to be part of the expert reviewer instructions on this
registry.


The expert reviewer instructions already state this:

"Since a high degree of overlap is expected between these
registries and the contents of the OAuth parameters registries,
experts should require new registrations to maintain a reasonable
level of alignment with parameters from OAuth that have comparable
functionality."

This includes the error registry, do you think this is
sufficiently clear or should I elaborate?


The question I had was the difference between SHOULD and MUST be
registered.  The text there says - try and keep them in sync, but if
they are not it is not a problem.   If that is what you want then
this is not a problem, I was just validating this.


The intention of the "should require ... a reasonable level of
alignment" was "try and keep them in sync, but if they are not you need
a good reason for this".

Your alternate interpretation makes me think the text is not worded
strongly enough.







4. In section 8.4 - Is there a reason to require a specification
for this registry?  Should it be sufficient to have somebody
request that a mapping be registered and the DE approves it?  The
previous comment would apply

to

all of the mapping registries that are just mappings.


The idea is to prevent the squatting of low byte count
abbreviations by parameters that are not frequently used, thus
there is a range of different policies for different integer
abbreviation number ranges. (note: I'm following the example of the
CWT specification here)


Not requiring a document to exists could still allow this.  IANA
would still have the DE approve the assignment.



Ok so you mean not having "specification required" for -65536 to -257 
and 256 to 65535 and not having "standards action" for -256 to 255 would 
be ok?


Note that this would be different from the policy in RFC 8392 (CWT).

/Ludwig


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



smime.p7s
Description: S/MIME Cryptographic Signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-oauth-authz

[Jim Schaad]

> -Original Message-
> From: Ludwig Seitz 
> Sent: Monday, February 25, 2019 6:21 AM
> To: Jim Schaad ; draft-ietf-ace-oauth-
> au...@ietf.org
> Cc: 'ace' 
> Subject: Re: draft-ietf-ace-oauth-authz
> 
> On 24/02/2019 01:13, Jim Schaad wrote:


> > 3. In section 8.3 - Is/Should there be a requirement that the error also be
> > registered in an OAuth registry?  If so then this needs to be part of the
> > expert reviewer instructions on this registry.
> 
> The expert reviewer instructions already state this:
> 
> "Since a high degree of overlap is expected between these registries
>   and the contents of the OAuth parameters registries, experts should
> require new registrations to maintain a reasonable level of alignment
> with parameters from OAuth that have comparable functionality."
> 
> This includes the error registry, do you think this is sufficiently
> clear or should I elaborate?

The question I had was the difference between SHOULD and MUST be registered.  
The text there says - try and keep them in sync, but if they are not it is not 
a problem.   If that is what you want then this is not a problem, I was just 
validating this.

> 
> >
> > 4. In section 8.4 - Is there a reason to require a specification for this
> > registry?  Should it be sufficient to have somebody request that a mapping
> > be registered and the DE approves it?  The previous comment would apply
> to
> > all of the mapping registries that are just mappings.
> >
> The idea is to prevent the squatting of low byte count abbreviations by
> parameters that are not frequently used, thus there is a range of
> different policies for different integer abbreviation number ranges.
> (note: I'm following the example of the CWT specification here)

Not requiring a document to exists could still allow this.  IANA would still 
have the DE approve the assignment.

> >
> > 6. In section 8.9 - see comments of section 8.3 and 8.4
> >
> > 7.  In section 8.11 - see comments of section 8.3 and 8.4
> >
> See above
> 
> 
> > 8.  This document has an IPR disclosure on it.   If anybody has any problems
> > with the current disclosure then they need to speak up now.
> 
> Processing ...
> 
> The changes are currently only in the github version, I will upload a
> new version of the draft soon.
> 
> /Ludwig
> 
> --
> Ludwig Seitz, PhD
> Security Lab, RISE
> Phone +46(0)70-349 92 51


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-oauth-authz

[Ludwig Seitz]

On 24/02/2019 01:13, Jim Schaad wrote:

1.  Figure 4 needs to be updated as it no longer matches Figure 3.


Fixed


2. In section 8.2 - Should he error usage location match any of the current
values in the table.   Possibly "authorization server response"

Fixed, I made that "token error response" as one of the specified 
locations in RFC 6749 11.4.1.


(side note: The OpenID and Kantara IANA registrations apparently missed 
the limited range of values specified for this field and used custom 
location descriptions).



3. In section 8.3 - Is/Should there be a requirement that the error also be
registered in an OAuth registry?  If so then this needs to be part of the
expert reviewer instructions on this registry.


The expert reviewer instructions already state this:

"Since a high degree of overlap is expected between these registries 
 and the contents of the OAuth parameters registries, experts should 
require new registrations to maintain a reasonable level of alignment 
with parameters from OAuth that have comparable functionality."


This includes the error registry, do you think this is sufficiently 
clear or should I elaborate?




4. In section 8.4 - Is there a reason to require a specification for this
registry?  Should it be sufficient to have somebody request that a mapping
be registered and the DE approves it?  The previous comment would apply to
all of the mapping registries that are just mappings.

The idea is to prevent the squatting of low byte count abbreviations by 
parameters that are not frequently used, thus there is a range of 
different policies for different integer abbreviation number ranges.

(note: I'm following the example of the CWT specification here)


5. In section 8.5 - You are missing two fields of the registration template.
Specifically should the expiration time field be noted in the "Additional
Token Endpoint Response Parameters" column.

Fixed



6. In section 8.9 - see comments of section 8.3 and 8.4

7.  In section 8.11 - see comments of section 8.3 and 8.4


See above



8.  This document has an IPR disclosure on it.   If anybody has any problems
with the current disclosure then they need to speak up now.


Processing ...

The changes are currently only in the github version, I will upload a 
new version of the draft soon.


/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



smime.p7s
Description: S/MIME Cryptographic Signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark

[Hannes Tschofenig]

Hi Carsten,

OAuth defined something called "Dynamic Client Registration", which gives you 
an idea what type of information is typically needed. Here is the RFC: 
https://tools.ietf.org/html/rfc7591

Regarding "initial integration of a device into a network only" isn't this 
sometimes called "network access authentication"?

In any case, I agree with you that we should add some text about what 
information is assumed to be present.

Ciao
Hannes

-Original Message-
From: Carsten Bormann [mailto:c...@tzi.org]
Sent: 20 February 2018 19:05
To: Hannes Tschofenig
Cc: Michael Richardson; Ludwig Seitz; ace@ietf.org
Subject: Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in 
the dark

On Feb 20, 2018, at 08:43, Hannes Tschofenig <hannes.tschofe...@arm.com> wrote:
>
> IMHO the biggest problem with "onboarding" is that people create new terms 
> without specifying what they actually mean and thereby fail to see the 
> relationship with existing work.

Right.  I have no idea what client registration has to do with “onboarding”, 
but I use that term for the initial integration of a device into a network only.

I continue to believe that we need a clear understanding of what information is 
exchanged during client registration that is relevant to the ACE OAuth.  There 
definitely will also be other information (“business logic”, and you can call 
the exchange of that part of the registration info “onboarding” if you like), 
and that is where the vendor differentiation can set in, but we should have no 
trouble defining the ACE content of client registration.

If we don’t define that ACE content, there is no way to know whether ACE OAuth 
is secure.

Defining the ACE content of the client registration as a set of data structures 
also helps with achieving actual interoperability, even if additional business 
logic is required in a specific case.

Grüße, Carsten

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark

[Carsten Bormann]

On Feb 20, 2018, at 08:43, Hannes Tschofenig  wrote:
> 
> IMHO the biggest problem with "onboarding" is that people create new terms 
> without specifying what they actually mean and thereby fail to see the 
> relationship with existing work.

Right.  I have no idea what client registration has to do with “onboarding”, 
but I use that term for the initial integration of a device into a network only.

I continue to believe that we need a clear understanding of what information is 
exchanged during client registration that is relevant to the ACE OAuth.  There 
definitely will also be other information (“business logic”, and you can call 
the exchange of that part of the registration info “onboarding” if you like), 
and that is where the vendor differentiation can set in, but we should have no 
trouble defining the ACE content of client registration.  

If we don’t define that ACE content, there is no way to know whether ACE OAuth 
is secure.

Defining the ACE content of the client registration as a set of data structures 
also helps with achieving actual interoperability, even if additional business 
logic is required in a specific case.

Grüße, Carsten

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark

[Hannes Tschofenig]

IMHO the biggest problem with "onboarding" is that people create new terms 
without specifying what they actually mean and thereby fail to see the 
relationship with existing work.

-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Michael Richardson
Sent: 19 February 2018 19:21
To: Ludwig Seitz
Cc: ace@ietf.org
Subject: Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in 
the dark


Ludwig Seitz <ludwig.se...@ri.se> wrote:
> I agree that onboarding is a valid concern (which is why I wrote
> appendix B),
> but lets not delay draft-ietf-ace-oauth-authz any further by adding a 
whole
> new set of functionality in it.

Back at the beginning of ACE it was clear that onboarding was an entire project 
of itself.  That's why I argued to keep it out of the first charter.

Onboarding suffers from a tendancy to boil the ocean, combined with the
elephant/blind-men problem.The way to tackle onboarding is not with
a single unifying ocean boiling protocol, but rather by letting each interested 
party define small protocols, and over time find commonality.
I get the vision of:  https://en.wikipedia.org/wiki/Nibbler

So while it is unfortunate if some implementers feel to be "in the dark", 
before we could rectify that situation, we'd have to know which implementers we 
are worried about.

--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works  -= IPv6 
IoT consulting =-



IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark

[Carsten Bormann]

On Feb 18, 2018, at 08:35, Hannes Tschofenig  wrote:
> 
> Hi Carsten,
> 
> We should maybe add that this information is provisioned either during 
> manufacturing, via a commissioning tool or some other mechanisms. Not sure 
> whether this will indeed add more but it might be useful to know.

For a protocol that is meant to be interoperable, there need to be standard (if 
not MTI) ways of getting this done.
At least we need to have a defined interface between CAM (“commissioning tool”) 
and C for letting C know what was agreed about how to address AS and which RSes 
it should be used for.

Grüße, Carsten

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-oauth-authz-02

[Somaraju Abhinav]

On 2016-10-10 09:02, Somaraju Abhinav wrote:
> Hi, I have been looking into this draft, which is very well written,
> and I would like a clarification regarding the workflow in figure 1
> of the draft.
>
> This workflow is a bit different to the typical one I imagine for
> constrained clients/servers. Such devices would typically be
> provisioned from some kind of a commissioning tool and the tool would
> also initiate the provisioning process. Therefore, would it not be
> better to have a protocol flow that is not necessarily initiated by
> the client device?

If I understand you correctly, you are suggesting to provision either
the grant or the access token during the commissioning process.

Our idea was to use the client credentials grant instead (not shown in
our figure 1) and have the AS decide what access tokens to grant purely
based on the credentials presented by the client.

This way you don't have to provision anything, except for base
credentials to a client.

The underlying idea is that the RO would configure access control
policies at the AS during the commissioning procedure. The AS uses these
to determine what kind of access tokens to grant to the client, when it
requests one.
[AS] Okay. This makes sense. I did not understand this from the text and maybe 
some clarification in the text could help. For example, in figure 2, how does 
the client know what to write in the "aud" field. In the Figure 3, the 
grant_type says "token" and I am not sure how this would work. In general, this 
Section is a little unclear to me and maybe an example in the Appendix of how a 
commissioning tool would be used to provision the system might help with the 
readability of the document.

You could of course also provision a long term access token to the
client during commissioning (I think we mentioned that somewhere, or at
least thought of it), so your proposed option 2 would also be valid, and
I think they would work just as well with the rest of the framework.
I would suggest to add a step before (A) then, were the RO requests an
access token from the AS on behalf of the client.
[AS] Okay. This could work but maybe the CoAP server/client interaction needs a 
little bit more work (e.g. how can the AS initiate an interaction with the 
client without needing the client to send a GET request).

As for option 1, I am not sure what the advantage would be of
provisioning a grant to the client as opposed to using the client
credentials grant. Could you elaborate on that?
[AS] Now that I understand your idea better (i.e. use of client credentials and 
the fact that the commissioning tool tells the AS the access rights of the 
client), I don't think Option 2 is required. I was thinking of a situation 
where the commissioning tool is not permanently available. With Option 2, the 
commissioning tool could be available during the initial provisioning and 
during this time it could provide every client with an authorization grant that 
includes in the "claims" the access rights of the client. This authorization 
grant could then be used in the token request from client to AS, which then 
provides the access tokens.
 The contents of this 
e-mail and any attachments are confidential to the intended recipient. They may 
not be disclosed to or used by or copied in any way by anyone other than the 
intended recipient. If this e-mail is received in error, please immediately 
notify the sender and delete the e-mail and attached documents. Please note 
that neither the sender nor the sender's company accept any responsibility for 
viruses and it is your responsibility to scan or otherwise check this e-mail 
and any attachments.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace