Subject: Re: [Ace] ACE Framework Review

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Nov 2018 09:31:01 -0500

Thanks for this amazing analysis.
It languished in my inbox because it was not bikeshed material, and I had to
think about things :-)

Stefanie Gerdes <[email-masked]> wrote:
    > The minimal security requirements for the communication between two
    > communication partners should be listed (C-AS, RS-AS, C-RS,
    > respectively). Which pieces of information do they require prior to the
    > communication? How must the communication be secured? Which keying
    > material do they need to use? The framework should point out that all
    > claims that influence the security must stem from claimants that were
    > approved by the respective human being that is responsible for the
    > device, i.e., the requesting party for the client and the resource
    > owner for the AS and RS. Otherwise the solution is not secure.

It seems that the answers should start with 
   "which keying material do they need to use"

and then move upwards.

    > Management of the authz-info resource: * The authz-info resource is
    > vulnerable to DoS attacks: clients may (with or without intention) send
    > large numbers of access tokens to RS. A constrained RS may soon run out
    > of memory/storage space if it needs to store large numbers of

This seems like a really serious issue, and it seems that we need
an additional RTT to really fix it.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 12 Nov 2018 15:50:20 +0100

> an additional RTT to really fix it.

Note Steffi's words were: "store large numbers of tokens".

In order to have the RS store a large number of tokens, an attacker 
would need to have a large number of valid tokens for starters (since 
invalid tokens are not stored but discarded).

Furthermore, since the RS checks whether the audience of a token 
applies, and can safely discard tokens that do not have a matching 
audience the attacker would need to have a large number of tokens that 
all match an audience that this RS identifies with.

Finally we just learned at IETF 103 that OAuth typically does not use 
multiple, simultaneous access tokens for the same pair of client-RS. 
Thus if the token has a subject (sub claim) or some other binding to the 
client, the RS can safely discard all older tokens bound to the same client.

Therefore I propose that an attack that induces the RS to store a large 
number of tokens is quite hard to pull of.

Even so, lets still assume it would be possible, there is this part in 
the spec:

==========================
5.8.1.  The Authorization Information Endpoint

...
    The RS MUST be prepared to store at least one access token for future
    use.
...
==========================

This means that the RS can limit the total number of tokens it stores 
for future use based on its memory and storage space, as long as it 
stores at least one (in total, not per client).

Thus I'm curious what additional protections you would suggest are 
feasible and necessary for the authz-info endpoint?

/Ludwig

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

---

From: Jim Schaad <[email-masked]>
Date: Mon, 12 Nov 2018 22:07:18 +0700

> -----Original Message-----
> From: Ace <[email-masked]> On Behalf Of Ludwig Seitz
> Sent: Monday, November 12, 2018 9:50 PM
> To: [email-masked]
> Subject: Re: [Ace] ACE Framework Review
> 
> >      > large numbers of access tokens to RS. A constrained RS may soon
run
> out
> > This seems like a really serious issue, and it seems that we need an
> > additional RTT to really fix it.
> >
> 
> In order to have the RS store a large number of tokens, an attacker would
> need to have a large number of valid tokens for starters (since invalid
tokens
> are not stored but discarded).
> 
> Furthermore, since the RS checks whether the audience of a token applies,
> and can safely discard tokens that do not have a matching audience the
> attacker would need to have a large number of tokens that all match an
> audience that this RS identifies with.
> 
multiple,
> simultaneous access tokens for the same pair of client-RS.

Putting the last three "checks" into the text someplace about DoS attacks as
well as pointing to the echo option would be a good start to helping people
make sure that they think about this problem and that they look at it
solidly.

I would also suggest that sending the same token over and over should not be
a good attack as the RS can look at the AS and the token ID and not process
if it is the same.

Jim

> Even so, lets still assume it would be possible, there is this part in the
spec:
> ....
> ....
> This means that the RS can limit the total number of tokens it stores for
> future use based on its memory and storage space, as long as it stores at
> least one (in total, not per client).
> 
feasible
> and necessary for the authz-info endpoint?
> 
> /Ludwig
> 
> 
> 
> --
> Ludwig Seitz, PhD
> Security Lab, RISE
> Phone +46(0)70-349 92 51
> 
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace